Six layers of context, fewer tools, and why the foundation beats the model — lessons from a 1.5-exabyte data agent, applied to natural-language SQL.
Inspired by OpenAI's internal data agent, described by Emma Tang (Head of Data Platform Engineering) in a ByteByteGo feature. All commentary and PeopleWorks GPT mappings are our own analysis.
OpenAI's data platform now holds roughly 1.5 exabytes across about 90,000 datasets, queried by thousands of internal users. At that scale, the team made an observation that should sound familiar to anyone who has built a business intelligence tool: the difficult part of data analysis is not writing SQL. It is finding the right tables and understanding what they actually mean. Two tables can look almost identical, share a user_id column, and still answer completely different questions — one counts logged-out visitors, the other does not.
This is precisely the thesis PeopleWorks GPT was built on: domain knowledge beats pure coding skills. A model that can generate flawless syntax is useless if it joins the wrong tables. The lesson from OpenAI is that reliability does not come from a clever agent. It comes from the engineering that feeds the agent the right context before it ever sees a question.
Everyone expects a system that handles 90,000 tables to be enormously complex — routers that pick between cheap and expensive models, fine-tuned variants, multiple embedding pipelines. OpenAI went the other way. Their agent is, in the team's own framing, deliberately plain: one model, a context-assembly layer, a small curated tool set, and a runtime loop. The reliability lives in the data foundation underneath, not in agent gymnastics.
The core pattern is an LLM plus a harness. The model reasons; the harness gives it tools, assembles context, and runs it in a loop so it can write a query, observe the result, and try again until the answer holds up.
PeopleWorks GPT already follows this shape. We generate SQL directly rather than relying on embeddings to approximate answers, we run against a universal provider for SQL Server, MySQL, PostgreSQL, Oracle and SQLite, and our MCP Server exposes the same capabilities to any AI assistant. The open question OpenAI answers for us is where to invest next: not in a fancier agent, but in richer context.
The real engineering in OpenAI's agent is the context layer. A bare schema cannot tell near-identical tables apart, so the team assembles meaning from six sources before generation. Here is each layer mapped to where it lives — or could live — inside PeopleWorks GPT.
| Layer | What it provides at OpenAI | PeopleWorks GPT analogue |
|---|---|---|
| 1. Table usage metadata | Schema, lineage and a ranked history of how the table has been queried. | Our schema introspection (PRAGMA / INFORMATION_SCHEMA / ALL_TAB_*) plus a future store of "golden" example queries used as hints. |
| 2. Human annotations | Owner-written notes: business meaning, ownership, criticality, caveats. | Database hints and column descriptions — a curated domain glossary attached to each connection. |
| 3. Codex enrichment | A nightly job reads the pipeline code to learn how each table is built and when to use it. | A batch job that reads stored procedures, views and ETL logic to auto-describe tables for the AI context. |
| 4. Institutional knowledge | Slack, Docs and Notion, embedded and served through an access-controlled retrieval service. | Optional doc/wiki connectors with per-user permissions, so the agent never surfaces what a user can't see. |
| 5. Memory | Corrections and learnings saved from past conversations, global or personal. | Conversation memory feeding our routing layer: org-wide SQL patterns plus per-user preferences (date ranges, default metrics). |
| 6. Runtime context | Live queries to the warehouse, Airflow or Spark when offline context is stale. | Our live multi-engine providers, queried on demand when cached schema is missing or out of date. |
Once the foundation is in place, the request flow is short: embed the question, assemble the context, then run the agent loop until the answer is verified. This maps almost one-to-one onto the PeopleWorks GPT NL2SQL pipeline.
What makes the loop trustworthy is not the model's raw intelligence but the quality of what flows through these three steps. The same principle applies to us: the better our table descriptions and example queries, the fewer retries, and the more often the first SQL is the right SQL.
The team shared five lessons that generalize far beyond OpenAI. Each one has a direct application to how we build PeopleWorks GPT.
| Lesson | What OpenAI found | How we apply it |
|---|---|---|
| The foundation beats the agent | A unified data lake, a single monorepo and strong annotations are what make a plain agent reliable. | Keep investing in clean schema introspection, foreign-key discovery and curated hints before adding agent complexity. |
| Fewer tools beat more tools | Starting with ~40 tools confused the model; capping at ~13 and removing overlap fixed it. | Curate the MCP Server tool set deliberately: no two tools doing the same job, no near-duplicates competing for selection. |
| Pick trusted queries for retrieval | Embedding every historical query failed; ranking by trust (dashboard / data-scientist queries first) worked. | Weight example queries by source quality so the model imitates good patterns, not one-off exploratory SQL. |
| Guide the goal, not the path | Prescriptive step-by-step prompts produced worse answers than high-level goals plus good context. | Prompt the model with the objective and the right context; let it plan the SQL rather than scripting every step. |
| Be more ambitious | A "two-year" cross-cloud migration finished in two months once an agent did most of the code changes. | Re-estimate roadmap items assuming AI does the heavy lifting; the safe timeline is now the risky one. |
Reading this through the lens of our roadmap, six concrete directions stand out.
Evolve our prompt from "schema only" to schema + ranked example queries + human annotations + memory, merged into one table description per connection.
Rank stored example queries by source. A query behind a heavily used report outweighs a one-off, so the AI copies the patterns worth imitating.
Audit our MCP Server tools for overlap and cap how many reach the model per call — fewer, sharper tools, no near-duplicates.
Two memory tiers feeding the three-tier conversational router: org-wide SQL conventions and per-user defaults like preferred date ranges and metrics.
A nightly job that reads stored procedures and views to auto-generate plain-language table descriptions — our own "Codex enrichment" for legacy schemas.
Beyond grid and pivot: generate a tailored interface per question, the natural next step for our rich conversational experience layer.
The encouraging part of OpenAI's story is that almost none of it requires privileged access. Public APIs, public embeddings, an open protocol (MCP) and a willingness to keep the agent simple. That is the exact posture PeopleWorks GPT already takes — which means the gap between us and a state-of-the-art data agent is mostly disciplined context engineering, not exotic technology.
OpenAI's data agent works because the data underneath it is legible to a model: unified, annotated, well-named. The agent is the easy part. For PeopleWorks GPT, the takeaway is direct — the next leap in accuracy comes from richer context, trusted example queries, curated tools and memory, not from a more elaborate agent. Domain knowledge, made machine-readable, beats pure coding skills every single time.
Try PeopleWorks GPT →Seis capas de contexto, menos herramientas y por qué la base le gana al modelo — lecciones de un data agent de 1,5 exabytes, aplicadas al SQL en lenguaje natural.
Inspirado en el data agent interno de OpenAI, descrito por Emma Tang (Head of Data Platform Engineering) en un reportaje de ByteByteGo. Todo el análisis y las equivalencias con PeopleWorks GPT son nuestros.
La plataforma de datos de OpenAI almacena hoy cerca de 1,5 exabytes en unos 90 000 conjuntos de datos, consultados por miles de usuarios internos. A esa escala, el equipo hizo una observación que le resultará familiar a cualquiera que haya construido una herramienta de inteligencia de negocio: lo difícil del análisis de datos no es escribir SQL. Es encontrar las tablas correctas y entender qué significan realmente. Dos tablas pueden parecer casi idénticas, compartir una columna user_id y aun así responder preguntas completamente distintas — una cuenta visitantes no autenticados, la otra no.
Esta es exactamente la tesis sobre la que se construyó PeopleWorks GPT: el dominio del negocio le gana al puro código. Un modelo capaz de generar sintaxis impecable es inútil si une las tablas equivocadas. La lección de OpenAI es que la fiabilidad no viene de un agente ingenioso. Viene de la ingeniería que le entrega al agente el contexto correcto antes de que vea siquiera la pregunta.
Todos esperan que un sistema que maneja 90 000 tablas sea enormemente complejo — enrutadores que eligen entre modelos baratos y caros, variantes con fine-tuning, múltiples pipelines de embeddings. OpenAI hizo lo contrario. Su agente es, en palabras del propio equipo, deliberadamente sencillo: un solo modelo, una capa de ensamblaje de contexto, un conjunto pequeño y curado de herramientas, y un bucle de ejecución. La fiabilidad vive en la base de datos que hay debajo, no en acrobacias del agente.
El patrón central es un LLM más un arnés. El modelo razona; el arnés le da herramientas, ensambla el contexto y lo ejecuta en un bucle para que escriba una consulta, observe el resultado y vuelva a intentarlo hasta que la respuesta se sostenga.
PeopleWorks GPT ya sigue esta forma. Generamos SQL directamente en lugar de depender de embeddings para aproximar respuestas, ejecutamos sobre un proveedor universal para SQL Server, MySQL, PostgreSQL, Oracle y SQLite, y nuestro MCP Server expone las mismas capacidades a cualquier asistente de IA. La pregunta que OpenAI nos responde es dónde invertir a continuación: no en un agente más sofisticado, sino en un contexto más rico.
La verdadera ingeniería del agente de OpenAI es la capa de contexto. Un esquema desnudo no distingue tablas casi idénticas, así que el equipo ensambla significado desde seis fuentes antes de generar. Aquí está cada capa mapeada a dónde vive — o podría vivir — dentro de PeopleWorks GPT.
| Capa | Qué aporta en OpenAI | Equivalente en PeopleWorks GPT |
|---|---|---|
| 1. Metadatos de uso de tablas | Esquema, linaje e historial clasificado de cómo se ha consultado la tabla. | Nuestra introspección de esquema (PRAGMA / INFORMATION_SCHEMA / ALL_TAB_*) más un futuro repositorio de consultas de ejemplo "doradas" usadas como hints. |
| 2. Anotaciones humanas | Notas del responsable: significado de negocio, propiedad, criticidad y advertencias. | Hints de base de datos y descripciones de columnas — un glosario de dominio curado por cada conexión. |
| 3. Enriquecimiento por código | Un trabajo nocturno lee el código del pipeline para saber cómo se construye cada tabla y cuándo usarla. | Un proceso por lotes que lee procedimientos almacenados, vistas y lógica ETL para autodescribir tablas en el contexto de la IA. |
| 4. Conocimiento institucional | Slack, Docs y Notion, indexados y servidos por un servicio de recuperación con control de acceso. | Conectores opcionales de docs/wiki con permisos por usuario, para que el agente nunca muestre lo que el usuario no puede ver. |
| 5. Memoria | Correcciones y aprendizajes guardados de conversaciones previas, globales o personales. | Memoria conversacional que alimenta nuestra capa de enrutamiento: patrones SQL de toda la organización más preferencias por usuario (rangos de fechas, métricas por defecto). |
| 6. Contexto en tiempo de ejecución | Consultas en vivo al almacén, Airflow o Spark cuando el contexto offline está desactualizado. | Nuestros proveedores multi-motor en vivo, consultados bajo demanda cuando el esquema en caché falta o está obsoleto. |
Una vez puesta la base, el flujo de cada petición es corto: incrustar la pregunta, ensamblar el contexto y ejecutar el bucle del agente hasta verificar la respuesta. Esto se mapea casi uno a uno sobre el pipeline NL2SQL de PeopleWorks GPT.
Lo que hace confiable al bucle no es la inteligencia bruta del modelo, sino la calidad de lo que fluye por estos tres pasos. El mismo principio aplica para nosotros: cuanto mejores sean nuestras descripciones de tablas y consultas de ejemplo, menos reintentos, y más a menudo el primer SQL será el correcto.
El equipo compartió cinco lecciones que se generalizan mucho más allá de OpenAI. Cada una tiene una aplicación directa en cómo construimos PeopleWorks GPT.
| Lección | Lo que descubrió OpenAI | Cómo lo aplicamos |
|---|---|---|
| La base le gana al agente | Un data lake unificado, un único monorepo y anotaciones sólidas son lo que hace fiable a un agente sencillo. | Seguir invirtiendo en introspección limpia de esquemas, descubrimiento de claves foráneas y hints curados antes de añadir complejidad al agente. |
| Menos herramientas le ganan a más | Empezar con ~40 herramientas confundía al modelo; limitarlas a ~13 y quitar solapamientos lo resolvió. | Curar el conjunto de herramientas del MCP Server con criterio: que dos herramientas no hagan el mismo trabajo ni compitan por ser elegidas. |
| Elegir consultas confiables para recuperación | Incrustar todas las consultas históricas falló; clasificar por confianza (consultas de dashboards / científicos de datos primero) funcionó. | Ponderar las consultas de ejemplo por la calidad de su fuente para que el modelo imite buenos patrones, no SQL exploratorio de una sola vez. |
| Guiar la meta, no el camino | Los prompts prescriptivos paso a paso produjeron peores respuestas que metas de alto nivel con buen contexto. | Darle al modelo el objetivo y el contexto correcto; dejar que él planifique el SQL en lugar de guionizar cada paso. |
| Ser más ambicioso | Una migración entre nubes "de dos años" terminó en dos meses cuando un agente hizo la mayoría de los cambios de código. | Reestimar el roadmap asumiendo que la IA hace el trabajo pesado; el plazo seguro es ahora el plazo arriesgado. |
Leyendo todo esto con el lente de nuestro roadmap, sobresalen seis direcciones concretas.
Evolucionar el prompt de "solo esquema" a esquema + consultas de ejemplo clasificadas + anotaciones humanas + memoria, fusionados en una descripción por conexión.
Clasificar las consultas de ejemplo por su fuente. Una consulta detrás de un reporte muy usado pesa más que una de una sola vez, para que la IA copie los patrones que merece imitar.
Auditar las herramientas del MCP Server en busca de solapamientos y limitar cuántas llegan al modelo por llamada — menos herramientas, más afiladas, sin casi-duplicados.
Dos niveles de memoria alimentando el enrutador conversacional de tres niveles: convenciones SQL de la organización y valores por defecto por usuario, como rangos de fechas y métricas.
Un trabajo nocturno que lee procedimientos almacenados y vistas para autogenerar descripciones de tablas en lenguaje natural — nuestro propio "enriquecimiento por código" para esquemas legados.
Más allá del grid y la tabla dinámica: generar una interfaz a medida por pregunta, el siguiente paso natural para nuestra capa de experiencia conversacional rica.
Lo alentador de la historia de OpenAI es que casi nada requiere acceso privilegiado. APIs públicas, embeddings públicos, un protocolo abierto (MCP) y la disposición a mantener el agente simple. Esa es exactamente la postura que ya tiene PeopleWorks GPT — lo que significa que la distancia entre nosotros y un data agent de última generación es, sobre todo, ingeniería de contexto disciplinada, no tecnología exótica.
El data agent de OpenAI funciona porque los datos que tiene debajo son legibles para un modelo: unificados, anotados, bien nombrados. El agente es la parte fácil. Para PeopleWorks GPT, la conclusión es directa — el próximo salto en precisión viene de un contexto más rico, consultas de ejemplo confiables, herramientas curadas y memoria, no de un agente más elaborado. El conocimiento del dominio, hecho legible para la máquina, le gana al puro código todas y cada una de las veces.
Prueba PeopleWorks GPT →