Inuti OpenAI:s interna dataagent

Data driver hur system lär sig, hur produkter utvecklas och hur företag fattar beslut. Men att få svar snabbt, korrekt och i rätt sammanhang är ofta svårare än det borde vara. I takt med att OpenAI skalar har vi byggt vår egen skräddarsydda interna AI-dataagent som utforskar och resonerar över vår egen plattform.

Vår agent är ett anpassat, endast internt verktyg (inte ett externt erbjudande), byggt specifikt kring OpenAI:s data, behörigheter och arbetsflöden. Vi visar hur vi byggde och använder det för att lyfta fram exempel på de verkliga och betydelsefulla sätten som AI kan stödja det dagliga arbetet i våra team. De OpenAI-verktyg som vi använde för att bygga och köra det (Codex, vår flaggskeppsmodell GPT‑5, Evals API⁠(öppnas i ett nytt fönster) och Embeddings API⁠(öppnas i ett nytt fönster)) är samma verktyg som vi gör tillgängliga för utvecklare överallt.

Vår dataagent låter medarbetare gå från fråga till insikt på några minuter, inte dagar. Det sänker tröskeln för att samla in data och utföra nyanserad analys inom alla funktioner, inte bara av vårt datateam. Idag förlitar sig team inom teknik, datavetenskap, marknadsstrategi, ekonomi och forskning på OpenAI på agenten för att besvara viktiga frågor om data. Det kan till exempel hjälpa till att svara på hur man utvärderar lanseringar och förstår företagets hälsa, allt genom det intuitiva formatet med naturligt språk. Agenten kombinerar Codex-driven kunskap på tabellnivå med produkt- och organisationskontext. Dess ständigt lärande minnessystem innebär att det också förbättras med varje omgång.

I det här inlägget går vi igenom varför vi behövde en skräddarsydd AI-dataagent, vad som gör dess kodberikade datakontext och självlärande så användbart samt vilka lärdomar vi drog längs vägen.

OpenAI:s dataplattform betjänar fler än 3,5k interna användare som arbetar inom teknik, produkt och forskning, och hanterar över 600 petabyte data i 70k dataset. Vid den storleken kan det vara en av de mest tidskrävande delarna av analysarbetet att bara hitta rätt tabell.

Som en intern användare uttryckte det:

”Vi har många tabeller som är ganska lika varandra, och jag lägger massor av tid på att försöka lista ut hur de skiljer sig åt och vilken jag ska använda. Vissa inkluderar utloggade användare, andra gör det inte. Vissa har överlappande fält – det är svårt att avgöra vad som är vad.

Även om rätt tabeller har valts kan det vara svårt att få fram korrekta resultat. Analytiker måste analysera tabelldata och tabellrelationer för att säkerställa att transformationer och filter tillämpas korrekt. Vanliga fellägen – många-till-många-sammanfogningar, filterpushdown-fel och ohanterade nollvärden – kan tyst ogiltigförklara resultaten. Med OpenAI:s storlek bör analytiker inte behöva lägga tid på att felsöka SQL-semantik eller frågeprestanda: deras fokus bör ligga på att definiera mätvärden, validera antaganden och fatta datadrivna beslut.

Låt oss gå igenom vad vår agent är, hur den skapar kontext och hur den fortsätter att förbättra sig själv.

Vår agent drivs av GPT‑5.2 och är utformad för att resonera över OpenAI:s dataplattform. Den är tillgänglig där medarbetare redan arbetar: som en Slack-agent, via ett webbgränssnitt, i IDE:er, i Codex CLI via MCP⁠(öppnas i ett nytt fönster) och direkt i OpenAI:s interna ChatGPT‑app genom en MCP-anslutning⁠(öppnas i ett nytt fönster).

Användare kan ställa komplexa, öppna frågor som normalt skulle kräva flera omgångar av manuell utforskning. Ta denna exempelprompt, som använder en testdatauppsättning: ”Vilka postnummerpar för upphämtning och avlämning är mest opålitliga för taxiresor i New York, med den största skillnaden mellan typiska och värsta fallets restider, och när uppstår denna variation?”

Agenten hanterar analysen från början till slut, från att förstå frågan till att utforska data, köra frågor och sammanställa resultaten.

En av agentens superkrafter är dess förmåga att resonera sig igenom problem. I stället för att följa ett fast manus utvärderar agenten sina egna framsteg. Om ett mellanresultat ser felaktigt ut (t.ex. om det har noll rader på grund av en felaktig sammanfogning eller filtrering) undersöker agenten vad som gick fel, justerar sin metod och försöker igen. Under hela processen behåller den fullständig kontext och överför lärdomar mellan stegen. Denna slutna, självlärande process flyttar iterationen från användaren till agenten själv, vilket möjliggör snabbare resultat och analyser av genomgående högre kvalitet än manuella arbetsflöden.

Agenten täcker hela analysarbetsflödet: upptäcka data, köra SQL och publicera anteckningsböcker och rapporter. Den förstår intern företagskunskap, kan söka på webben efter extern information och förbättras med tiden genom inlärd användning och minne.

Svar av hög kvalitet beror på rikt, korrekt sammanhang. Utan kontext kan även starka modeller ge felaktiga resultat, som att kraftigt felbedöma användarantal eller misstolka intern terminologi.

Agenten är uppbyggd kring flera lager av kontext som förankrar den i OpenAI:s data och institutionella kunskap för att undvika dessa feltyper.

• Metadatabaserad förankring: Agenten förlitar sig på schemametadata (kolumnnamn och datatyper) för att informera SQL-skrivning och använder tabelllinjering (t.ex. uppströms- och nedströmsrelationer mellan tabeller) för att ge kontext kring hur olika tabeller hänger samman.
• Frågeinferens: Genom att ta in historiska frågor lär sig agenten hur den ska skriva egna frågor och vilka tabeller som vanligtvis kopplas samman.

• Sammanfattande beskrivningar av tabeller och kolumner som tillhandahålls av domänexperter, som fångar upp avsikt, semantik, affärsmässig betydelse och kända förbehåll som inte lätt kan utläsas ur scheman eller tidigare frågor.

Metadata räcker inte. Att verkligen kunna skilja tabeller åt kräver att man förstår hur de skapades och var de har sitt ursprung.

• Genom att härleda en definition av en tabell på kodnivå får agenten en djupare förståelse för vad data faktiskt innehåller. 
  • Nyanser om vad som lagras i tabellen och hur det härleds från en analyshändelse ger extra information. Till exempel kan den ge kontext om värdens unikhet, hur ofta tabelldata uppdateras, datats omfattning (t.ex. om tabellen exkluderar vissa fält innebär det denna granularitetsnivå) med mera.
• Detta ger ett förbättrat användningssammanhang genom att visa hur tabellen används utöver SQL i Spark, Python och andra datasystem.
• Detta innebär att agenten kan skilja mellan tabeller som ser likadana ut men som skiljer sig åt på viktiga punkter. Det kan till exempel avgöra om en tabell endast innehåller förstahands-ChatGPT‑trafik. Denna kontext uppdateras också automatiskt, så den förblir aktuell utan behov av manuell underhåll.

• Agenten har tillgång till Slack, Google Docs och Notion, som samlar in viktig information om företaget, såsom lanseringar, tillförlitlighetsincidenter, interna kodnamn och verktyg, samt kanoniska definitioner och beräkningslogik för viktiga mätvärden.
• Dessa dokument importeras, bäddas in och lagras tillsammans med metadata och behörigheter. En hämtningstjänst hanterar åtkomstkontroll och cachelagring vid körning, vilket gör det möjligt för agenten att hämta denna information på ett effektivt och säkert sätt.

• När agenten får korrigeringar eller upptäcker nyanser i vissa datafrågor kan den spara dessa lärdomar till nästa gång, vilket gör att den ständigt kan förbättras tillsammans med sina användare. 
  • Som ett resultat av detta utgår framtida svar från en mer korrekt utgångspunkt istället för att upprepade gånger stöta på samma problem.
  • Målet med minnet är att behålla och återanvända icke-uppenbara korrigeringar, filter och begränsningar som är avgörande för datakorrektheten men svåra att utläsa från de andra lagren ensamma. 
  • I ett fall visste agenten till exempel inte hur man filtrerar för ett visst analysförsök (det förlitade sig på matchning mot en specifik sträng som definierats i en försöksgrind). Minnet var avgörande här för att säkerställa att det kunde filtrera korrekt, istället för att försöka matcha strängar på ett oskarpt sätt.
• När du ger agenten en korrigering eller när den lär sig något från din konversation, kommer den att uppmana dig att spara det minnet till nästa gång. 
  • Minnen kan också skapas och redigeras manuellt av användare.
  • Minnena omfattar både globala och personliga nivåer, och agentens verktyg gör det enkelt att redigera dem.

• När det inte finns något tidigare sammanhang för en tabell eller när befintlig information är inaktuell, kan agenten skicka live-frågor till datalagret för att inspektera och fråga tabellen direkt. Detta möjliggör validering av scheman, förståelse av data i realtid och att svara därefter.
• Agenten kan även interagera med andra system inom dataplattformen (metadatatjänst, Airflow, Spark) vid behov för att inhämta bredare datakontext som finns utanför datalagret.

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⁠(öppnas i ett nytt fönster) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(öppnas i ett nytt fönster) (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⁠(öppnas i ett nytt fönster) 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.