Okta hat den Kontext seiner KI-Agenten in dbt Pull Requests verlagert, und falsche Antworten lassen sich jetzt mit einem Merge beheben

Oktas erste KI-Analytics-Agenten funktionierten, und genau das war das Problem. Laut einem Bericht von dbt Labs (ein Anbieter, für dessen Tooling sich Okta entschieden hat, also eher eine Kundengeschichte als ein Audit) liefen Oktas frühe KI-Experimente auf Semantic Views, die direkt in der Oberfläche von Snowflake gebaut und unmittelbar mit Snowflake-Cortex-Agenten verbunden waren. Das funktionierte, und zwar schnell, aber diese Semantic Views hatten keinerlei Verbindung zu den governten dbt-Modellen, in denen die Geschäftslogik tatsächlich definiert war. Das Team dahinter ist klein. Crahens Team, rund dreizehn Analytics Engineers, die in Delivery, Go-to-MarketGo-to-MarketDie Strategie, die festlegt, wie Sie ein Produkt einführen: Zielsegmente, Kanäle, Value Proposition und koordinierter Aktionsplan.Vollständige Definition ansehen →, Product und Finance eingebettet sind, gehört zu einer größeren Technologie-, Daten- und Intelligence-Organisation, die für das Reporting Tableau und als zentrales Warehouse Snowflake nutzt.

Pooja Crahen, Senior Manager of Analytics Engineering bei Okta, beschrieb das Problem auf dem dbt Summit 2026: „Nach ein paar Jahren kam die Erkenntnis, dass das Bauen des Agenten nie der schwierige Teil war“, sagte Crahen. „Schwierig war, was ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → sehen und dem er vertrauen konnte.“ Ihr Team fand drei Risse in diesem Fundament: fragmentierter Kontext zwischen Snowflake und dbt, keine Nachvollziehbarkeit, weil alles nur in der Klick-Historie der Oberfläche existierte, und sämtliche Anweisungen eines Agenten in einem einzigen undifferenzierten Block.

Was diesen Fall nützlich macht, ist Oktas Position. Das Unternehmen verkauft Identity Governance für KI-Agenten. CEO Todd McKinnon sagte gegenüber Investoren, dass unter den Kunden „über 90 % Agenten in Produktion haben und nur 22 % sicher sind, dass sie diese im Griff haben“ (eine Einschätzung des Anbieters über die eigenen Kunden, also kein neutraler benchmark). Trotzdem scheiterte Oktas internes Datenteam nicht am Zugriff. Es scheiterte an der Bedeutung. Meine These: Ein Agent kann genau die richtigen Berechtigungen haben und trotzdem selbstsicher eine falsche Antwort geben. Für einen CDO heißt KI-Risiken steuern, den Kontext, den Agenten lesen, derselben Change Control zu unterwerfen wie den Code, der die Zahlen erzeugt, ihn in einem Repository zu halten und ihn dort zu veröffentlichen, wo jeder Agent ihn lesen kann.

Wie Okta den Agentenkontext aus der Snowflake-Oberfläche nach dbt verlagert hat

Aus den drei Rissen wurden konkrete Fehler. Niemand konnte herausfinden, was existierte, weil es keinen Katalog gab, der die Semantic Views außerhalb von Snowflake sichtbar machte. Niemand konnte dem Gefundenen trauen, weil kein gemeinsames System of Record bestätigte, dass es aktuell war. Und jedes Team leitete seine Definitionen am Ende von Grund auf selbst her. Der dritte Fehler ist derjenige, der einem CDO Sorgen machen sollte. Wenn jedes Team seine eigenen Definitionen schreibt, haben Sie am Ende mehrere Versionen jedes KPIKPIKey Performance Indicator, ein messbarer Wert, der zeigt, wie wirksam Sie ein bestimmtes Ziel erreichen, über die Zeit verfolgt und gegen einen Zielwert gemessen.Vollständige Definition ansehen →, und niemand ist für eine davon verantwortlich.

Drei Kontextebenen, ein Pull-Request-Workflow

Die Lösung war ein dreistufiges Kontext-framework für Agenten, komplett in dbt gebaut und über normale Pull Requests ausgeliefert.

• Auf Asset-Ebene erhalten die Metadaten auf Modell- und Spaltenebene im YAML einen neuen Unterblock „agent“, der festhält, wofür ein Modell sicher genutzt werden kann, wofür nicht, und welche Filter automatisch greifen müssen.
• Auf Unternehmensebene erfassen Kontextdokumente in Markdown unternehmensweite Fakten (Oktas Geschäftsjahr beginnt am 1. Februar) und domänenspezifische Routing-Regeln.
• Auf Metrikebene werden die Semantic Views, aus der Snowflake-Oberfläche in die Semantic-Layer-Spezifikation von dbt migriert, zur governten, per PR geprüften Quelle für Facts, Dimensionen und Metriken.

Auch die Migration wurde automatisiert. Um die Semantic Views nach dbt zu bringen, brauchte es einen eigenen Skill mit einem Slash-Befehl, der die DDL einer bestehenden Snowflake Semantic View ausliest und automatisch in eine dbt-Semantic-View-Spezifikation umwandelt. Wenn Sie sehen möchten, wie Metrikdefinitionen zu einem einzigen Vertrag werden, den jeder Konsument abfragt, geht unsere Lektion zurSemantic-Layer-Spezifikation von dbt und governten Metriken tiefer darauf ein.

Kontext über Agents SchemaSchemaEin Schema ist der formale Bauplan, der festlegt, wie Daten in einer Datenbank, einer Datei oder einer Nachricht strukturiert, benannt, typisiert und miteinander verknüpft sind.Vollständige Definition ansehen → veröffentlichen

Kontext in einem Repository zu halten, bringt nur etwas, wenn die Agenten ihn tatsächlich von dort lesen. Bei Okta werden alle drei Ebenen automatisch in Agents Schema synchronisiert, einen offenen, warehouse-nativen Metadatenstandard, sodass jeder Agent mit SQLSQLSales Qualified Lead: ein Prospect, den das Sales-Team als bereit für direkte Ansprache und ein Angebot validiert hat, weil er klare Qualifizierungskriterien erfüllt.Vollständige Definition ansehen →-Zugriff, ob Cortex oder Claude, dieselben Definitionen liest. Im Open-Source-Repository, das dbt Labs pflegt, hat Ihr Warehouse nach dem ersten Lauf abfragbare Metadatentabellen wie AGENTS.DBT_MODEL, AGENTS.LOOKML_VIEW, AGENTS.OMNI_VIEW oder AGENTS.OSI_DATASET. Agenten kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen über diese Tabellen erkennen, welche Modelle und semantischen Objekte existieren. Der Standard hat kommerziellen Rückhalt: Fivetran und dbt Labs, inzwischen ein Unternehmen, haben angekündigt, dass ihr neuer Context Layer Agents Schema nutzt, einen Open-Source-Standard, der Kontext in einem strukturierten, erweiterbaren Format direkt im Data WarehouseData WarehouseEin zentrales Repository, das Daten aus vielen Quellsystemen in einem strukturierten, abfrageoptimierten Speicher zusammenführt, ausgelegt für Analytics, Reporting und Business Intelligence.Vollständige Definition ansehen → bündelt.

Okta hat die Designfrage außerdem in die dbt-Community getragen. Das Unternehmen hat auf GitHub eine öffentliche Diskussion zu dbt Core eröffnet, ob so etwas wie ein Cortex-Agent einfach eine normale Materialisierung eines dbt-Modells sein sollte oder einen eigenen, vollwertigen Node-Typ verdient, so wie eine Exposure. Diese Frage lohnt sich zu verfolgen. Wenn Agenten zu Nodes im DAG werden, könnten Lineage-Tools anzeigen, welche Agenten eine Schemaänderung kaputtmachen würde.

Hat die Governance des Kontexts in dbt Oktas Agenten genauer gemacht?

Okta hat keine Genauigkeitszahl veröffentlicht, ehrlicherweise wissen wir also nicht, um wie viel. Was das Unternehmen berichtet, sind Konsistenz und schnellere Korrekturen. Laut Crahen bedeutet die Korrektur einer falschen Antwort nicht mehr, eine undurchsichtige Agentenkonfiguration zu bearbeiten und über mehrere Zyklen neu zu deployen. Ein Analytics Engineer merged eine Änderung am Kontext-Layer in dbt, und jeder Agent, der davon liest, wird sofort besser. Ihr Fazit: „Das Ergebnis ist, dass die 100. Frage eine Antwort in derselben Qualität bekommt wie die erste“, und „Es geht nicht um den Agenten. Es geht eher um Kontext als Infrastruktur.“

Die Roadmap zeigt, was noch fehlt. Als Nächstes plant das Team automatisierte Regressionstests, die bei jeder Kontextänderung verifizierte Abfragen gegen die Agenten laufen lassen, die Ausweitung des Kontexts über eine einzelne Domäne hinaus und später den Abgleich der Agentenantworten mit der Ground Truth. Heute erreicht ein Kontext-Merge also alle Agenten gleichzeitig, aber noch kein automatisierter Test bestätigt, dass der Merge etwas verbessert hat. Diese Lücke ist als Nächstes zu schließen, denn derselbe Mechanismus, der eine Korrektur sofort verbreitet, verbreitet einen Fehler genauso schnell.

Data Culture, ein Beratungsunternehmen, hat gemessen, was Okta noch nicht gemessen hat. Auch diese Ergebnisse kommen über dbt Labs und den eigenen Blog, stehen also dem Anbieter nahe. Data Culture begann mit 13 Golden Questions, echten Geschäftsfragen, die Stakeholder stellen würden, jeweils mit einer verifizierten richtigen Antwort, und fügte dann Ebene für Ebene Kontext hinzu. Mit dem Agenten auf Rohtabellen lautete das Ergebnis SQL generation: 0% | Accuracy: 0%. Später stellte sich heraus, dass ihre Auswertung das Problem war. Antworten wurden als falsch gewertet, weil der Agent eine Spalte TOTAL_APPOINTMENTS nannte, während wir APPOINTMENT_COUNT erwartet hatten. Oder er lieferte 33.30%, wo wir 33.3% notiert hatten. Nachdem sie die Vergleichslogik korrigiert hatten, sprang die Genauigkeit in den unteren 90er-Bereich. Am Agenten hatten wir gar nichts geändert. Die Zahl, die dbt Labs für dieses Deployment nennt, ist 94,7 %.

Als neutrale Referenz: Gartner prognostiziert, dass Organisationen bis 2026 60 % der KI-Projekte aufgeben werden, die nicht von KI-fähigen Daten gestützt sind, und rät Organisationen, kontinuierlich in Metadatenmanagement, Data ObservabilityData ObservabilityKontinuierliche Überwachung des Datenzustands, um Ausfälle, Drift oder fehlende Daten zu erkennen, bevor sie einen Report oder ein Modell erreichen.Vollständige Definition ansehen → sowie D&A- und KI-Governance zu investieren und deren Reife weiterzuentwickeln. Oktas Setup ist eine konkrete Umsetzung dieses Rats.

Was CDOs von Oktas Context-as-Code-Modell übernehmen können

Eine Sortierregel für Agentenkontext

Oktas drei Ebenen liefern eine einfache Regel, um zu entscheiden, wohin jedes Stück Kontext gehört. Schreiben Sie sie ans Whiteboard:

Gilt es für das ganze Unternehmen, ist es ein Kontextdokument. Berechnet es eine Zahl, ist es eine semantische Definition. Schränkt es ein, wie eine Tabelle genutzt werden darf, ist es eine Leitplanke auf Modellebene. Liegt es irgendwo anders, ist es ein Risiko.

Prüfen Sie dann jeden Eintrag mit vier Fragen. Wo liegt er? Wer hat ihn freigegeben? Wann wurde er zuletzt geändert? Kann jeder Agent ihn lesen? Antworten wie „in einer Oberfläche“, „niemand“, „weiß nicht“ oder „nur ein Agent“ deuten auf die Risse hin, die Okta gefunden hat.

Ein durchgerechnetes Beispiel: Oktas Geschäftskalender

Oktas Geschäftsjahr beginnt am 1. Februar, und das Unternehmen berichtet nach diesem Kalender. Die jüngsten Ergebnisse betrafen das zweite Quartal des Geschäftsjahres 2027 mit einem Gesamtumsatz von 805 Millionen US-Dollar. Zur Rechnung: Wenn Q1 von Februar bis April läuft, läuft Q2 von Mai bis Juli 2026. Ein Agent, der das nicht weiß und nach dem „Q2-Umsatz“ gefragt wird, zieht April bis Juni. Nur zwei der drei Monate überschneiden sich, ein Drittel des Zeitraums ist also falsch, und der Agent liefert trotzdem eine präzise wirkende Zahl. Mit einer einzigen Zeile in einem geprüften Kontextdokument bekommt jeder Agent das Quartal richtig. Ohne sie muss jedes Team daran denken, es dem eigenen Agenten mitzuteilen, und Okta hat festgestellt, dass Teams das nicht zuverlässig tun.

Wo sich Ihre Situation von Oktas unterscheidet

Okta arbeitet mit einem einzigen Warehouse und hat eine ausgereifte dbt-Praxis. Wenn Ihre Metriken über Snowflake, Databricks und den eigenen Semantic LayerSemantic LayerEine gemeinsame Ebene für Geschäftsdefinitionen zwischen Rohdaten und Berichten, damit alle Umsatz, Churn oder Marge gleich berechnen.Vollständige Definition ansehen → eines BIBITechnologien und Prozesse, die Rohdaten über Reporting, Dashboards und Analysen in verwertbare Insights überführen, damit Teams auf Basis von Fakten statt Intuition entscheiden.Vollständige Definition ansehen →-Tools verteilt sind, steigt der Wert eines offenen Standards. Agents Schema führt bereits dbt, Looker, Omni, OSI, Sigma und Markdown-Skills als Quellen. Wenn Sie dbt nicht in Produktion haben, bringen Sie zuerst Ihre Definitionen unter Versionskontrolle, bevor Sie Agenten darauf aufbauen.

Der Sicherheitsaspekt, den CDOs gern überspringen: Ein „avoid“-Flag im YAML ist eine Empfehlung für den Agenten. Es setzt nichts durch. Ein Agent, der seinen Kontext ignoriert, kann weiterhin jede Tabelle abfragen, die seine Rolle erreicht. Die echte Kontrolle ist ein Warehouse-Grant, eine Row Policy oder ein Identity-Layer, und genau dort kommen Oktas kommerzielle Produkte ins Spiel: Laut Unternehmen wird jeder Agent im Universal Directory von Okta als „eindeutige, vollwertige Identität“ behandelt statt als Benutzer- oder Service-Account. Koppeln Sie deshalb jedes „avoid“-Flag an eine durchgesetzte Regel, nacheinem Zero-Trust-Ansatz für Klassifizierung und Zugriff. Context Governance entscheidet, ob eine Antwort richtig ist. Access Control entscheidet, ob der Agent überhaupt hinschauen durfte.

Das wird dringlicher, sobald Agenten anfangen, Transformationscode zu schreiben. In Meldungen, die dbt Labs zu seinem Summit 2026 veröffentlicht hat (Anbieterquellen), schreibt und validiert der Agent von Careem dbt-Modelle, bevor ein Mensch den PR prüft, und DocuSign meldete einen Produktivitätsgewinn von 50 % durch die Kombination von Claude Code mit dbt MCPMCPEin offener Standard, mit dem KI-Assistenten einheitlich und kontrolliert an die Werkzeuge und Daten des Unternehmens angebunden werden, statt jede Integration einzeln zu bauen.Vollständige Definition ansehen →. Sobald Agenten den Kontext-Layer bearbeiten können, ist das Review von Kontext-Pull-Requests eine Sicherheitskontrolle.

Was Sie am Montag beim Kontext für KI-Agenten tun sollten

• Listen Sie jeden Ort auf, an dem heute Agentenanweisungen liegen: Warehouse-Oberflächen, System-prompts, Copilot-Konfigurationen, Notebooks. Zählen Sie sie. Oktas Problem begann damit, dass diese Zahl größer als eins war.
• Schreiben Sie ein einziges Markdown-Kontextdokument für eine Domäne. Nehmen Sie den Geschäftskalender, Kundendefinitionen und Routing-Regeln auf, committen Sie es ins Repo und benennen Sie einen Code Owner.
• Ergänzen Sie Ihre zehn meistabgefragten Modelle um einen Agenten-Metadatenblock, der festhält, wofür jedes sicher ist, was zu vermeiden ist und welche Filter Pflicht sind.
• Schreiben Sie mit Fachexperten 13 Golden Questions (die Zahl, die Data Culture verwendet hat) und lassen Sie sie nach jeder Kontextänderung manuell laufen, bis Sie den Lauf automatisieren können.
• Ordnen Sie jedem „avoid“-Flag einen echten Warehouse-Grant oder eine Row Policy zu. Wo es keine solche Regel gibt, eröffnen Sie ein Ticket bei Ihrem Security-Team.

Okta hat das Vertrauensproblem bei Agenten nicht mit einem besseren Modell oder einem neuen Zugriffstool gelöst. Das Unternehmen hat die Definitionen, auf die sich Agenten stützen, prüfbar, versioniert und gemeinsam nutzbar gemacht, sodass ein Merge alle Agenten auf einmal korrigiert. Der nächste Schritt, den Okta noch nicht gebaut hat, ist ein Regressionstest, der belegt, dass jeder Merge die Antworten verbessert hat.