Sa loob ng in-house na data agent ng OpenAI

Pinapagana ng data kung paano natututo ang mga system, umuunlad ang mga produkto, at gumagawa ng mga desisyon ang mga kumpanya. Ngunit ang pagkuha ng mga sagot nang mabilis, tama, at may tamang konteksto ay kadalasang mas mahirap kaysa sa nararapat. Upang mas mapadali ito habang lumalaki ang OpenAI, bumuo kami ng sarili naming bespoke na in-house AI data agent na nag-e-explore at nagre-reason sa aming sariling platform.

Ang aming agent ay isang custom na internal-only tool (hindi isang external na alok), na binuo partikular sa paligid ng data, mga pahintulot, at mga daloy ng trabaho ng OpenAI. Ipinapakita namin kung paano namin ito binuo at ginagamit upang makatulong na maipakita ang mga halimbawa ng mga tunay at makabuluhang paraan kung paano masusuportahan ng AI ang pang-araw-araw na trabaho sa iba’t ibang naming team. Ang mga tool ng OpenAI na ginamit namin upang buuin at patakbuhin ito (Codex, ang aming flagship na modelo na GPT‑5, ang Evals API⁠(magbubukas sa bagong window), at ang Embeddings API⁠(magbubukas sa bagong window)) ay ang parehong mga tool na ginagawa naming available sa mga developer saanman.

Ang aming data agent ay nagpapahintulot sa mga empleyado na lumipat mula sa tanong patungo sa insight sa loob ng ilang minuto, hindi araw. Pinapababa nito ang hadlang sa paghugot ng data at masinsing pagsusuri sa lahat ng tungkulin, hindi lamang ng aming data team. Ngayon, umaasa ang mga team ng OpenAI sa Engineering, Data Science, Go-To-Market, Finance, at Research sa sa agent upang sagutin ang mga tanong na may malaking epekto sa data. Halimbawa, makakatulong ito na sagutin kung paano suriin ang mga paglulunsad at maunawaan ang kapakanan ng negosyo, lahat sa pamamagitan ng intuitive na format ng natural na wika. Pinagsasama ng agent ang kaalamang pinapagana ng Codex sa antas ng talahanayan at ang konteksto ng produkto at organisasyon. Ang patuloy na natututo nitong memory system ay nangangahulugang bumubuti rin ito sa bawat turn.

Sa post na ito, tatalakayin natin kung bakit kailangan namin ng isang bespoke na AI data agent, kung ano ang dahilan kung bakit napakakapaki-pakinabang ng code-enriched na data context at self-learning nito, at ang mga aral na natutunan namin sa buong proseso.

Ang data platform ng OpenAI ay nagseserbisyo sa mahigit 3.5k na internal na user na nagtatrabaho sa Engineering, Product, at Research, na sumasaklaw sa mahigit 600 petabytes ng data sa 70k na dataset. Sa laking iyon, ang simpleng paghahanap ng tamang talahanayan ay maaaring isa sa mga pinakamatagal na bahagi ng paggawa ng pagsusuri.

Gaya ng sinabi ng isang internal na user:

“Marami kaming mga talahanayan na halos magkakahawig, at napakaraming oras ang ginugugol ko sa pagsubok na alamin kung paano sila nagkakaiba at kung alin ang dapat gamitin. Ang ilan ay kasama ang mga naka-log out na user, ang ilan ay hindi. May ilang nag-o-overlap na mga field; mahirap matukoy kung alin ang alin.”

Kahit na napili na ang mga tamang table, maaari pa ring maging mahirap ang pagbuo ng mga tamang resulta. Dapat magbigay-katwiran ang mga analyst tungkol sa data ng talahanayan at mga ugnayan ng talahanayan upang matiyak na ang mga pagbabagong-anyo at mga filter ay naia-apply nang tama. Ang mga karaniwang mode ng pagkabigo—mga many-to-many join, mga error sa filter pushdown, at mga hindi na-handle na null—ay maaaring tahimik na magpawalang-bisa ng mga resulta. Sa saklaw ng OpenAI, hindi dapat mag-aksaya ng oras ang mga analyst sa pag-debug ng mga semantika ng SQL o performance ng query; dapat silang tumuon sa pagtukoy ng mga sukatan, pag-validate ng mga palagay, at paggawa ng mga desisyong nakabatay sa data.

Tingnan natin kung ano ang aming agent, kung paano ito nagku-curate ng konteksto, at kung paano ito patuloy na nagpapahusay sa sarili.

Ang aming agent ay pinapagana ng GPT‑5.2 at idinisenyo upang mangatwiran sa data platform ng OpenAI. Magagamit ito saanman nagtatrabaho na ang mga empleyado: bilang isang Slack agent, sa pamamagitan ng web interface, sa loob ng mga IDE, sa Codex CLI sa pamamagitan ng MCP⁠(magbubukas sa bagong window), at direkta sa internal na ChatGPT app ng OpenAI sa pamamagitan ng isang MCP connector⁠(magbubukas sa bagong window).

Maaaring magtanong ang mga user ng mga kumplikado at bukas na tanong na karaniwang mangangailangan ng maraming round ng manual na pag-explore. Gamitin ang halimbawang prompt na ito, na gumagamit ng test data set: “Para sa mga biyahe ng NYC taxi, aling mga pares ng ZIP mula sa pickup hanggang dropoff ang pinaka-hindi maaasahan, na may pinakamalaking agwat sa pagitan ng karaniwan at pinakamasamang kaso ng tagal ng biyahe, at kailan nagaganap ang pagkakaiba-ibang iyon?”

Pinangangasiwaan ng agent ang pagsusuri mula simula hanggang wakas, mula sa pag-unawa sa tanong hanggang sa pag-explore ng datos, pagpapatakbo ng mga query, at pagsasama-sama ng mga natuklasan.

Isa sa mga superpower ng agent ay ang kakayahan nitong magbigay ng pangangatwiran sa mga problema. Sa halip na sumunod sa isang nakapirming script, sinusuri ng agent ang sarili nitong progreso. Kung mukhang mali ang isang intermediate na resulta (halimbawa, kung wala itong mga row dahil sa maling join o filter), iniimbestigahan ng agent kung ano ang naging mali, inaayos ang kanyang pamamaraan, at sinusubukang muli. Sa buong prosesong ito, pinananatili nito ang buong konteksto at dinadala ang mga natutunan pasulong sa pagitan ng mga hakbang. Ang closed-loop, self-learning na prosesong ito ay naglilipat ng pag-uulit mula sa user patungo sa mismong agent, na nagpapahintulot ng mas mabilis na mga resulta at palagiang mas mataas na kalidad ng mga pagsusuri kumpara sa mga manual na daloy ng trabaho.

Sinasaklaw ng agent ang buong daloy ng trabaho ng analytics: pagtuklas ng data, pagpapatakbo ng SQL, at pag-publish ng mga notebook at ulat. Nauunawaan nito ang internal na kaalaman sa kumpanya, maaari itong maghanap sa web para sa external na impormasyon, at bumubuti sa paglipas ng panahon sa pamamagitan ng natutunang paggamit at memory.

Ang mga de-kalidad na sagot ay nakasalalay sa mayaman at tumpak na konteksto. Kung walang konteksto, kahit ang mga malalakas na modelo ay maaaring magbigay ng maling resulta, tulad ng labis na maling pagtatantiya sa bilang ng mga user o maling pag-unawa sa internal na terminolohiya.

Upang maiwasan ang mga ganitong failure mode, ang agent ay binuo sa paligid ng maraming layer ng konteksto na nag-uugat dito sa data at institusyonal na kaalaman ng OpenAI.

• Metadata grounding: Umaasa ang agent sa schema metadata (mga pangalan ng column at mga uri ng data) upang gabayan ang pagsulat ng SQL at gumagamit ng table lineage (hal., mga ugnayan ng upstream at downstream na talahanayan) upang magbigay ng konteksto kung paano magkakaugnay ang iba’t ibang talahanayan.
• Query inference: Ang pag-ingest ng mga historikal na query ay tumutulong sa agent na maunawaan kung paano isulat ang sarili nitong mga query at kung aling mga talahanayan ang karaniwang pinagsasama.

• Mga na-curate na paglalarawan ng mga talahanayan at column na ibinigay ng mga eksperto sa domain, na naglalarawan ng layunin, semantika, kahulugang pang-negosyo, at mga kilalang caveat na hindi madaling mahinuha mula sa mga schema o mga nakaraang query.

Hindi sapat ang metadata lamang. Para talagang partikular na matukoy ang mga talahanayan, kailangan ninyong maintindihan kung paano sila ginawa at kung saan sila nagmula.

• Sa pamamagitan ng pagkuha ng depinisyon sa antas ng code ng isang talahanayan, bumubuo ang agent ng mas malalim na pag-unawa sa aktwal na nilalaman ng data. 
  • Ang mga detalye kung ano ang naka-store sa talahanayan at kung paano ito nakuha mula sa isang analytics event ay nagbibigay ng karagdagang impormasyon. Halimbawa, maaari itong magbigay ng konteksto tungkol sa pagiging natatangi ng mga value, kung gaano kadalas ina-update ang data ng talahanayan, ang saklaw ng data (hal., kung hindi kasama sa talahanayan ang ilang field, mayroon itong ganitong antas ng granularity), atbp.
• Nagbibigay ito ng pinahusay na konteksto ng paggamit sa pamamagitan ng pagpapakita kung paano ginagamit ang talahanayan hindi lamang sa SQL kundi pati na rin sa Spark, Python, at iba pang data system.
• Ibig sabihin nito, kayang matukoy ng agent ang pagkakaiba sa pagitan ng mga talahanayan na magkahawig ang hitsura ngunit nagkakaiba sa mahahalagang aspeto. Halimbawa, masasabi nito kung ang isang talahanayan ay naglalaman lamang ng first-party na trapiko ng ChatGPT. Awtomatiko ring nire-refresh ang kontekstong ito, kaya nananatili itong napapanahon nang walang pangangailangan para sa mano-manong maintenance.

• Maaaring ma-access ng agent ang Slack, Google Docs, at Notion, na kumukuha ng mahahalagang konteksto ng kumpanya tulad ng mga paglulunsad, mga insidente sa pagiging maaasahan, mga internal na codename at tool, at ang mga kanonikal na depinisyon at lohika ng pagkukuwenta para sa mga pangunahing sukatan.
• Ang mga dokumentong ito ay ini-ingest, ine-embed, at sino-store kasama ang metadata at mga pahintulot. Ang retrieval service ay namamahala sa access control at caching sa runtime, na nagpapahintulot sa agent na mahusay at ligtas na makuha ang impormasyong ito.

• Kapag binibigyan ang agent ng mga pagwawasto o nakakatuklas ng mga detalye tungkol sa ilang tanong sa data, nagagawa nitong i-save ang mga natutunan para sa susunod, na nagbibigay-daan dito na patuloy na bumuti kasama ang mga user nito. 
  • Bilang resulta, ang mga sagot sa hinaharap ay magsisimula mula sa mas tumpak na baseline sa halip na paulit-ulit na makaharap ang parehong mga isyu.
  • Ang layunin ng memory ay panatilihin at muling gamitin ang mga hindi halatang pagwawasto, filter, at limitasyon na kritikal para sa pagiging tama ng data ngunit mahirap mahinuha mula lamang sa iba pang mga layer. 
  • Halimbawa, sa isang kaso, hindi alam ng agent kung paano mag-filter para sa isang partikular na eksperimento sa analytics (umasa ito sa pagtutugma laban sa isang tiyak na string na tinukoy sa isang experiment gate). Napakahalaga ng memory dito upang matiyak na makakapag-filter ito nang tama, sa halip na malabong subukang mag-string match.
• Kapag binigyan ninyo ang agent ng pagwawasto o kapag may natutunan ito mula sa inyong pag-uusap, magpo-prompt ito sa inyo na i-save ang memory na iyon para sa susunod. 
  • Maaari ding mano-manong likhain at i-edit ng mga user ang mga memory.
  • Ang mga memory ay may saklaw sa pandaigdigan at personal na antas, at pinapadali ng tooling ng agent na i-edit ang mga ito.

• Kapag walang umiiral na naunang konteksto para sa isang talahanayan o kapag luma na ang umiiral na impormasyon, maaaring mag-isyu ang agent ng mga live na query sa data warehouse upang siyasatin at direktang i-query ang talahanayan. Nagbibigay-daan ito upang ma-validate ang mga schema, maunawaan ang data nang real-time, at tumugon nang naaayon.
• Nagagawa rin ng agent na makipag-usap sa iba pang mga system ng Data Platform (metadata service, Airflow, Spark) kung kinakailangan upang makakuha ng mas malawak na konteksto ng data na umiiral sa labas ng warehouse.

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⁠(magbubukas sa bagong window) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(magbubukas sa bagong window) (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⁠(magbubukas sa bagong window) 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.