Jeder BI-Stack, den ich je gesehen habe, endet auf dieselbe Weise: Ein Mensch schaut auf ein Diagramm und entscheidet, was zu tun ist. Die vorgelagerte Engineering-Arbeit (Ingestion, Modellierung und Tests) dient dazu, dass eine Person das Diagramm liest und entscheidet. Das Dashboard liefert die Information, ein Mensch handelt, und so funktioniert Analytics seit zwanzig Jahren.
Für meine MSc-Abschlussarbeit habe ich zunächst den üblichen Analytics-Teil dieses Ablaufs gebaut. Ich habe einen Churn-Intelligence-Stack für eine produktive B2B-SaaS-Umgebung gebaut: Survival Analysis, um zu sagen, wann Accounts voraussichtlich abwandern, Gradient-Boosting-Klassifikation mit SHAP-Erklärungen, um zu sagen, wie wahrscheinlich und warum, und kausale Inferenz mit DR-Learner, um zu sagen, welche Interventionen tatsächlich wirken, statt nur mit dem Bleiben zu korrelieren. Er basiert auf einem Warehouse aus 48 dbt-Modellen in geschichteter Kimball-Architektur, befüllt von Python-Extraktoren und orchestriert mit Dagster.
Dann habe ich, statt beim Dashboard aufzuhören, einen Model-Context-Protocol-Endpoint obendrauf gesetzt.
Was MCP tatsächlich ändert
MCP ist ein kleiner offener Standard, der es einem LLM-Agenten erlaubt, von Ihnen definierte Tools aufzurufen. Mein Server stellt zwölf davon über dem Intelligence-Stack bereit: Dinge wie churn_at_risk_accounts, churn_score_for_account und csm_intervention_priority, organisiert in die Domänen Churn, Account und Customer Success über einer gemeinsamen Datenbankschicht.
Der Unterschied zeigt sich am deutlichsten an einem einzigen Austausch. Ein Customer-Success-Lead fragt: "Welche Accounts sind dieses Quartal hochriskant, und welche davon würden tatsächlich reagieren, wenn wir intervenieren?" Auf einem Dashboard sind das zwei Filter, ein Join im Kopf und eine Diskussion darüber, was "reagieren" bedeutet. Über den MCP-Endpoint verkettet ein Agent zwei Tool-Aufrufe, gleicht das Survival-Fenster mit der kausalen Treatment-Gruppe ab und antwortet mit der priorisierten Liste samt SHAP-Treibern pro Account. Der Mensch trifft weiterhin die Entscheidung, muss aber nicht mehr warten, filtern oder die beiden Ansichten manuell zusammenführen.
Meine zentrale These: Dashboards informieren, Agenten handeln, und die wichtigste Engineering-Frage betrifft dann die Qualität der Datenebene darunter.
Die Antworten des Agenten hängen von getesteten Marts ab
Die meisten Agent-Demos lassen den folgenden Punkt aus. Ein LLM-Agent antwortet aus einem kaputten Mart mit genau derselben Überzeugung wie aus einem korrekten. Er hat keine Ahnung, dass Ihr Umsatzmodell Verlängerungen stillschweigend doppelt zählt. Ein menschlicher Analyst würde eine verdächtige Zahl vielleicht hinterfragen; der Agent fasst sie zusammen, ohne sie zu prüfen.
Die Verlässlichkeit der agentischen Schicht hängt daher von der Routinearbeit an den Daten im Stack ab. In diesem Projekt hieß das: dimensionale Modelle mit Tests auf jeder Ebene, Contracts auf den Schnittstellen, die die Tools abfragen, und Korrektheit, die in der CI geprüft wird, bevor irgendetwas den Serving Layer erreicht. Diese Arbeit lässt sich in einer Demo schwer zeigen, sie ist aber der Grund, warum die Antworten des Agenten verlässlich sind.
Wenn Ihre Marts nicht getestet sind, liefert ein MCP-Endpoint flüssig formulierte, überzeugt klingende Antworten, die falsch sein können.
Einschränkungen
Dies war ein Abschlussprojekt in einer NDA-geschützten Umgebung, die Fallstudie auf dieser Seite ist daher bereinigt und der veröffentlichte Code anonymisiert. Das Survival-Modell erreichte kreuzvalidiert einen C-Index von 0,850, der Klassifikator eine AUC von 0,924 und lag damit über der logistischen Baseline. Die Kausalschicht korrigierte einen Selektionsbias von rund 50 Prozentpunkten, den ein naiver Vergleich als Tatsache berichtet hätte. Die getestete Datenebene macht diese Ergebnisse belastbar.
Agenten verkürzen die Zeit zwischen einer Frage und ihrer Antwort; Analysten werden weiterhin gebraucht. Jemand muss weiterhin entscheiden, was eine Treatment-Gruppe bedeutet, ob eine Intervention ihre Kosten wert ist und wann das Modell falsch liegt. Dieser Jemand verbringt seine Zeit jetzt mit Urteilsvermögen statt mit Filtern.
Das Muster ist auf andere Bereiche übertragbar
Nichts davon ist Churn-spezifisch. Jede Intelligence-Schicht mit echter Modellierung darunter, bepreistes Risiko, Nachfrageprognosen, Fraud-Scores, lässt sich auf dieselbe Weise zugänglich machen: Tools über getesteten Marts, Erklärungen an jeder Zahl und ein Agent davor. Ich glaube, in drei Jahren wird es schlicht das sein, was "Serving Layer" bedeutet.
Zur vollständigen Fallstudie → Auf GitHub ansehen →
Ich bin Analytics Engineer in Manchester, UK, und baue Datenplattformen mit dbt, Dagster und PostgreSQL. Wenn Sie an ähnlichen Problemen arbeiten, schreiben Sie mir gern.