Ein Blick in OpenAIs internen Datenagenten

Daten bestimmen, wie Systeme lernen, sich Produkte weiterentwickeln und wie Unternehmen Entscheidungen treffen. Doch schnell, korrekt und im richtigen Kontext zu Antworten zu kommen, ist oft schwieriger, als es sein sollte. Um das mit dem Wachstum von OpenAI zu vereinfachen, haben wir einen eigenen, maßgefertigten internen KI-Datenagenten entwickelt, der unsere eigene Plattform erkundet und darüber schlussfolgert.

Unser Agent ist ein speziell entwickeltes, ausschließlich internes Tool (kein externes Angebot), das gezielt auf OpenAIs Daten, Berechtigungen und Workflows zugeschnitten ist. Wir zeigen, wie wir ihn gebaut haben und einsetzen, um greifbare Beispiele dafür sichtbar zu machen, wie KI die tägliche Arbeit in unseren Teams konkret unterstützen kann. Die OpenAI-Tools, die wir zum Aufbau und Betrieb genutzt haben (Codex, unser GPT‑5‑Flaggschiffmodell, die Evals API⁠(wird in einem neuen Fenster geöffnet) und die Embeddings API⁠(wird in einem neuen Fenster geöffnet)), sind dieselben Tools, die wir Entwicklern weltweit zur Verfügung stellen.

Unser Datenagent ermöglicht es Mitarbeitenden, in Minuten von einer Frage zu einer Erkenntnis zu kommen – nicht erst nach Tagen. Das senkt die Hürde für Datenabfragen und differenzierte Analysen über alle Funktionen hinweg, nicht nur für unser Datenteam. Heute verlassen sich Teams aus Engineering, Data Science, Go-To-Market, Finance und Research bei OpenAI auf den Agenten, um wirkungsstarke Datenfragen zu beantworten. Zum Beispiel hilft er dabei, Launches zu bewerten und den Zustand des Unternehmens zu verstehen – alles über das intuitive Format natürlicher Sprache. Der Agent kombiniert Codex-gestütztes Wissen auf Tabellenebene mit Produkt- und Organisationskontext. Sein kontinuierlich lernendes Erinnerungssystem sorgt außerdem dafür, dass er mit jeder Runde besser wird.

In diesem Beitrag erklären wir, warum wir einen maßgefertigten KI-Datenagenten brauchten, was seinen Code-angereicherten Datenkontext und sein selbstlernendes Verhalten so wertvoll macht und welche Lehren wir auf dem Weg gezogen haben.

OpenAIs Datenplattform bedient mehr als 3500 interne Nutzer aus Engineering, Product und Research und umfasst über 600 Petabyte an Daten in 70.000 Datensätzen. Bei dieser Größenordnung ist allein das Finden der richtigen Tabelle oft einer der zeitaufwendigsten Teile jeder Analyse.

Wie es ein interner Nutzer formulierte:

„Wir haben viele Tabellen, die sich ziemlich ähnlich sind, und ich verbringe enorm viel Zeit damit herauszufinden, worin sie sich unterscheiden und welche ich verwenden soll. Manche enthalten ausgeloggte Nutzer, andere nicht. Manche haben überlappende Felder; es ist schwer zu erkennen, was was ist.“

Selbst wenn die richtigen Tabellen ausgewählt sind, ist es schwierig, korrekte Ergebnisse zu erzeugen. Analysten müssen über Tabellendaten und Tabellenbeziehungen schlussfolgern, um sicherzustellen, dass Transformationen und Filter korrekt angewendet werden. Häufige Fehlermodi – Many-to-Many-Joins, Fehler beim Filter-Pushdown oder nicht behandelte Null-Werte – können Ergebnisse unbemerkt ungültig machen. Bei der Größenordnung von OpenAI sollten Analysten keine Zeit damit verlieren, SQL-Semantik oder Query-Performance zu debuggen. Ihr Fokus sollte auf der Definition von Metriken, der Validierung von Annahmen und datenbasierten Entscheidungen liegen.

Schauen wir uns an, was unser Agent ist, wie er Kontext kuratiert und wie er sich selbst kontinuierlich verbessert.

Unser Agent wird mit GPT‑5.2 bereitgestellt und ist darauf ausgelegt, über OpenAIs Datenplattform zu schlussfolgern. Er ist dort verfügbar, wo Mitarbeiter ohnehin arbeiten: als Slack-Agent, über eine Weboberfläche, in IDEs, in der Codex CLI via MCP⁠(wird in einem neuen Fenster geöffnet) und direkt in OpenAIs interner ChatGPT‑App über einen MCP-Konnektor⁠(wird in einem neuen Fenster geöffnet).

Nutzer können komplexe, offene Fragen stellen, die normalerweise mehrere Runden manueller Exploration erfordern würden. Nehmen wir zum Beispiel diesen Prompt, der einen Testdatensatz nutzt: „Bei NYC-Taxifahrten: Welche Abhol-zu-Absetz-ZIP-Code-Paare sind am unzuverlässigsten, mit der größten Lücke zwischen typischen und Worst-Case-Reisezeiten, und wann tritt diese Variabilität auf?“

Der Agent übernimmt die Analyse von Anfang bis Ende – vom Verstehen der Frage über die Exploration der Daten und das Ausführen von Abfragen bis hin zur Synthese der Ergebnisse.

Eine der Superkräfte des Agenten ist seine Art zu schlussfolgern. Anstatt einem festen Skript zu folgen, bewertet der Agent seinen eigenen Fortschritt. Wenn ein Zwischenergebnis falsch aussieht (zum Beispiel wenn aufgrund eines falschen Joins oder Filters null Zeilen zurückkommen), untersucht der Agent, was schiefgelaufen ist, passt sein Vorgehen an und versucht es erneut. Während dieses Prozesses behält er den vollständigen Kontext und trägt Lern­ergebnisse zwischen den Schritten weiter. Dieser geschlossene, selbstlernende Prozess verlagert Iteration vom Nutzer in den Agenten selbst und ermöglicht schnellere Ergebnisse sowie durchgehend hochwertigere Analysen als manuelle Workflows.

Der Agent deckt den gesamten Analytics-Workflow ab: Daten entdecken, SQL ausführen sowie Notebooks und Reports veröffentlichen. Er versteht internes Unternehmenswissen, kann für externe Informationen im Web suchen und verbessert sich über die Zeit durch erlernte Nutzung und Erinnerungen.

Hochwertige Antworten hängen von reichhaltigem, präzisem Kontext ab. Ohne Kontext können selbst leistungsstarke Modelle falsche Ergebnisse liefern, etwa die Nutzerzahlen massiv falsch einschätzen oder interne Terminologie missverstehen.

Um diese Fehlermodi zu vermeiden, ist der Agent um mehrere Kontextebenen herum aufgebaut, die ihn in OpenAIs Daten und institutionellem Wissen verankern.

• Metadaten-Grundlage: Der Agent stützt sich auf Schema-Metadaten (Spaltennamen und Datentypen), um das Schreiben von SQL zu steuern, und nutzt Tabellen-Lineage (z. B. Beziehungen zwischen Upstream- und Downstream-Tabellen), um Kontext dafür zu liefern, wie verschiedene Tabellen zusammenhängen.
• Abfrageinferenz: Das Einlesen historischer Abfragen hilft dem Agenten zu verstehen, wie er eigene Abfragen schreiben sollte und welche Tabellen typischerweise miteinander verknüpft werden.

• Kuratierte Beschreibungen von Tabellen und Spalten, die von Fachexperten bereitgestellt werden und die Intention, Semantik, geschäftliche Bedeutung und bekannte Einschränkungen erfassen, die sich weder aus Schemata noch aus früheren Abfragen leicht ableiten lassen.

Metadaten allein reichen nicht aus. Um Tabellen wirklich auseinanderzuhalten, muss man verstehen, wie sie erstellt wurden und woher sie stammen.

• Durch die Ableitung einer Definition auf Code-Ebene baut der Agent ein tieferes Verständnis dafür auf, was die Daten tatsächlich enthalten. 
  • Nuancen darüber, was in der Tabelle gespeichert ist und wie es aus einem Analytics-Ereignis abgeleitet wird, liefern zusätzliche Informationen. Zum Beispiel kann das Kontext zur Eindeutigkeit von Werten geben, dazu, wie häufig die Tabellendaten aktualisiert werden, zum Umfang der Daten (z. B. ob die Tabelle bestimmte Felder ausschließt und welche Granularität sie hat) usw.
• Das schafft einen erweiterten Nutzungskontext, indem gezeigt wird, wie die Tabelle jenseits von SQL in Spark, Python und anderen Datensystemen verwendet wird.
• Das bedeutet, dass der Agent zwischen Tabellen unterscheiden kann, die ähnlich aussehen, sich aber in entscheidenden Punkten unterscheiden. So kann er zum Beispiel erkennen, ob eine Tabelle ausschließlich First-Party-ChatGPT‑Traffic enthält. Dieser Kontext wird außerdem automatisch aktualisiert, sodass er ohne manuelle Pflege aktuell bleibt.

• Der Agent kann auf Slack, Google Docs und Notion zugreifen, die zentralen Unternehmenskontext wie Launches, Zuverlässigkeitsvorfälle, interne Codenamen und Tools sowie die kanonischen Definitionen und Berechnungslogiken zentraler Kennzahlen erfassen.
• Diese Dokumente werden ingestiert, eingebettet und mit Metadaten und Berechtigungen gespeichert. Ein Retrieval-Service übernimmt zur Laufzeit Zugriffskontrolle und Caching und ermöglicht es dem Agenten, diese Informationen effizient und sicher einzubeziehen.

• Wenn der Agent Korrekturen erhält oder Nuancen zu bestimmten Datenfragen entdeckt, kann er diese Erkenntnisse für das nächste Mal speichern und sich so gemeinsam mit den Nutzern kontinuierlich verbessern. 
  • Infolgedessen beginnen künftige Antworten von einer präziseren Ausgangsbasis, statt immer wieder auf dieselben Probleme zu stoßen.
  • Ziel der Erinnerung ist es, nicht offensichtliche Korrekturen, Filter und Einschränkungen zu behalten und wiederzuverwenden, die für die Datenkorrektheit entscheidend sind, sich aber allein aus den anderen Ebenen nur schwer ableiten lassen.
  • In einem Fall wusste der Agent zum Beispiel nicht, wie er für ein bestimmtes Analytics-Experiment filtern sollte (er verließ sich auf den Abgleich mit einem spezifischen String, der in einem Experiment-Gate definiert war). Hier war die Erinnerung entscheidend, um korrekt zu filtern, statt unscharf per String-Matching vorzugehen.
• Wenn man dem Agenten eine Korrektur gibt oder er aus der Konversation eine Erkenntnis gewinnt, fordert er einen auf, diese Erinnerung für das nächste Mal zu speichern. 
  • Erinnerungen können auch manuell von Nutzern erstellt und bearbeitet werden.
  • Erinnerungen sind global und persönlich abgegrenzt, und das Tooling des Agenten macht es einfach, sie zu bearbeiten.

• Wenn es für eine Tabelle keinen vorherigen Kontext gibt oder vorhandene Informationen veraltet sind, kann der Agent Live-Abfragen an das Data Warehouse stellen, um die Tabelle direkt zu prüfen und abzufragen. Dadurch kann er Schemas validieren, die Daten in Echtzeit verstehen und entsprechend reagieren.
• Der Agent kann außerdem bei Bedarf mit anderen Data-Platform-Systemen (Metadata Service, Airflow, Spark) kommunizieren, um einen breiteren Datenkontext zu erhalten, der außerhalb des Warehouses existiert.

We run a daily offline pipeline that aggregates table usage, human annotations, and Codex-derived enrichment into a single, normalized representation. This enriched context is then converted into embeddings using the OpenAI embeddings API⁠(wird in einem neuen Fenster geöffnet) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(wird in einem neuen Fenster geöffnet) (RAG) instead of scanning raw metadata or logs. This makes table understanding fast and scalable, even across tens of thousands of tables, while keeping runtime latency predictable and low. Runtime queries are issued to our data warehouse live as needed.

Together, these layers ensure the agent’s reasoning is grounded in OpenAI’s data, code, and institutional knowledge, dramatically reducing errors and improving answer quality.

One-shot answers work when the problem is clear, but most questions aren’t. More often, arriving at the correct result requires back-and-forth refinement and some course correction.

The agent is built to behave like a teammate you can reason with. It’s a conversational, always-on and handles both quick answers and iterative exploration.

It carries over complete context across turns, so users can ask follow-up questions, adjust their intent, or change direction without restating everything. If the agent starts heading down the wrong path, users can interrupt mid-analysis and redirect it, just like working with a human collaborator who listens instead of plowing ahead.

When instructions are unclear or incomplete, the agent proactively asks clarifying questions. If no response is provided, it applies sensible defaults to make progress. For example, if a user asks about business growth with no date range specified, it may assume the last seven or 30 days. These priors allow it to stay responsive and non-blocking while still converging on the right outcome.

The result is an agent that works well both when you know exactly what you want (e.g., “Tell me about this table”) and just as strong when you’re exploring (e.g., “I’m seeing a dip here, can we break this down by customer type and timeframe?”). 

After rollout, we observed that users frequently ran the same analyses for routine repetitive work. To expedite this, the agent's workflows package recurring analyses into reusable instruction sets. Examples include workflows for weekly business reports and table validations. By encoding context and best practices once, workflows streamline repeat analyses and ensure consistent results across users.

Building an always-on, evolving agent means quality can drift just as easily as it can improve. Without a tight feedback loop, regressions are inevitable and invisible. The only way to scale capability without breaking trust is through systematic evaluation.

In this section, we’ll discuss how we leverage OpenAI’s Evals API⁠(wird in einem neuen Fenster geöffnet) to measure and protect the agent’s response quality.

Its Evals are built on curated sets of question-answer pairs. Each question targets an important metric or analytical pattern we care deeply about getting right, paired with a manually authored “golden” SQL query that produces the expected result. For each eval, we send the natural language question to its query-generation endpoint, execute the generated SQL, and compare the output against the result of the expected SQL.

Evaluation doesn’t rely on naive string matching. Generated SQL can differ syntactically while still being correct, and result sets may include extra columns that don’t materially affect the answer. To account for this, we compare both the SQL and the resulting data, and feed these signals into OpenAI’s Evals grader. The grader produces a final score along with an explanation, capturing both correctness and acceptable variation.

These evals are like unit tests that run continuously during development to identify regressions as canaries in production; this allows us to catch issues early and confidently iterate as the agent's capabilities expand.

Our agent plugs directly into OpenAI’s existing security and access-control model. It operates purely as an interface layer, inheriting and enforcing the same permissions and guardrails that govern OpenAI’s data. 

All of the agent’s access is strictly pass-through, meaning users can only query tables they already have permission to access. When access is missing, it flags this or falls back to alternative datasets the user is authorized to use.

Finally, it's built for transparency. Like any system, it can make mistakes. It exposes its reasoning process by summarizing assumptions and execution steps alongside each answer. When queries are executed, it links directly to the underlying results, allowing users to inspect raw data and verify every step of the analysis.

Building our agent from scratch surfaced practical lessons about how agents behave, where they struggle, and what actually makes them reliable at scale.

Early on, we exposed our full tool set to the agent, and quickly ran into problems with overlapping functionality. While this redundancy can be helpful for specific custom cases and is more obvious to a human when manually invoking, it’s confusing to agents. To reduce ambiguity and improve reliability, we restricted and consolidated certain tool calls.

We also discovered that highly prescriptive prompting degraded results. While many questions share a general analytical shape, the details vary enough that rigid instructions often pushed the agent down incorrect paths. By shifting to higher-level guidance and relying on GPT‑5’s reasoning to choose the appropriate execution path, the agent became more robust and produced better results.

Schemas and query history describe a table’s shape and usage, but its true meaning lives in the code that produces it. Pipeline logic captures assumptions, freshness guarantees, and business intent that never surface in SQL or metadata. By crawling the codebase with Codex, our agent understands how datasets are actually constructed and is able to better reason about what each table actually contains. It can answer “what’s in here” and “when can I use it” far more accurately than from warehouse signals alone. 

We’re constantly working to improve our agent by increasing its ability to handle ambiguous questions, improving its reliability and accuracy with stronger validations, and integrating it more deeply into workflows. We believe it should blend naturally into how people already work, instead of functioning like a separate tool.

While our tooling will keep benefiting from underlying improvements in agent reasoning, validation, and self-correction, our team’s mission remains the same: seamlessly deliver fast, trustworthy data analysis across OpenAI’s data ecosystem.