Unutar OpenAI-jevog internog agenta za podatke

Podaci omogućuju sustavima da uče, proizvodima da se razvijaju, a tvrtkama da donose odluke. Ali dobivanje odgovora brzo, točno i s pravim kontekstom često je teže nego što bi trebalo biti. Kako bismo ovo olakšali dok OpenAI bude rastao, izgradili smo vlastitog internog AI agenta za podatke koji istražuje i donosi zaključke na našoj vlastitoj platformi.

Naš agent je prilagođeni alat samo za internu upotrebu (nije vanjska ponuda), razvijen posebno za podatke, dozvole i radne tijekova OpenAI-ja. Pokazujemo kako smo ga razvili i kako ga upotrebljavamo kako bismo istaknuli primjere stvarnih, značajnih načina na koje umjetna inteligencija može podržati svakodnevni rad u našim timovima. Alati OpenAI-ja koje smo upotrebljavali za razvoj i pokretanje (Codex, naš vodeći model GPT‑5, Evals API⁠(otvara se u novom prozoru) i Embeddings API⁠(otvara se u novom prozoru)) isti su alati koje nudimo razvojnim inženjerima diljem svijeta.

Naš agent za podatke omogućuje zaposlenicima da od pitanja do uvida dođu u nekoliko minuta, a ne dana. Ovo snižava letvicu za prikupljanje podataka i detaljnu analizu u svim funkcijama, a ne samo našeg tima za podatke. Danas se timovi u inženjerstvu, podatkovnoj znanosti, strategiji izlaska na tržište, financijama i istraživanju u OpenAI-ju oslanjaju na agenta kako bi dobili odgovore na pitanja o podacima s velikim utjecajem. Na primjer, može vam pomoći da odgovorite na pitanje kako procijeniti lansiranja i razumjeti stanje poslovanja, sve putem intuitivnog formata prirodnog jezika. Agent kombinira znanje na razini tablice koje pokreće Codex s kontekstom proizvoda i organizacije. Njegov sustav memorije koja kontinuirano uči znači da se također poboljšava sa svakim korakom.

U ovoj objavi raščlanit ćemo zašto nam je bio potreban prilagođeni AI agent za podatke, što njegov kontekst podataka obogaćen kodom i samoučenje čini toliko korisnim te lekcije koje smo naučili putem.

OpenAI-jeva podatkovna platforma opslužuje više od 3,5 tisuća internih korisnika koji rade u inženjerstvu, proizvodima i istraživanju, obuhvaćajući preko 600 petabajta podataka u 70 tisuća skupova podataka. Pri toj veličini, samo pronalaženje odgovarajuće tablice može biti jedan od najzahtjevnijih dijelova analize.

Kako je rekao jedan od internih korisnika:

„Imamo mnogo tablica koje su prilično slične i trošim puno vremena pokušavajući shvatiti po čemu se razlikuju i koje koristiti. Neke uključuju odjavljene korisnike, a neke ne. Neka se polja preklapaju; teško je razaznati što je što.”

Čak i uz odabir ispravnih tablica, dobivanje ispravnih rezultata može biti izazovno. Analitičari moraju rasuđivati o podacima u tablicama i njihovim međusobnim odnosima kako bi osigurali ispravnu primjenu transformacija i filtara. Uobičajeni načini neuspjeha – spajanja mnogo-prema-mnogo, pogreške potiskivanja filtra i neobrađene null vrijednosti – mogu neprimjetno poništiti valjanost rezultata. Na razini OpenAI-ja analitičari ne bi trebali trošiti vrijeme na otklanjanje pogrešaka u semantici SQL-a ili izvedbi upita: njihov fokus trebao bi biti na definiranju metrika, provjeri pretpostavki i donošenju odluka temeljenih na podacima.

Prođimo kroz to što je naš agent, kako oblikuje kontekst i kako se kontinuirano samousavršava.

Naš agent pokreće model GPT‑5.2 i dizajniran je za rasuđivanje na OpenAI-ovoj podatkovnoj platformi. Dostupan je na mjestima na kojima zaposlenici već rade: kao Slack agent, putem web sučelja, unutar IDE-ova, u Codex CLI putem MCP-a⁠(otvara se u novom prozoru) i izravno u OpenAI-jevoj internoj aplikaciji ChatGPT putem MCP konektora⁠(otvara se u novom prozoru).

Korisnici mogu postavljati složena, otvorena pitanja koja bi obično zahtijevala više krugova ručnog istraživanja. Uzmimo ovaj primjer upita, koji se koristi testnim skupom podataka:„Za putovanja taksijem u New Yorku, koji su parovi ZIP-ova od mjesta preuzimanja do mjesta odredišta najnepouzdaniji, s najvećim razmakom između tipičnog i najgoreg slučaja vremena vožnje i kada se ta varijabilnost javlja?“

Agent provodi analizu od početka do kraja, od razumijevanja pitanja do istraživanja podataka, pokretanja upita i sažimanja nalaza.

Jedna od agentovih supermoći je način na koji rješava probleme. Umjesto da slijedi fiksni tekst, agent procjenjuje svoj napredak. Ako međurezultat izgleda pogrešno (npr. ako ima nula redaka zbog netočnog spajanja ili filtriranja), agent istražuje što je pošlo po zlu, prilagođava svoj pristup i pokušava ponovno. U cjelokupnom procesu zadržava puni kontekst i prenosi naučeno između koraka. Ovaj zatvoreni krug, samoučeći proces premješta iteraciju s korisnika na samog agenta, omogućujući brže rezultate i dosljedno kvalitetnije analize od ručnih radnih tijekova.

Agent pokriva cijeli analitički radni tijek: otkrivanje podataka, pokretanje SQL-a i objavljivanje bilježnica i izvješća. Razumije interno znanje tvrtke, može pretraživati vanjske informacije na webu i poboljšava se tijekom vremena kroz naučenu upotrebu i memoriju.

Visokokvalitetni odgovori ovise o bogatom i točnom kontekstu. Bez konteksta čak i snažni modeli mogu proizvesti pogrešne rezultate, poput općenito pogrešne procjene broja korisnika ili pogrešnog tumačenja interne terminologije.

Kako bi se izbjegli ovi načini neuspjeha, agent je razvijen oko više slojeva konteksta koji ga utemeljuju u podacima i institucionalnom znanju OpenAI-ja.

• Utemeljenje metapodataka: Agent se oslanja na metapodatke sheme (nazive stupaca i vrste podataka) za pisanje SQL-a i koristi porijeklo tablica (npr. odnose između uzvodnih i nizvodnih tablica) kako bi pružio kontekst o međusobnoj povezanosti različitih tablica.
• Zaključivanje upita: Unošenje povijesnih upita pomaže agentu da razumije kako pisati vlastite upite i koje se tablice obično spajaju.

• Prilagođeni opisi tablica i stupaca koje pružaju stručnjaci za domenu, obuhvaćajući namjenu, semantiku, poslovno značenje i poznata ograničenja koja se ne mogu lako zaključiti iz shema ili prošlih upita.

Sami metapodaci nisu dovoljni. Da biste doista razlikovali tablice, trebate razumjeti kako su stvorene i odakle potječu.

• Izradom definicije tablice na razini koda, agent stječe dublje razumijevanje stvarnog sadržaja podataka. 
  • Nijanse o tome što se pohranjuje u tablici i kako se izvodi iz analitičkog događaja pružaju dodatne informacije. Na primjer, može pružiti kontekst o jedinstvenosti vrijednosti, koliko se često ažuriraju podaci tablice, opsegu podataka (npr., ako tablica isključuje određena polja, ima ovu razinu detaljnosti) itd.
• Ovo pruža poboljšani kontekst upotrebe pokazujući kako se tablica upotrebljava ne samo u SQL-u, već i u Sparku, Pythonu i ostalim podatkovnim sustavima.
• To znači da agent može razlikovati tablice koje izgledaju slično, ali se razlikuju u ključnim aspektima. Na primjer, može utvrditi uključuje li tablica samo promet prve strane za ChatGPT. Ovaj se kontekst također automatski osvježava, tako da ostaje ažuran bez potrebe za ručnim održavanjem.

• Agent može pristupiti Slacku, Google Docsu i Notionu, koji bilježe ključni kontekst tvrtke, uključujući lansiranja, incidente pouzdanosti, interne kodne nazive i alate, te kanonske definicije i logiku izračuna za ključne metrike.
• Ovi se dokumenti unose, ugrađuju i pohranjuju s metapodacima i dopuštenjima. Usluga dohvaćanja upravlja kontrolom pristupa i predmemoriranjem tijekom izvršavanja, omogućujući agentu da učinkovito i sigurno preuzme te informacije.

• Kada agent primi ispravke ili otkrije detalje u vezi s određenim pitanjima o podacima, može pohraniti ta saznanja za sljedeći put, što mu omogućuje da se neprestano poboljšava zajedno s korisnicima. 
  • Kao rezultat, budući odgovori počinju s točnijom početnom osnovom, umjesto da se stalno susreću s istim problemima.
  • Cilj memorije je zadržati i ponovno upotrebljavati neočite ispravke, filtre i ograničenja koji su ključni za točnost podataka, ali ih je teško zaključiti samo iz ostalih slojeva. 
  • Na primjer, u jednom slučaju agent nije znao kako filtrirati određeni analitički eksperiment (oslanjao se na podudaranje s određenim nizom definiranim u ulazu eksperimenta). Memorija je ovdje bila presudno važna kako bi se osiguralo ispravno filtriranje, umjesto nejasnog pokušaja podudaranja s nizom.
• Kada agentu date ispravak ili kada pronađe nešto što je naučio iz vašeg razgovora, prikazat će vam upit da spremite tu memoriju za sljedeći put. 
  • Korisnici također mogu ručno stvarati i uređivati memorije.
  • Memorije su definirane na globalnoj i osobnoj razini, a alati agenta omogućuju njihovo jednostavno uređivanje.

• Kada ne postoji prethodni kontekst za tablicu ili kada su postojeće informacije zastarjele, agent može izdati upite uživo prema skladištu podataka kako bi pregledao tablicu i izravno postavljao upite. To mu omogućuje da provjerava valjanost shema, razumije podatke u stvarnom vremenu i odgovara u skladu s tim.
• Agent također može komunicirati s ostalim sustavima na Data Platform (usluga metapodataka, Airflow, Spark) prema potrebi kako bi dobio širi kontekst podataka koji postoji izvan skladišta.

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⁠(otvara se u novom prozoru) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(otvara se u novom prozoru) (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⁠(otvara se u novom prozoru) 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.