Di dalam agen data internal OpenAI

Data menggerakkan bagaimana sistem belajar, produk berkembang, dan bagaimana perusahaan mengambil keputusan. Namun, mendapatkan jawaban dengan cepat, benar, dan dengan konteks yang tepat sering kali lebih sulit daripada yang seharusnya. Untuk mempermudah hal ini seiring OpenAI meningkatkan skala, kami membangun agen data AI internal khusus buatan kami sendiri yang mengeksplorasi dan bernalar di atas platform kami sendiri.

Agen kami adalah alat kustom yang hanya untuk penggunaan internal (bukan penawaran eksternal), yang dibangun secara khusus berdasarkan data, izin, dan alur kerja OpenAI. Kami menunjukkan bagaimana kami membangun dan menggunakannya untuk membantu menampilkan contoh nyata dan berdampak tentang bagaimana AI dapat mendukung pekerjaan sehari-hari di seluruh tim kami. Alat OpenAI yang kami gunakan untuk membangun dan menjalankannya (Codex, model unggulan GPT‑5 kami, API Evals⁠(terbuka di jendela baru), dan API Embeddings⁠(terbuka di jendela baru)) adalah alat yang sama yang kami sediakan untuk pengembang di mana saja.

Agen data kami memungkinkan para karyawan beralih dari pertanyaan ke wawasan dalam hitungan menit, bukan dalam hitungan hari. Ini menurunkan hambatan untuk mengumpulkan data dan melakukan analisis yang mendalam di seluruh fungsi, bukan hanya oleh tim data kami. Saat ini, tim di seluruh Teknik, Ilmu Data, Go-To-Market, Keuangan, dan Riset di OpenAI mengandalkan agen untuk menjawab pertanyaan data yang berdampak besar. Sebagai contoh, sistem ini dapat membantu menjawab cara mengevaluasi peluncuran produk dan memahami kesehatan bisnis, semuanya melalui format yang intuitif. Agen menggabungkan pengetahuan tingkat tabel yang didukung oleh Codex dengan konteks produk dan organisasi. Sistem memori yang terus belajar berarti sistem ini juga meningkat dengan setiap interaksi.

Dalam postingan ini, kami akan menjelaskan mengapa kami memerlukan agen data AI yang dirancang khusus, apa yang membuat konteks data yang diperkaya kode dan pembelajaran mandirinya sangat berguna, serta pelajaran yang kami pelajari sepanjang perjalanan.

Platform data OpenAI melayani lebih dari 3.500 pengguna internal yang bekerja di bidang Teknik, Produk, dan Riset, mencakup lebih dari 600 petabyte data di 70.000 kumpulan data. Pada ukuran tersebut, sekadar menemukan tabel yang tepat dapat menjadi salah satu bagian yang paling memakan waktu dalam melakukan analisis.

Seperti yang diungkapkan oleh salah satu pengguna internal:

“Kami memiliki banyak tabel yang cukup mirip, dan saya menghabiskan banyak waktu untuk mencoba mencari tahu apa perbedaannya dan yang mana yang harus digunakan. Beberapa menyertakan pengguna yang telah keluar, beberapa tidak. Beberapa memiliki bidang yang tumpang tindih; sulit untuk mengetahui mana yang mana.”

Bahkan dengan tabel yang benar telah dipilih, menghasilkan hasil yang benar bisa menjadi tantangan. Para analis harus menalar tentang data tabel dan hubungan tabel untuk memastikan transformasi dan filter diterapkan dengan benar. Mode kegagalan umum—join many-to-many, kesalahan filter pushdown, dan null yang tidak ditangani—dapat secara diam-diam membuat hasil tidak valid. Pada skala OpenAI, para analis seharusnya tidak perlu menghabiskan waktu untuk men-debug semantik SQL atau kinerja kueri: fokus mereka seharusnya pada mendefinisikan metrik, memvalidasi asumsi, dan membuat keputusan berbasis data.

Mari kita bahas apa itu agen kami, bagaimana agen tersebut mengkurasi konteks, dan bagaimana agen tersebut terus memperbaiki diri.

Agen kami didukung oleh GPT‑5.2 dan dirancang untuk melakukan penalaran pada platform data OpenAI. Tersedia di mana pun karyawan sudah bekerja: sebagai agen Slack, melalui antarmuka web, di dalam IDE, di Codex CLI melalui MCP⁠(terbuka di jendela baru), dan langsung di aplikasi ChatGPT internal OpenAI melalui konektor MCP⁠(terbuka di jendela baru).

Pengguna dapat mengajukan pertanyaan kompleks dan terbuka yang biasanya memerlukan beberapa putaran eksplorasi manual. Ambillah contoh prompt ini, yang menggunakan kumpulan data uji: “Untuk perjalanan taksi NYC, pasangan ZIP penjemputan-ke-pengantaran mana yang paling tidak dapat diandalkan, dengan kesenjangan terbesar antara waktu tempuh rata-rata dan skenario terburuk, dan kapan variabilitas itu terjadi?”

Agen menangani analisis secara menyeluruh, mulai dari memahami pertanyaan hingga mengeksplorasi data, menjalankan kueri, dan mensintesis temuan.

Salah satu kekuatan super agen adalah cara ia menalar dalam menyelesaikan masalah. Alih-alih mengikuti skrip yang tetap, agen mengevaluasi kemajuannya sendiri. Jika hasil perantara terlihat salah (misalnya, jika hasilnya memiliki nol baris karena penggabungan atau penyaringan yang tidak benar), agen menyelidiki apa yang salah, menyesuaikan pendekatannya, dan mencoba lagi. Sepanjang proses ini, ia mempertahankan konteks penuh, dan membawa pembelajaran ke depan di antara langkah-langkah. Proses loop tertutup dan belajar mandiri ini mengalihkan iterasi dari pengguna ke dalam agen itu sendiri, memungkinkan hasil yang lebih cepat dan analisis yang secara konsisten lebih berkualitas tinggi dibandingkan alur kerja manual.

Agen mencakup seluruh alur kerja analitik: menemukan data, menjalankan SQL, dan menerbitkan notebook serta laporan. Selain memahami konteks internal perusahaan, ia juga bisa mencari informasi eksternal di web dan semakin cerdas lewat pemakaian dan memori yang dipelajarinya.

Jawaban berkualitas tinggi bergantung pada konteks yang kaya dan akurat. Tanpa konteks, bahkan model yang kuat pun dapat menghasilkan hasil yang salah, seperti salah memperkirakan jumlah pengguna secara signifikan atau salah menafsirkan istilah internal.

Untuk menghindari mode kegagalan ini, agen dibangun di sekitar berbagai lapisan konteks yang menghubungkannya dengan data dan pengetahuan kelembagaan OpenAI.

• Landasan metadata: Agen mengandalkan metadata skema (nama kolom dan tipe data) untuk menginformasikan penulisan SQL dan menggunakan silsilah tabel (misalnya, hubungan tabel hulu dan hilir) untuk memberikan konteks tentang bagaimana tabel yang berbeda saling terkait.
• Inferensi kueri: Mengimpor kueri historis membantu agen memahami cara menulis kuerinya sendiri dan tabel mana yang biasanya digabungkan.

• Deskripsi terkurasi dari tabel dan kolom yang disediakan oleh pakar domain, menangkap niat, semantik, makna bisnis, dan catatan penting yang diketahui yang tidak mudah disimpulkan dari skema atau kueri sebelumnya.

Metadata saja tidaklah cukup. Untuk benar-benar membedakan tabel, Anda perlu memahami bagaimana tabel tersebut dibuat dan dari mana asalnya.

• Dengan menyusun definisi tingkat kode dari sebuah tabel, agen membangun pemahaman yang lebih mendalam tentang apa yang sebenarnya terkandung dalam data. 
  • Nuansa tentang apa yang disimpan dalam tabel dan bagaimana hal itu diturunkan dari peristiwa analitik memberikan informasi tambahan. Misalnya, ini dapat memberikan konteks tentang keunikan nilai, seberapa sering data tabel diperbarui, ruang lingkup data (misalnya, jika tabel mengecualikan bidang tertentu, tabel memiliki tingkat granularitas ini), dan lain-lain.
• Ini memberikan konteks penggunaan yang lebih mendalam dengan menunjukkan bagaimana tabel digunakan di luar SQL dalam Spark, Python, dan sistem data lainnya.
• Ini berarti bahwa agen dapat membedakan antara tabel yang tampak serupa tetapi berbeda dalam cara-cara yang penting. Sebagai contoh, ini dapat menentukan apakah sebuah tabel hanya menyertakan lalu lintas ChatGPT pihak pertama. Konteks ini juga diperbarui secara otomatis, sehingga tetap mutakhir tanpa pemeliharaan manual.

• Agen dapat mengakses Slack, Google Docs, dan Notion, yang menangkap konteks penting perusahaan seperti peluncuran, insiden keandalan, nama kode dan alat internal, serta definisi kanonis dan logika komputasi untuk metrik utama.
• Dokumen-dokumen ini diolah, disematkan, dan disimpan dengan metadata dan izin. Layanan pengambilan menangani kontrol akses dan caching saat runtime, memungkinkan agen untuk menarik informasi ini secara efisien dan aman.

• Ketika agen menerima koreksi atau menemukan nuansa baru dalam pertanyaan data tertentu, ia dapat menyimpan pembelajaran tersebut untuk digunakan di lain waktu, sehingga terus meningkatkan kemampuannya bersama para pengguna. 
  • Sebagai hasilnya, jawaban di masa depan dimulai dari dasar yang lebih akurat, daripada terus-menerus menghadapi masalah yang sama.
  • Tujuan memori adalah untuk mempertahankan dan menggunakan kembali koreksi, filter, dan batasan yang tidak terlihat secara gamblang yang sangat penting untuk ketepatan data tetapi sulit disimpulkan hanya dari lapisan lainnya saja. 
  • Sebagai contoh, dalam satu kasus, agen tidak tahu cara memfilter untuk eksperimen analitik tertentu (agen tersebut bergantung pada pencocokan terhadap string spesifik yang didefinisikan dalam gerbang eksperimen). Memori sangat penting di sini untuk memastikan dapat memfilter dengan benar, alih-alih mencoba mencocokkan string secara samar.
• Ketika Anda memberikan koreksi kepada agen atau ketika agen menemukan pembelajaran dari percakapan Anda, agen akan mem-prompt Anda untuk menyimpan memori tersebut untuk lain kali. 
  • Memori juga dapat dibuat dan diedit secara manual oleh pengguna.
  • Memori dicakup pada tingkat global dan personal, dan alat agen memudahkan Anda untuk mengeditnya.

• Ketika tidak ada konteks sebelumnya untuk suatu tabel atau ketika informasi yang ada sudah tidak mutakhir, agen dapat menjalankan kueri langsung ke gudang data untuk memeriksa dan mengakses tabel tersebut secara langsung. Ini memungkinkannya untuk memvalidasi skema, memahami data secara real-time, dan merespons dengan tepat.
• Agen juga dapat berkomunikasi dengan sistem Data Platform lainnya (layanan metadata, Airflow, Spark) sesuai kebutuhan untuk mendapatkan konteks data yang lebih luas yang ada di luar gudang data.

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⁠(terbuka di jendela baru) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(terbuka di jendela baru) (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⁠(terbuka di jendela baru) 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.