Por dentro do agente de dados interno da OpenAI

Os dados impulsionam a forma como os sistemas aprendem, os produtos evoluem e as empresas tomam decisões. Mas obter respostas de forma rápida, correta e com o contexto adequado costuma ser mais difícil do que deveria. Para facilitar esse processo à medida que a OpenAI cresce, criamos nosso próprio agente de dados de IA personalizado, desenvolvido internamente, que explora e raciocina sobre nossa própria plataforma.

Nosso agente é uma ferramenta personalizada, de uso exclusivamente interno (não uma oferta externa), desenvolvida especificamente para os dados, permissões e fluxos de trabalho da OpenAI. Estamos mostrando como construímos e usamos essa ferramenta para ajudar a revelar exemplos reais e impactantes de como a IA pode apoiar o trabalho diário em nossas equipes. As ferramentas da OpenAI que usamos para construir e executar o projeto (Codex, nosso modelo principal GPT‑5, a API Evals⁠(abre em uma nova janela) e a API Embeddings⁠(abre em uma nova janela)) são as mesmas ferramentas que disponibilizamos para desenvolvedores em todo o mundo.

Nosso agente de dados Permite que os funcionários passem da dúvida à compreensão em minutos, não em dias. Isso facilita a coleta de dados e a realização de análises detalhadas em todas as funções, não apenas pela nossa equipe de dados. Hoje, equipes de Engenharia, Ciência de Dados, Estratégia de Mercado, Finanças e Pesquisa da OpenAI contam com o agente para responder a perguntas de dados de alto impacto. Por exemplo, pode ajudar a responder perguntas sobre como avaliar lançamentos e compreender a saúde dos negócios, tudo isso através do formato intuitivo da linguagem natural. O agente combina o conhecimento em nível de tabela, baseado no Codex, com o contexto do produto e da organização. Seu sistema de memória de aprendizado contínuo significa que ele também melhora a cada vez que é usado.

Neste post, vamos explicar por que precisávamos de um agente de dados de IA personalizado, o que torna seu contexto de dados enriquecido por código e sua capacidade de autoaprendizagem tão úteis, e as lições que aprendemos ao longo do processo.

A plataforma de dados da OpenAI atende a mais de 3.500 usuários internos que trabalham nas áreas de Engenharia, Produto e Pesquisa, abrangendo mais de 600 petabytes de dados em 70 mil conjuntos de dados. Nesse tamanho, simplesmente encontrar a tabela certa pode ser uma das partes mais demoradas da análise.

Como disse um usuário interno:

“Temos muitas tabelas bastante semelhantes, e eu passo muito tempo tentando descobrir as diferenças entre elas e qual usar.” Algumas incluem usuários desconectados, outras não. Algumas têm campos sobrepostos; é difícil distinguir uma da outra.”

Mesmo com as tabelas corretas selecionadas, produzir resultados corretos pode ser um desafio. Os analistas devem analisar os dados das tabelas e os relacionamentos entre elas para garantir que as transformações e os filtros sejam aplicados corretamente. Modos de falha comuns — junções muitos-para-muitos, erros de pushdown de filtro e valores nulos não tratados — podem invalidar resultados silenciosamente. Na escala da OpenAI, os analistas não deveriam precisar perder tempo depurando a semântica do SQL ou o desempenho das consultas: seu foco deveria ser definir métricas, validar hipóteses e tomar decisões baseadas em dados.

Vamos analisar o que é o nosso agente, como ele seleciona o contexto e como ele se aprimora continuamente.

Nosso agente é baseado no GPT‑5.2 e foi projetado para raciocinar sobre a plataforma de dados da OpenAI. Está disponível em todos os locais onde os funcionários já trabalham: como um agente do Slack, por meio de uma interface web, dentro de IDEs, no Codex CLI via MCP⁠(abre em uma nova janela) e diretamente no aplicativo interno ChatGPT da OpenAI por meio de um conector MCP⁠(abre em uma nova janela).

Os usuários podem fazer perguntas complexas e abertas que normalmente exigiriam várias rodadas de exploração manual. Considere este exemplo de pergunta, que usa um conjunto de dados de teste: “Para viagens de táxi em Nova York, quais pares de CEPs de partida e chegada são os menos confiáveis, com a maior diferença entre os tempos de viagem típicos e os tempos de viagem no pior cenário, e quando ocorre essa variabilidade?”

O agente realiza a análise de ponta a ponta, desde a compreensão da questão até a exploração dos dados, execução de consultas e síntese das conclusões.

Uma das superpotências do agente é a sua capacidade de raciocinar sobre os problemas. Em vez de seguir um roteiro fixo, o agente avalia seu próprio progresso. Se um resultado intermediário parecer incorreto (por exemplo, se tiver zero linhas devido a uma junção ou filtro incorreto), o agente investiga o que deu errado, ajusta sua abordagem e tenta novamente. Ao longo de todo esse processo, o contexto completo é mantido e os aprendizados são aplicados entre as etapas. Esse processo de autoaprendizagem em circuito fechado transfere a iteração do usuário para o próprio agente, possibilitando resultados mais rápidos e análises de qualidade consistentemente superior aos fluxos de trabalho manuais.

O agente abrange todo o fluxo de trabalho de análise: descoberta de dados, execução de SQL e publicação de notebooks e relatórios. Compreende o conhecimento interno da empresa, consegue pesquisar informações externas na web e melhora com o tempo através do uso e da memorização.

Respostas de alta qualidade dependem de um contexto rico e preciso. Sem contexto, mesmo modelos robustos podem produzir resultados incorretos, como estimar erroneamente o número de usuários ou interpretar erroneamente a terminologia interna.

Para evitar esses modos de falha, o agente é construído em torno de múltiplas camadas de contexto que o fundamentam nos dados e no conhecimento institucional da OpenAI.

• Fundamentação de metadados: O agente se baseia em metadados de esquema (nomes de colunas e tipos de dados) para orientar a escrita de SQL e usa a linhagem da tabela (por exemplo, relacionamentos entre tabelas anteriores e posteriores) para fornecer contexto sobre como as diferentes tabelas se relacionam.
• Inferência de consultas: a ingestão de consultas históricas ajuda o agente a entender como escrever suas próprias consultas e quais tabelas são normalmente unidas.

• Descrições selecionadas de tabelas e colunas fornecidas por especialistas do domínio, capturando a intenção, a semântica, o significado comercial e as limitações conhecidas que não são facilmente inferidas a partir de esquemas ou consultas anteriores.

Os metadados por si só não são suficientes. Para realmente diferenciar as tabelas, é preciso entender como elas foram criadas e qual a sua origem.

• Ao derivar uma definição de tabela em nível de código, o agente constrói uma compreensão mais profunda do que os dados realmente contêm. 
  • As nuances sobre o que está armazenado na tabela e como isso é derivado de um evento analítico fornecem informações adicionais. Por exemplo, pode fornecer contexto sobre a unicidade dos valores, a frequência com que os dados da tabela são atualizados, o escopo dos dados (por exemplo, se a tabela exclui determinados campos, ela tem esse nível de granularidade), etc.
• Isso proporciona um contexto de uso aprimorado, mostrando como a tabela é utilizada além do SQL no Spark, Python e outros sistemas de dados.
• Isso significa que o agente consegue distinguir entre tabelas que parecem semelhantes, mas diferem em aspectos cruciais. Por exemplo, pode indicar se uma tabela inclui apenas tráfego ChatGPT de primeira parte. Esse contexto também é atualizado automaticamente, mantendo-se sempre em dia sem necessidade de manutenção manual.

• O agente pode acessar o Slack, o Google Docs e o Notion, que capturam o contexto crítico da empresa, como lançamentos, incidentes de confiabilidade, nomes de código internos e ferramentas, além das definições canônicas e da lógica de computação para métricas-chave.
• Esses documentos são ingeridos, incorporados e armazenados com metadados e permissões. Um serviço de recuperação gerencia o controle de acesso e o armazenamento em cache em tempo de execução, permitindo que o agente obtenha essas informações de forma eficiente e segura.

• Quando o agente recebe correções ou descobre nuances sobre determinadas questões de dados, ele consegue salvar esses aprendizados para a próxima vez, permitindo que ele melhore constantemente junto com seus usuários. 
  • Como resultado, as respostas futuras partem de uma base mais precisa, em vez de se depararem repetidamente com os mesmos problemas.
  • O objetivo da memória é reter e reutilizar correções, filtros e restrições não óbvias que são essenciais para a correção dos dados, mas difíceis de inferir apenas a partir das outras camadas. 
  • Por exemplo, em um caso, o agente não sabia como filtrar um experimento analítico específico (ele dependia da correspondência com uma string específica definida em um portão de experimento). A memória foi crucial nesse processo para garantir que o filtro fosse capaz de funcionar corretamente, em vez de tentar encontrar correspondências de strings de forma imprecisa.
• Quando você fornece uma correção ao agente ou quando ele extrai uma lição da sua conversa, ele lhe sugerirá que salve essa informação para a próxima vez. 
  • As memórias também podem ser criadas e editadas manualmente pelos usuários.
  • As memórias são delimitadas em níveis global e pessoal, e as ferramentas do agente facilitam a sua edição.

• Quando não existe contexto prévio para uma tabela ou quando as informações existentes estão desatualizadas, o agente pode enviar consultas em tempo real ao data warehouse para inspecionar e consultar a tabela diretamente. Isso permite validar schemas, entender os dados em tempo real e responder de forma adequada.
• O agente também é capaz de se comunicar com outros sistemas da Plataforma de Dados (serviço de metadados, Airflow, Spark) conforme necessário para obter um contexto de dados mais amplo que exista fora do data 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⁠(abre em uma nova janela) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(abre em uma nova janela) (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⁠(abre em uma nova janela) 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.