Inne i OpenAIs interne dataagent

Data driver hvordan systemer lærer, produkter utvikler seg, og hvordan selskaper tar beslutninger. Men det å få svar raskt, korrekt og med riktig kontekst er ofte vanskeligere enn det burde være. For å gjøre dette enklere etter hvert som OpenAI skalerer, bygde vi vår egen skreddersydde interne KI-dataagent som utforsker og resonerer over vår egen plattform.

Vår agent er et tilpasset, internt verktøy (ikke et eksternt tilbud), bygget spesielt rundt OpenAI sine data, tillatelser og arbeidsflyter. Vi viser hvordan vi bygde det og bruker det for å fremheve eksempler på de virkelige, innflytelsesrike måtene KI kan støtte det daglige arbeidet på tvers av teamene våre. OpenAI-verktøyene vi brukte til å bygge og kjøre det (Codex, vår GPT‑5 flaggskipmodell, Evals API⁠(åpnes i et nytt vindu) og Embeddings API⁠(åpnes i et nytt vindu)) er de samme verktøyene vi gjør tilgjengelige for utviklere overalt.

Vår dataagent lar ansatte gå fra spørsmål til innsikt på minutter, ikke dager. Dette senker terskelen for å hente ut data og utføre nyansert analyse på tvers av alle funksjoner, ikke bare av datateamet vårt. I dag støtter team på tvers av Engineering, Data Science, go-to-market, Finance og Research hos OpenAI seg på agenten for å svare på høyt prioriterte datasprøsmål. For eksempel kan det hjelpe deg med å svare på hvordan du evaluerer lanseringer og forstår forretningshelsen, alt gjennom det intuitive formatet av naturlig språk. Agenten kombinerer Codex-drevet kunnskap på tabellnivå med produkt- og organisasjonskontekst. Det kontinuerlig lærende minnesystemet betyr at det også forbedres med hver vending.

I dette innlegget skal vi bryte ned hvorfor vi trengte en skreddersydd AI-dataagent, hva som gjør dens kodeberikede datakontekst og selvlæring så nyttig, og hvilke lærdommer vi lærte underveis.

OpenAIs dataplattform betjener mer enn 3,5k interne brukere som jobber på tvers av Engineering, Product og Research, og omfatter over 600 petabyte med data på tvers av 70k datasett. I den størrelsen kan det å finne den rette tabellen være en av de mest tidkrevende delene av å utføre analyse.

Som en intern bruker uttrykte det:

“Vi har mange tabeller som er ganske like, og jeg bruker masse tid på å finne ut hvordan de er forskjellige og hvilke jeg skal bruke. Noen inkluderer utloggede brukere, noen gjør det ikke. "Noen har overlappende felt; det er vanskelig å si hva som er hva.”

Selv med de riktige tabellene valgt, kan det være utfordrende å produsere korrekte resultater. Analytikere må resonnere om tabelldata og tabellrelasjoner for å sikre at transformasjoner og filtre anvendes korrekt. Vanlige feilmønstre—mange-til-mange-tilkoblinger, filter pushdown-feil og ubehandlede nullverdier—kan stille gjøre resultatene ugyldige. På OpenAIs nivå bør analytikere ikke bruke tid på å feilsøke SQL-semantikk eller spørringsytelse: deres fokus bør være på å definere måleparametere, validere antakelser og ta datadrevne beslutninger.

La oss gå gjennom hva agenten vår er, hvordan den kuraterer kontekst, og hvordan den fortsetter å forbedre seg selv.

Vår agent drives av GPT‑5.2 og er designet for å resonnere over OpenAIs dataplattform. Den er tilgjengelig der ansatte allerede jobber: som en Slack-agent, via et nettgrensesnitt, inne i IDE-er, i Codex CLI via MCP⁠(åpnes i et nytt vindu), og direkte i OpenAI sin interne ChatGPT‑app gjennom en MCP-kobling⁠(åpnes i et nytt vindu).

Brukere kan stille komplekse, åpne spørsmål som vanligvis ville kreve flere runder med manuell utforsking. Ta dette eksempel-promptet, som bruker et testdatasett: “For NYC-taxiturer, hvilke henting-til-avlevering ZIP-par er de mest upålitelige, med det største gapet mellom typiske og verste fall-reisetider, og når oppstår den variasjonen?”

Agenten håndterer analysen fra start til slutt, fra å forstå spørsmålet til å utforske dataene, kjøre spørringer og syntetisere funn.

En av agentens superkrefter er hvordan den resonnerer seg gjennom problemer. I stedet for å følge et fast manus evaluerer agenten sin egen fremdrift. Hvis et mellomresultat ser feil ut (f.eks. hvis det har null rader på grunn av en feilaktig join eller et feilaktig filter), undersøker agenten hva som gikk galt, justerer tilnærmingen sin og prøver igjen. Gjennom hele denne prosessen beholder den full kontekst og tar med seg lærdom mellom trinnene. Denne lukkede, selvlærende prosessen flytter iterasjon fra brukeren til selve agenten, noe som muliggjør raskere resultater og konsekvent høyere kvalitet på analyser enn manuelle arbeidsflyter.

Agenten dekker hele analysearbeidsflyten: oppdager data, kjører SQL og publiserer notatbøker og rapporter. Den forstår intern kunnskap i selskapet, kan søke på nettet etter ekstern informasjon, og forbedrer seg over tid gjennom lært bruk og hukommelse.

Svar av høy kvalitet avhenger av rik og nøyaktig kontekst. Uten kontekst kan selv sterke modeller gi feil resultater, som å grovt feilestimere antall brukere eller feiltolke intern terminologi.

For å unngå disse feilmodusene er agenten bygget rundt flere lag med kontekst som forankrer den i OpenAI sine data og institusjonelle kunnskap.

• Metadataforankring: Agenten baserer seg på skjema-metadata (kolonnenavn og datatyper) for å informere SQL-skriving og bruker tabellavstamning (f.eks. oppstrøms- og nedstrøms tabellrelasjoner) for å gi kontekst om hvordan ulike tabeller henger sammen.
• Forespørselsinferens: Inntak av historiske forespørsler hjelper agenten med å forstå hvordan den kan skrive sine egne forespørsler og hvilke tabeller som vanligvis kobles sammen.

• Kuraterte beskrivelser av tabeller og kolonner levert av domeneeksperter, som fanger opp hensikt, semantikk, forretningsmessig betydning og kjente forbehold som ikke lett kan utledes fra skjemaer eller tidligere forespørsler.

Metadata i seg selv er ikke nok. For å virkelig kunne skille tabeller fra hverandre, må du forstå hvordan de ble opprettet og hvor de kommer fra.

• Ved å utlede en definisjon av en tabell på kodenivå, bygger agenten en dypere forståelse av hva dataene faktisk inneholder. 
  • Nyanser om hva som lagres i tabellen og hvordan det utledes fra en analytisk hendelse gir ekstra informasjon. For eksempel kan det gi kontekst om hvor unike verdiene er, hvor ofte tabelldataene oppdateres, omfanget av dataene (f.eks., hvis tabellen ekskluderer visse felt, har den dette detaljeringsnivået), osv.
• Dette gir en forbedret brukskontekst ved å vise hvordan tabellen brukes utover SQL i Spark, Python og andre datasystemer.
• Dette betyr at agenten kan skille mellom tabeller som ser like ut, men som er forskjellige på kritiske måter. For eksempel kan den fortelle om en tabell kun inkluderer førsteparts ChatGPT‑trafikk. Denne konteksten oppdateres også automatisk, slik at den forblir oppdatert uten behov for manuelt vedlikehold.

• Agenten kan få tilgang til Slack, Google Docs og Notion, som fanger opp kritisk bedriftskontekst som lanseringer, pålitelighetshendelser, interne kodenavn og verktøy, samt de kanoniske definisjonene og beregningslogikken for viktige måleparametere.
• Disse dokumentene importeres, integreres og lagres med metadata og tillatelser. En hentetjeneste håndterer tilgangskontroll og hurtigbufring under kjøring, slik at agenten effektivt og trygt kan hente inn denne informasjonen.

• Når agenten får korrigeringer eller oppdager nyanser i visse dataspørsmål, kan den lagre disse lærdommene til neste gang, slik at den hele tiden kan forbedre seg sammen med brukerne sine. 
  • Som et resultat starter fremtidige svar fra et mer presist utgangspunkt i stedet for å stadig møte de samme problemene.
  • Målet med minne er å beholde og gjenbruke ikke-åpenbare rettelser, filtre og begrensninger som er avgjørende for datakorrekthet, men vanskelige å utlede fra de andre lagene alene. 
  • For eksempel, i ett tilfelle, visste agenten ikke hvordan den skulle filtrere for et bestemt analyseeksperiment (det var avhengig av samsvar med en spesifikk streng definert i en eksperimentport). Minne var avgjørende viktig her for å sikre at det kunne filtrere korrekt, i stedet for å forsøke en uklar strengmatching.
• Når du gir agenten en korrigering eller når den finner noe å lære av samtalen din, vil den gi deg en prompt for å lagre det minnet til neste gang. 
  • Minner kan også opprettes og redigeres manuelt av brukere.
  • Minner er avgrenset på globalt og personlig nivå, og agentens verktøy gjør det enkelt å redigere dem.

• Når det ikke finnes noen tidligere kontekst for en tabell, eller når eksisterende informasjon er utdatert, kan agenten sende live spørringer til datavarehuset for å inspisere og forespørre tabellen direkte. Dette gjør at den kan validere skjemaer, forstå dataene i sanntid og svare deretter.
• Agenten kan også kommunisere med andre Data Platform-systemer (metadata service, Airflow, Spark) etter behov for å få en bredere datakontekst som finnes utenfor datalageret.

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⁠(åpnes i et nytt vindu) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(åpnes i et nytt vindu) (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⁠(åpnes i et nytt vindu) 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.