Das Problem: Der traditionelle BI-Stack als Flaschenhals
Eine einfache Frage zu den Umsatzzahlen beantwortet die Datenabteilung erst nach drei Tagen. LangChain stand vor genau diesem Problem. Ihr Data Stack: ein klassisches BI-Tool, gut für vordefinierte Reports, unflexibel für spontane Fragen. Jede Anfrage landete bei der Datenabteilung, damals eine Person. Sie entschlüsselte die Frage, suchte das Modell, schrieb SQL, validierte das Ergebnis und antwortete. Das bremste viele Anfragen aus.
Die Entwickler erkannten, dass der Workflow nicht skalierte. Sie wollten einen Stack für mehrere Benutzertypen gleichzeitig: Dashboards für Eilige, Notebooks für Techniker, direkte Fragen für Geschäftsanwender – und optimiert für einen KI-Agenten, der die Datenabteilung entlastet. Das war der Ausgangspunkt.
Die Lösung: Ein zentraler Arbeitsplatz für Menschen und Agenten
Das Team ersetzte den alten BI-Stack durch Hex. Hex bietet Dashboards, Notebooks, SQL-Workflows und eine konversationelle Schnittstelle – alles in einer Plattform mit eingebauten KI-Funktionen. So entstand ein zentraler Arbeitsplatz für Menschen und Agenten. Der Agent operiert als virtueller Analyst und ist über Hex, Slack, CLI oder MCP zugänglich. Nutzer fragen dort, wo sie arbeiten.
Ein Produktmanager fragt in Hex nach Nutzerverhalten, ein Vertriebler stellt die gleiche Frage über Slack, ein Entwickler nutzt das CLI. Der Agent liefert eine erste Antwort; die Datenabteilung validiert später. Die Migration dauerte sechs Wochen. Danach nutzen 100 Prozent des Unternehmens den neuen Stack. 30 Prozent der Mitarbeiter haben Agentenzugriff, beantragbar über die IT. Der Agent bearbeitet heute die 40‑fache Menge an Anfragen, die das dreiköpfige Daten‑Team zuvor schaffte. In den letzten 30 Tagen gab es rund 2.200 Agentengespräche – durchschnittlich 23 pro aktivem Nutzer.
Die Kontextschichten: Das Rezeptbuch für den Agenten
Die Qualität des Agenten hängt vom Kontext ab. Ein Datenagent ohne Kontext ist wie ein Koch ohne Rezept – er mischt Zutaten, aber das Ergebnis passt selten. LangChain hat vier Schichten aufgebaut, die dem Agenten genau sagen, was die Daten bedeuten und wie sie verwendet werden.
1. Datenmodelle mit klaren Definitionen
Die Grundlage sind Datenmodelle, verwaltet mit dbt. dbt organisiert SQL‑Abfragen und Beschreibungen für Tabellen und Spalten. Jede Spalte bekommt nicht nur einen technischen Namen, sondern eine erklärende Beschreibung. Statt account_status: Der Status des Kontos heißt es nun: account_status: Der aktuelle Lebenszyklusstatus des Kontos in Salesforce. ‚Active‘ bedeutet, der Kunde hat einen aktiven bezahlten Vertrag. ‚Churned‘ bedeutet, der Kunde hatte früher einen bezahlten Vertrag, der beendet wurde. ‚Prospect‘ bedeutet, das Konto ist noch kein Kunde. Für Kundenberichte filtere auf ‚Active‘, es sei denn, die Analyse schließt explizit abgewanderte oder potenzielle Konten ein. Diese Details liefern Geschäftswissen. Auch Tabellen werden beschrieben: Körnung, geeignete Fragen, Vorsichtshinweise. Schwache Definitionen führen zu technisch korrekten, aber fachlich nutzlosen Antworten.
2. Das semantische Modell für konsistente Metriken
Die zweite Schicht: das semantische Modell. Es definiert Begriffe wie ARR, Pipeline oder Nutzung und ihre Berechnung. So muss der Agent nicht raten, welche Tabelle oder Formel gemeint ist. Das semantische Modell baut auf den sauberen Datenmodellen auf – schlechte Fundamente nützen auch der besten Semantik nichts. Klare Modelle, Körnungen und Definitionen steigern die Qualität auf jeder Ebene.
3. Business-Kontext in Workspace Guides
Manche Informationen – wie unternehmensinterne Prozesse, team‑spezifische Workflows oder Reporting‑Konventionen – passen nicht in Tabellen‑ oder Metrikdefinitionen. Dafür verwenden die Entwickler Workspace Guides in Hex: schriftliche Anleitungen für den Agenten. Ein Guide erklärt etwa: Wie definieren wir die Pipeline für das wöchentliche Vertriebs‑Reporting? Welche Dashboards gelten als kanonisch für eine Metrik? Wie interpretieren wir die Produktnutzung bei verschiedenen Bereitstellungsarten? Welche Filter setzen wir bei Kunden‑Gesundheitsanalysen? Wann leiten wir eine Frage zur Validierung an die Datenabteilung? Diese Guides werden in einem GitHub‑Repository versioniert und automatisch mit Hex synchronisiert. Sie sind in natürlicher Sprache und fangen Nuancen ab, die nicht in Code passen.
4. Endorsements: Vertrauenssignale für den Agenten
Die vierte Schicht: Endorsements – Kennzeichnung vertrauenswürdiger Datenquellen. In vielen Unternehmen gibt es mehrere Tabellen oder Dashboards zu ähnlichen Konzepten. Ohne Vertrauenssignal könnte der Agent eine veraltete Quelle wählen. Deshalb markiert nur die Datenabteilung bestimmte Assets als „endorsed“. Ein endorsed Dashboard ist wie ein offizielles Rezept – der Agent vertraut ihm. Nur das Daten‑Team darf Endorsements vergeben, Änderungen an endorsed Dashboards müssen vorab geprüft werden. Sonst verliert das Signal an Wert, wenn alles endorsed ist. Zusätzlich hat der Agent Zugriff auf das dbt‑Repository, um die SQL‑Logik hinter jeder Spalte nachzuvollziehen. Das ist für technische Nutzer wichtig.
Der Feedback-Loop: Aus Fehlern lernen
Kontext allein reicht nicht. Das Team hat eine Feedback‑Infrastruktur aufgebaut. Sie nutzen das Context Studio von Hex (oder LangSmith). Damit analysieren sie Gesprächsthemen, Warnungen und Fehlschläge des Agenten. Häufige gleiche Fragen deuten auf ein fehlendes Dashboard hin. Bei wiederholten Fehlern zu einer Metrik verbessern sie die Definition im semantischen Modell. Erfordern Fragen internes Prozesswissen, erstellen sie einen neuen Workspace Guide. Greift der Agent auf die falsche Quelle zu, passen sie Endorsements oder die dbt‑Dokumentation an. Dieser Kreislauf aus Beobachten und Verbessern macht den Agenten zuverlässiger.
Fazit: Der Wandel von der Datenabteilung zum Systemkurator
Die Datenabteilung von LangChain wandelte sich vom Dienstleister zum Kurator eines intelligenten Systems. Sie verbringt Zeit mit der Verbesserung von Modellen, dem Schreiben von Guides, der Freigabe von Endorsements und der Analyse von Feedback‑Daten. Einfachere Fragen übernimmt der Agent – mit der 40‑fachen Menge an Anfragen. Jeder mit Agentenzugriff kann jederzeit fragen, ohne auf einen Termin zu warten. Das macht Datenzugang demokratischer, ohne Qualitätsverlust – solange der Kontext stimmt. Für Unternehmen, die KI‑Agenten im Datenbereich einsetzen möchten, ist dieser Ansatz eine Blaupause: Datenfundamente klären, den Agenten mit Kontext versorgen, einen Kreislauf des Lernens etablieren. So wird der Agent mehr als ein SQL‑Generator – er entlastet die Datenabteilung und steigert die Wertschöpfung.
Quelle: langchain.com
