Okta verlagert den Kontext seiner KI-Agenten in dbt, damit alle Agenten auf eine gemeinsame Wahrheitsquelle zugreifen

Von schnellen Experimenten zu drei Schwachstellen

Oktas frühe KI-Experimente liefen über Semantic Views, die direkt in der Snowflake-Oberfläche erstellt und unmittelbar mit Snowflake Cortex Agenten verbunden wurden. Laut dem Bericht von dbt Labs funktionierte das, und zwar schnell. Allerdings waren diese Semantic Views vollständig von den gesteuerten dbt-Modellen entkoppelt, die die Geschäftslogik definierten.

Crahens Team, rund dreizehn Analytics Engineers, die in den Bereichen Delivery, Go-to-Market, Produkt und Finanzen eingebettet sind, identifizierte drei Probleme:

• Fragmentierter Kontext zwischen Snowflake und dbt.
• Fehlende Nachvollziehbarkeit, da alles im Klickverlauf der Oberfläche steckte.
• Ein undifferenzierter Block: Die Anweisungen eines Agenten waren zusammengeworfen, ohne Unterscheidung zwischen dem, was er immer wissen sollte, und dem, was er nachschlagen sollte.

In der Praxis zeigte sich das in drei Ausfällen. Niemand konnte entdecken, was existierte, weil Semantic Views außerhalb von Snowflake in keinem Katalog auftauchten. Niemand konnte dem Gefundenen vertrauen, weil es kein gemeinsames führendes System gab, das die Aktualität bestätigte. Und jedes Team leitete seine eigenen Definitionen neu ab, statt auf gemeinsamen aufzubauen.

„Nach ein paar Jahren kam die Erkenntnis, dass der Bau des Agenten nie wirklich das Schwierige war“, sagte Crahen. „Schwierig war, was er sehen und worauf er vertrauen konnte.“

Ein dreistufiges Kontext-Framework in dbt

Die Lösung ist ein dreistufiges Framework für den Agentenkontext, das vollständig in dbt aufgebaut ist und über normale Pull Requests ausgeliefert wird.

• Metadaten: Metadaten auf Modell- und Spaltenebene erhalten im YAML einen neuen Unterblock „agent“. Er legt fest, wofür ein Modell sich eignet, wofür nicht und welche Filter automatisch greifen sollen.
• Kontextdokumente: Markdown-Dateien halten unternehmensweite Fakten fest, etwa dass das Geschäftsjahr von Okta am 1. Februar beginnt, sowie domänenspezifische Routing-Regeln.
• Semantic Views: Sie wurden aus der Snowflake-Oberfläche in die Spezifikation der semantischen Schicht von dbt migriert und sind nun die gesteuerte, per PR geprüfte Quelle für Fakten, Dimensionen und Metriken.

Für die Migration baute das Team einen eigenen Skill, der an einen Slash-Befehl gekoppelt ist. Er zieht das DDL einer bestehenden Snowflake Semantic View und wandelt es automatisch in eine dbt-Semantic-View-Spezifikation um.

Okta eröffnete außerdem eine öffentliche GitHub-Diskussion zu dbt Core. Darin geht es um die Frage, ob etwas wie ein Cortex Agent eine normale dbt-Modell-Materialisierung sein sollte oder ein eigener Knotentyp erster Klasse, so wie eine Exposure.

Eine Regel, viele Agenten

Alle drei Ebenen werden automatisch in Agents Schema synchronisiert, das dbt Labs als offenen, Data-Warehouse-nativen Metadatenstandard beschreibt. Jeder Agent mit SQL-Zugriff, ob Cortex oder Claude, kann aus derselben Wahrheitsquelle lesen.

In der Praxis fragt Claude die Metadaten direkt über MCP ab und liest Kontextdokumente als Markdown-Dateien. Cortex liest dieselben Informationen über einen Suchdienst und seine eigene Skill-Konfiguration. Eine einmal in dbt geschriebene Regel wird von beiden übernommen, und ein später hinzugefügter dritter Agent würde sie ohne jede Duplizierung erben.

Laut dem Team verändert das, wie falsche Antworten korrigiert werden. Früher hieß das, eine undurchsichtige Agentenkonfiguration zu bearbeiten und sie in mehreren Zyklen neu auszurollen. Jetzt führt ein Analytics Engineer eine Änderung an der Kontextschicht in dbt zusammen, und jeder Agent, der daraus liest, wird sofort besser. „Das Ergebnis ist, dass die hundertste Frage dieselbe Antwortqualität bekommt wie die erste“, sagte Crahen. „Es geht nicht um den Agenten. Es geht eher um Kontext als Infrastruktur.“

Wie es weitergeht

Okta plant automatisierte Regressionstests, die verifizierte Abfragen gegen die Agenten ausführen, sobald sich der Kontext ändert. Zudem soll der Kontext über eine einzelne Domäne hinaus ausgeweitet werden. Langfristig will das Team den Kreis zwischen den Antworten eines Agenten und der Ground Truth schließen, sodass Korrekturen automatisch in die Kontextdokumente zurückfließen können. Crahen beschrieb das als Schritt von „Vertrauen, aber prüfen“ hin zu einem messbaren Genauigkeitswert.

Für Datenteams, die mehr als einen KI-Agenten betreiben, liefert der Fall Okta eine praktische Lehre: Wer Kontext als versionierte, prüfbare Infrastruktur in der Transformationsschicht behandelt, statt ihn pro Agent zu konfigurieren, hält die Antworten konsistent, wenn weitere Agenten hinzukommen.