OpenAI'ın dahili veri otonom ajanı hakkında

Veriler, sistemlerin öğrenmesini, ürünlerin evrimleşmesini ve şirketlerin karar almasını sağlar. Ancak yanıtları hızlı, doğru ve uygun bağlamda almak çoğu zaman olması gerekenden daha zordur. OpenAI ölçeklendikçe bunu daha kolay hale getirmek için kendi platformumuz üzerinde keşif yapan ve akıl yürüten kendimize özel şirket içi otonom ajanımızı geliştirdik.

Otonom ajanımız, OpenAI'ın verileri, izinleri ve iş akışları etrafında özel olarak geliştirilmiş, yalnızca dahili kullanıma yönelik bir araçtır (dışarıya sunulmamaktadır). Yapay zekanın ekiplerimiz genelinde günlük çalışmaları destekleyebileceği gerçek ve etkili yolların örneklerini ortaya çıkarmaya yardımcı olmak için bunu nasıl oluşturduğumuzu ve kullandığımızı gösteriyoruz. Bunu oluşturmak ve çalıştırmak için kullandığımız OpenAI araçları (Codex, GPT‑5 amiral modeli, Evals API⁠(yeni bir pencerede açılır) ve Embeddings API⁠(yeni bir pencerede açılır)) dünyanın her yerindeki geliştiricilere sunduğumuz araçlardır.

Veri otonom ajanımız çalışanların günler değil, dakikalar içinde sorudan analize ulaşmasını sağlıyor. Bu, yalnızca veri ekibimiz tarafından değil tüm birimler genelinde veri çekme ve detaylı analiz yapma eşiğini düşürüyor. Bugün OpenAI'da Mühendislik, Veri Bilimi, pazara giriş stratejisi, Finans ve Araştırma ekipleri, yüksek etkili veri sorularını yanıtlamak için bu otonom ajana güveniyor. Örneğin bu otonom ajan, doğal dilin sezgisel formatı aracılığıyla lansmanların nasıl değerlendirileceği ve iş sağlığının nasıl anlaşılacağı gibi soruların yanıtlanmasına yardımcı olabiliyor. Codex destekli tablo düzeyindeki bilgileri ürün ve organizasyon bağlamıyla birleştiriyor. Sürekli öğrenen bellek sistemi her seferinde daha da gelişiyor.

Bu yazıda, neden özel bir yapay zeka veri otonom ajanına ihtiyaç duyduğumuzu, kodla zenginleştirilmiş veri bağlamının ve kendi kendine öğrenme yeteneğinin onu neden bu kadar faydalı kıldığını ve süreç boyunca edindiğimiz dersleri ele alacağız.

OpenAI'ın veri platformu; Mühendislik, Ürün ve Araştırma alanlarında çalışan 3.500'den fazla dahili kullanıcıya hizmet veriyor ve 70.000 veri kümesine yayılmış 600 petabayttan fazla veriyi kapsıyor. Bu boyutta doğru tabloyu bulmak, analiz yapmanın en zaman alıcı kısımlarından biri olabilir.

Bir dahili kullanıcı bu durumu şöyle ifade ediyor:

"Oldukça benzer birçok tablomuz var ve aralarındaki farkları anlamak ve hangisini kullanacağımı belirlemek için çok zaman harcıyorum. Bazıları oturumu kapatmış kullanıcıları içerirken bazıları içermiyor. Bazı alanlar çakışıyor, hangisinin ne olduğunu anlamak zor."

Doğru tablolar seçilmiş olsa bile doğru sonuçlar elde etmek zor olabilir. Dönüşümlerin ve filtrelerin doğru bir şekilde uygulandığından emin olmak için analistlerin tablo verileri ve tablo ilişkileri üzerinde düşünmesi gerekir. Çoktan çoğa birleştirmeler, filtre aşağı itme hataları ve işlenmemiş null değerler gibi yaygın hata modları, sonuçları sessizce geçersiz kılabilir. OpenAI ölçeğinde analistlerin SQL semantiği veya sorgu performansı üzerinde zaman harcaması gereksizdir: Odakları, metrikleri tanımlamak, varsayımları doğrulamak ve veriye dayalı kararlar almak olmalıdır.

Otonom ajanımızın ne olduğunu, bağlamı nasıl oluşturduğunu ve kendini nasıl sürekli geliştirdiğini adım adım inceleyelim.

Otonom ajanımız, GPT‑5.2 tarafından desteklenmektedir ve OpenAI'ın veri platformu üzerinde akıl yürütmek için tasarlanmıştır. Çalışanların zaten çalıştığı her yerde kullanılabilir: Slack otonom ajanı olarak web arayüzü üzerinden, IDE'lerin içinde, MCP üzerinden Codex CLI'da⁠(yeni bir pencerede açılır) ve doğrudan MCP bağlayıcısı aracılığıyla OpenAI'ın dahili ChatGPT uygulamasında⁠(yeni bir pencerede açılır).

Kullanıcılar, genellikle birden fazla manuel keşif gerektiren karmaşık ve açık uçlu sorular sorabilir. Bir test veri kümesi kullanan şu örnek komutu ele alın: "NYC taksi yolculukları için tipik ve en kötü seyahat süreleri arasındaki farkın en büyük olduğu, en güvenilmez alma-bırakma posta kodu çiftleri hangileri ve bu değişkenlik ne zaman ortaya çıkıyor?"

Otonom ajan, soruyu anlamaktan verileri incelemeye, sorguları çalıştırmaya ve bulguları sentezlemeye kadar analizi baştan sona yürütür.

Otonom ajanın süper güçlerinden biri, sorunlar üzerinde akıl yürütme şeklidir. Sabit bir senaryoyu takip etmek yerine kendi ilerlemesini değerlendirir. Ara bir sonuç yanlış görünüyorsa (örneğin, yanlış bir birleştirme veya filtre nedeniyle sıfır satır içeriyorsa) otonom ajan neyin yanlış gittiğini araştırır, yaklaşımını ayarlar ve tekrar dener. Bu süreç boyunca tam bağlamı korur ve öğrenilenleri adımlar arasında taşır. Bu kapalı döngüde kendi kendine öğrenme süreci, yinelemeyi kullanıcıdan otonom ajana kaydırarak manuel iş akışlarına göre daha hızlı sonuçlar ve sürekli daha kaliteli analizler sağlar.

Otonom ajan; veri keşfi, SQL çalıştırma ve not defterleri ile rapor yayımlama dahil analitik iş akışının tamamını kapsar. Şirket içi bilgileri anlar, dış bilgileri bulmak için web'de arama yapabilir ve öğrenilen kullanım ve hafıza ile zamanla gelişir.

Kaliteli yanıtlar, zengin ve doğru bağlam gerektirir. Bağlam olmadığında güçlü modeller bile kullanıcı sayılarını büyük ölçüde yanlış tahmin edebilir veya dahili terminolojiyi yanlış yorumlayabilir. Bu da hatalı sonuçlara yol açabilir.

Otonom ajan, bu hata modlarından kaçınmak için OpenAI'ın verilerine ve kurumsal bilgi birikimine dayanan birden fazla bağlam katmanıetrafında inşa edilmiştir.

• Meta veri temellendirmesi: Otonom ajan, SQL yazımını bilgilendirmek için şema meta verilerini (sütun adları ve veri türleri) kullanır ve farklı tabloların ilişkisini anlamak için tablo soy ağacını (ör. yukarı akış ve aşağı akış tablo ilişkileri) kullanır.
• Sorgu çıkarımı: Geçmiş sorguların içe alınması, otonom ajanın kendi sorgularını nasıl yazacağını ve hangi tabloların genellikle birleştirildiğini anlamasına yardımcı olur.

• Alan uzmanları tarafından sağlanan, şemalardan veya geçmiş sorgulardan kolayca çıkarılamayan niyet, anlam, iş bağlamı ve bilinen uyarıları içeren tabloların ve sütunların özenle hazırlanmış açıklamaları.

Meta veriler tek başına yeterli olmaz. Tabloları gerçekten ayırt edebilmek için nasıl oluşturulduklarını ve nereden geldiklerini anlamanız gerekir.

• Otonom ajan, bir tablonun kod düzeyinde tanımını türeterek verilerin gerçekte ne içerdiğini daha iyi anlar. 
  • Tabloda depolanan verilerin ve bunların analitik bir etkinlikten nasıl türetildiğinin nüansları ek bilgi sağlar. Örneğin, değerlerin benzersizliği, tablo verilerinin ne sıklıkla güncellendiği, verinin kapsamı (örneğin, tablo belirli alanları hariç tutuyorsa bu ayrıntı düzeyine sahiptir) vb. hakkında bağlam sağlayabilir.
• Bu, tablonun SQL'in ötesinde Spark, Python ve diğer veri sistemlerinde nasıl kullanıldığını göstererek gelişmiş bir kullanım bağlamı sunar.
• Bu da otonom ajanın benzer görünen ancak kritik açılardan farklılık gösteren tabloları ayırt edebileceği anlamına gelir. Örneğin, bir tablonun yalnızca birinci taraf ChatGPT trafiğini içerip içermediğini belirleyebilir. Bu bağlam da otomatik olarak yenilenir ve bu sayede manuel bakım gerektirmeden güncel kalır.

• Otonom ajan; lansmanlar, güvenilirlik olayları, dahili kod adları ve araçlar ile temel metrikler için kabul edilmiş tanımlar ve hesaplama mantığı gibi kritik şirket bağlamını yakalayan Slack, Google Docs ve Notion'a erişebilir.
• Bu belgeler içeri alınıp gömülerek meta verilerle ve izinlerle birlikte saklanır. Bir getirme hizmeti, çalışma zamanında erişim kontrolünü ve önbelleğe almayı yönetir. Böylece otonom ajan bu bilgileri verimli ve güvenli bir şekilde çekebilir.

• Otonom ajan düzeltmeler yapıldığında veya belirli veri sorularının nüanslarını keşfettiğinde bu öğrenimleri bir sonraki sefer için kaydedebilir ve böylece kullanıcılarıyla birlikte sürekli olarak kendini geliştirebilir. 
  • Sonuç olarak gelecekteki yanıtlar aynı sorunlarla tekrar tekrar karşılaşmak yerine daha doğru bir başlangıç noktasından başlar.
  • Belleğin amacı, veri doğruluğu için kritik olan ancak diğer katmanlardan tek başına çıkarılması zor olan, ilk bakışta fark edilmeyen düzeltmeleri, filtreleri ve kısıtlamaları saklamak ve yeniden kullanmaktır. 
  • Örneğin, bir durumda otonom ajan belirli bir analitik deney için nasıl filtreleme yapacağını bilmiyordu (deney kapısında tanımlanan belirli bir dizeyle eşleşmeye dayanıyordu). Burada belirsiz bir şekilde dize eşleştirmeye çalışmak yerine doğru şekilde filtreleme yapabilmesi için bellek kritik derecede önemliydi.
• Otonom ajana bir düzeltme yaptığınızda veya konuşmanızdan bir öğrenim bulduğunda size bunu bir dahaki sefere hatırlaması için kaydetmek isteyip istemediğinizi soracaktır. 
  • Bellekler kullanıcılar tarafından manuel olarak da oluşturulabilir ve düzenlenebilir.
  • Bellekler küresel ve kişisel düzeyde kapsamlandırılır ve otonom ajanın araçları bunları düzenlemeyi kolaylaştırır.

• Bir tablo için önceden bir bağlam yoksa veya mevcut bilgiler güncelliğini yitirmişse otonom ajan, tabloyu doğrudan incelemek ve sorgulamak amacıyla veri deposuna canlı sorgular gönderebilir. Bu, şemaları doğrulamasını, verileri gerçek zamanlı olarak anlamasını ve buna uygun şekilde yanıt vermesini sağlar.
• Otonom ajan, gerektiğinde veri deposunun dışındaki daha geniş veri bağlamını elde etmek için diğer Veri Platformu sistemleriyle (metadata service, Airflow, Spark) iletişim kurabilir.

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⁠(yeni bir pencerede açılır) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(yeni bir pencerede açılır) (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⁠(yeni bir pencerede açılır) 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.