Dentro del agente de datos interno de OpenAI

Los datos impulsan cómo aprenden los sistemas, cómo evolucionan los productos y cómo las empresas toman decisiones. Pero obtener respuestas rápidamente, correctamente y con el contexto adecuado suele ser más difícil de lo que debería. Para facilitar esto a medida que OpenAI crece, desarrollamos nuestro propio agente de datos de IA personalizado, creado internamente que explora y razona sobre nuestra propia plataforma.

Nuestro agente es una herramienta personalizada de uso exclusivo interno (no es una oferta externa), diseñada específicamente en torno a los datos, permisos y flujos de trabajo de OpenAI. Estamos mostrando cómo lo construimos y lo usamos para ayudar a destacar ejemplos de las formas reales y significativas en que la IA puede apoyar el trabajo diario en nuestros equipos. Las herramientas de OpenAI que usamos para construirlo y ejecutarlo (Codex, nuestro modelo insignia GPT‑5, la Evals API⁠(se abre en una nueva ventana) y la Embeddings API⁠(se abre en una nueva ventana)) son las mismas herramientas que ponemos a disposición de los desarrolladores en todo el mundo.

Nuestro agente de datos permite a los empleados pasar de la pregunta a la información en minutos, no en días. Esto reduce la barrera para extraer datos y realizar análisis matizados en todas las funciones, no solo por parte de nuestro equipo de datos. Hoy, los equipos de Ingeniería, Ciencia de Datos, Go-To-Market, Finanzas e Investigación en OpenAI se apoyan en el agente para responder preguntas de datos de gran impacto. Por ejemplo, puede ayudar a responder cómo evaluar lanzamientos y comprender la salud empresarial, todo 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 de aprendizaje continuo significa que también mejora con cada giro.

En esta publicación, vamos a desglosar por qué necesitábamos un agente de datos de IA a medida, qué hace que su contexto de datos enriquecido con código y su capacidad de autoaprendizaje sean tan útiles, y las lecciones que aprendimos en el camino.

La plataforma de datos de OpenAI da servicio a más de 3500 usuarios internos que trabajan en Ingeniería, Producto e Investigación, y abarca más de 600 petabytes de datos en 70 000 conjuntos de datos. A esa escala, simplemente encontrar la tabla correcta puede ser una de las partes más lentas del análisis.

Como dijo un usuario interno:

“Tenemos muchas tablas que son bastante similares, y paso mucho tiempo tratando de averiguar en qué se diferencian y cuál debo usar. Algunos incluyen a usuarios que han cerrado sesión, otros no. Algunos tienen campos que se superponen; es difícil distinguir qué es qué”.

Incluso con las tablas correctas seleccionadas, producir resultados correctos puede ser un desafío. Los analistas deben analizar los datos de las tablas y las relaciones entre ellas para asegurar que las transformaciones y los filtros se apliquen correctamente. Modos de falla comunes—uniones de muchos a muchos, errores de empuje de filtros y valores nulos no manejados—pueden invalidar los resultados de manera silenciosa. A la escala de OpenAI, los analistas no deberían tener que invertir tiempo en depurar la semántica de SQL o el rendimiento de las consultas; su enfoque debería estar en definir métricas, validar supuestos y tomar decisiones basadas en datos.

Veamos qué es nuestro agente, cómo organiza el contexto y cómo sigue mejorando por sí mismo.

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

Los usuarios pueden hacer preguntas complejas y abiertas que normalmente requerirían múltiples rondas de exploración manual. Toma este ejemplo de prompt, que utiliza un conjunto de datos de prueba: “Para los viajes en taxi de NYC, ¿qué pares de códigos postales (ZIP) de recogida a destino son los más poco confiables, con la mayor diferencia entre los tiempos de viaje típicos y los del peor de los casos, y cuándo ocurre esa variabilidad?”

El agente gestiona el análisis de principio a fin, desde comprender la pregunta hasta explorar los datos, ejecutar consultas y sintetizar los hallazgos.

Uno de los superpoderes del agente es su capacidad para razonar y resolver problemas. En lugar de seguir un guion fijo, el agente evalúa su progreso. Si un resultado intermedio parece incorrecto (p. ej., si tiene cero filas debido a una unión o un filtro incorrectos), el agente investiga qué salió mal, ajusta su enfoque y lo intenta de nuevo. A lo largo de este proceso, mantiene el contexto completo y lleva los aprendizajes de un paso al siguiente. Este proceso de bucle cerrado y autoaprendizaje traslada la iteración del usuario al propio agente, permitiendo obtener resultados más rápidos y análisis consistentemente de mayor calidad que los flujos de trabajo manuales.

El agente cubre todo el flujo de trabajo analítico: descubrimiento de datos, ejecución de SQL y publicación de cuadernos e informes. Comprende el conocimiento interno 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.

Las respuestas de alta calidad dependen de un contexto rico y preciso. Sin contexto, incluso los modelos más sólidos pueden producir resultados incorrectos, como estimar erróneamente el número de usuarios o malinterpretar la terminología interna.

Para evitar estos modos de falla, el agente se construye en torno a múltiples capas de contexto que lo anclan en los datos y el conocimiento institucional de OpenAI.

• Fundamentación en metadatos: El agente se basa en los metadatos del esquema (nombres de columnas y tipos de datos) para informar 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 diferentes tablas.
• Inferencia de consultas: Ingerir consultas históricas ayuda al agente a comprender cómo redactar sus propias consultas y qué tablas suelen combinarse.

• Descripciones curadas de tablas y columnas proporcionadas por expertos en el dominio, capturando la intención, la semántica, el significado empresarial y las advertencias conocidas que no se infieren fácilmente de los esquemas o consultas pasadas.

Los metadatos por sí solos no bastan. Para distinguir realmente las tablas, necesitas entender cómo fueron creadas y de dónde se originan.

• 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 analítico proporcionan información adicional. Por ejemplo, puede proporcionar contexto sobre la singularidad de los valores, con qué frecuencia 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 ofrece un contexto de uso mejorado al demostrar cómo se utiliza la tabla más allá de SQL en Spark, Python y otros sistemas de datos.
• Esto significa que el agente puede distinguir entre tablas que parecen similares pero difieren en aspectos fundamentales. Por ejemplo, puede determinar si una tabla solo incluye tráfico de ChatGPT de primera mano. Este contexto también se actualiza automáticamente, por lo que se mantiene actualizado 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 confiabilidad, nombres en clave internos, herramientas, y las definiciones canónicas y la lógica de cálculo para las métricas clave.
• Estos documentos se ingieren, se incrustan y se 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, permitiendo al agente obtener esta información de manera eficiente y segura.

• Cuando el agente recibe correcciones o descubre matices sobre ciertas preguntas de datos, puede guardar estos aprendizajes para la próxima vez, lo que le permite mejorar constantemente con sus usuarios. 
  • Como resultado, las respuestas futuras parten de una base más precisa en vez de encontrarse repetidamente con los mismos problemas.
  • El objetivo de la memoria es retener y reutilizar correcciones, filtros y restricciones no evidentes que son cruciales para la exactitud de los datos, pero difíciles de deducir solo a partir de las otras capas. 
  • Por ejemplo, en un caso, el agente no sabía cómo filtrar un experimento analítico en particular (se basaba en la coincidencia con una cadena específica definida en una puerta de experimento). La memoria era crucialmente importante aquí para asegurar que pudiera filtrar correctamente, en lugar de intentar hacer una coincidencia difusa de cadenas.
• Cuando le das al agente una corrección o cuando encuentra un aprendizaje de tu conversación, te hará un prompt para que guardes esa memoria para la próxima vez. 
  • Las memorias también pueden ser creadas y editadas manualmente por los usuarios.
  • Las memorias se definen a nivel global y personal, y las herramientas del agente facilitan su edición.

• Cuando no hay un contexto previo para una tabla o cuando la información existente está obsoleta, el agente puede realizar consultas en tiempo real al almacén de datos para inspeccionar y consultar la tabla directamente. Esto le permite validar esquemas, entender los datos en tiempo real y responder de manera adecuada.
• 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 que existe 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 nueva ventana) and stored for retrieval. At query time, the agent pulls only the most relevant embedded context via retrieval-augmented generation⁠(se abre en una nueva ventana) (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 nueva ventana) 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.