En el interior del agente de datos interno de OpenAI

Los datos impulsan cómo aprenden los sistemas, cómo evolucionan los productos y cómo se toman las decisiones en las empresas. Pero conseguir respuestas de forma rápida y correcta, y con el contexto adecuado, suele ser más difícil de lo que debería. Para facilitar esto a medida que OpenAI escala, hemos creado nuestro propio agente de datos de IA personalizado interno, que explora nuestra propia plataforma y razona sobre ella.

Nuestro agente es una herramienta personalizada solo para uso interno (no se ofrece a nivel externo) que ha sido diseñada específicamente sobre la base de los datos, permisos y flujos de trabajo de OpenAI. Queremos mostrar cómo lo desarrollamos y lo utilizamos para poner de relieve ejemplos de formas reales e impactantes en que la IA puede ayudar a nuestros equipos en su trabajo diario. Las herramientas de OpenAI que empleamos para crearlo y ejecutarlo (Codex, nuestro modelo insignia GPT‑5, la API Evals⁠(se abre en una ventana nueva) y la API Embeddings⁠(se abre en una ventana nueva)) son las mismas herramientas que ponemos a disposición de los desarrolladores en todas partes.

Nuestro agente de datos permite a nuestros empleados pasar de la pregunta a la información en cuestión de minutos, no de días. Esto hace que se baje el listón a la hora de extraer datos y realizar análisis detallados por todas las funciones, en lugar de centrarse únicamente en nuestro equipo de datos. Hoy, los equipos de Ingeniería, Ciencia de Datos, Go-To-Market, Finanzas e Investigación de OpenAI confían en el agente para responder a preguntas de datos de alto impacto. Por ejemplo, puede ayudar a responder cómo evaluar lanzamientos y entender la situación del negocio, todo ello a través del formato intuitivo del lenguaje natural. El agente combina el conocimiento a nivel de tabla impulsado por Codex con el contexto del producto y la organización. Su sistema de memoria basado en el aprendizaje continuo también mejora con cada turno.

En esta publicación, vamos a analizar por qué necesitábamos un agente de datos de IA a medida, dónde reside la utilidad de su contexto de datos enriquecido con código y su capacidad de autoaprendizaje, y qué lecciones que aprendimos en el camino.

La plataforma de datos de OpenAI da servicio a más de 3500 usuarios internos que trabajan en las áreas de Ingeniería, Producto e Investigación, lo que supone más de 600 petabytes de datos en 70 000 conjuntos de datos. Con estas dimensiones, el simple hecho de encontrar la tabla adecuada puede ser una de las partes que más tiempo lleva a la hora de hacer un análisis.

En palabras de un usuario interno:

«Tenemos muchas tablas bastante similares, y pierdo mucho tiempo tratando de averiguar la diferencia entre ellas y cuál debo usar. Algunas incluyen a usuarios desconectados, otras no. Algunas tienen campos superpuestos, así que es difícil saber qué es qué.»

Incluso teniendo seleccionadas las tablas adecuadas, obtener resultados correctos puede ser todo un reto. Los analistas deben razonar sobre los datos de las tablas y las relaciones entre ellas para asegurarse de que las transformaciones y los filtros se apliquen correctamente. Algunos modos de fallo comunes, como uniones de muchos a muchos, errores de empuje de filtros y valores nulos no gestionados, pueden invalidar silenciosamente los resultados. A escala de OpenAI, los analistas no tendrían que perder tiempo depurando la semántica de SQL o el rendimiento de las consultas, sino que deberían enfocarse en definir métricas, validar suposiciones y tomar decisiones basadas en datos.

Haremos un recorrido por nuestro agente para ver en qué consiste, cómo organiza el contexto y cómo mejora de forma autónoma.

Nuestro agente, impulsado por GPT‑5.2, ha sido diseñado para razonar sobre la plataforma de datos de OpenAI. Está disponible en las áreas donde trabajan los empleados: como un agente de Slack, a través de una interfaz web, en el interior de los IDE, en la CLI de Codex a través de MCP⁠(se abre en una ventana nueva) y directamente en la aplicación interna de ChatGPT de OpenAI mediante un conector MCP⁠(se abre en una ventana nueva).

Los usuarios pueden hacer preguntas complejas y abiertas que de forma habitual requerirían varias rondas de exploración manual. Veamos este ejemplo de prompt, el cual utiliza un conjunto de datos de prueba: «En el caso de los trayectos en taxi en Nueva York, ¿qué pares de códigos postales de salida y llegada son los menos fiables, al presentar la mayor brecha entre la duración típica de un trayecto y la más larga en el peor de los casos, y cuándo se produce esa variabilidad?».

El agente gestiona el análisis de principio a fin, desde la comprensión de la pregunta hasta la exploración de los datos, la ejecución de las consultas y la sintetización de los hallazgos.

Uno de los superpoderes del agente es cómo razona los problemas. En lugar de seguir un guion fijo, el agente evalúa su propio progreso. Si un resultado intermedio parece incorrecto (por ejemplo, si tiene cero filas debido a una unión o un filtro incorrectos), el agente investiga lo que ha salido mal, ajusta su enfoque y lo intenta de nuevo. A lo largo de este proceso, conserva todo el contexto y arrastra el aprendizaje de un paso a otro. Este proceso de circuito cerrado y de autoaprendizaje traslada la iteración del usuario al propio agente, lo que le permite obtener resultados más rápidos y análisis de mayor calidad que los flujos de trabajo manuales.

El agente cubre todo el flujo de trabajo en torno al análisis, desde el descubrimiento de datos y la ejecución de SQL a la publicación de cuadernos e informes. Entiende los conocimientos internos de la empresa, puede buscar información externa en la web y mejora con el tiempo a través del uso aprendido y la memoria.

Para ofrecer respuestas de alta calidad se requiere un contexto rico y preciso. Sin contexto, incluso los modelos más sólidos pueden dar resultados erróneos, como una estimación incorrecta del número de usuarios o una mala interpretación de la terminología interna.

Para evitar estos modos de fallo, el agente se asienta en torno a múltiples capas de contexto que se alimentan de los datos y del conocimiento institucional de OpenAI.

• Fundamentación de metadatos: El agente se basa en los metadatos del esquema (nombres de columnas y tipos de datos) para guiar la escritura de SQL y utiliza el linaje de tablas (por ejemplo, relaciones de tablas ascendentes y descendentes) para proporcionar contexto sobre cómo se relacionan las diferentes tablas.
• Inferencia de consultas: Mediante la introducción de consultas históricas, el agente aprende a redactar sus propias consultas y qué tablas suelen unirse.

• Descripciones seleccionadas de tablas y columnas proporcionadas por expertos en la materia que recogen la intención, la semántica, el significado empresarial y las advertencias conocidas que no se infieren fácilmente de esquemas o consultas anteriores.

Los metadatos por sí solos no son suficientes. Para distinguir realmente unas tablas de otras, necesitas entender cómo fueron creadas y de dónde provienen.

• Al derivar una definición a nivel de código de una tabla, el agente adquiere una comprensión más profunda de lo que realmente contienen los datos. 
  • Los matices sobre lo que se almacena en la tabla y cómo se deriva de un evento de analítica proporcionan información extra. Por ejemplo, puede dar contexto sobre la singularidad de los valores, la frecuencia con la que se actualizan los datos de la tabla, el alcance de los datos (p. ej., si la tabla excluye ciertos campos, tiene este nivel de granularidad), etc.
• Esto proporciona un contexto de uso mejorado al mostrar cómo se utiliza la tabla más allá de SQL en Spark, Python y otros sistemas de datos.
• Gracias a ello, el agente puede distinguir entre tablas que parecen similares pero difieren en aspectos críticos. Por ejemplo, puede decir si una tabla solo incluye tráfico de ChatGPT de primera mano. Este contexto también se actualiza automáticamente, así que se mantiene al día sin necesidad de mantenimiento manual.

• El agente puede acceder a Slack, Google Docs y Notion, que capturan el contexto crítico de la empresa, como lanzamientos, incidentes de fiabilidad, nombres en clave y herramientas internas, así como las definiciones canónicas y la lógica de cálculo para las métricas clave.
• Estos documentos se introducen, insertan y almacenan con metadatos y permisos. Un servicio de recuperación gestiona el control de acceso y el almacenamiento en caché en tiempo de ejecución, lo que permite al agente incorporar esta información de manera eficiente y segura.

• Cuando el agente recibe correcciones o descubre matices sobre ciertas preguntas de datos, puede guardar este aprendizaje para la próxima vez, lo que le permite mejorar constantemente con sus usuarios. 
  • Como resultado, las siguientes respuestas parten de una base más precisa, en lugar de encontrarse repetidamente con los mismos problemas.
  • El objetivo de la memoria es conservar y reutilizar correcciones, filtros y restricciones no evidentes que resultan fundamentales para la corrección de los datos, aunque pueden ser difíciles de inferir a partir únicamente de las otras capas. 
  • Por ejemplo, en un caso, el agente no sabía cómo filtrar un experimento analítico específico (dependía de coincidir con una cadena específica definida en una puerta de experimento). La memoria aquí era crucial para asegurar que se pudiera filtrar correctamente, en lugar de intentar coincidir cadenas de manera imprecisa.
• Cuando hagas una corrección al agente o cuando este obtenga un aprendizaje a raíz de tu conversación, recibirás una indicación para guardar esa memoria para la próxima vez. 
  • Las memorias también pueden ser creadas y editadas manualmente por los usuarios.
  • Los recuerdos se gestionan a nivel global y personal, los cuales será muy fácil editar utilizando las herramientas del agente.

• Cuando no hay un contexto previo para una tabla o cuando la información existente está obsoleta, el agente puede realizar consultas en vivo al almacén de datos para inspeccionar y examinar la tabla directamente. Esto le permite validar esquemas, entender los datos en tiempo real y responder de forma oportuna.
• El agente también puede comunicarse con otros sistemas de la plataforma de datos (metadata service, Airflow, Spark) según sea necesario para obtener un contexto de datos más amplio fuera del almacén.

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⁠(se abre en una ventana nueva) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(se abre en una ventana nueva) (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⁠(se abre en una ventana nueva) 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.