Cuando una empresa empieza a usar agentes de IA sobre sus propios sistemas, tarde o temprano se enfrenta a la misma pregunta: ¿cómo le entregamos al agente la información que necesita para trabajar bien?
No hablamos de preguntas generales. Hablamos de tareas en las que el agente tiene que entender el código fuente, la estructura de una base de datos con cientos de tablas o la forma en que se conectan los sistemas de la organización.
Durante mucho tiempo la respuesta se basó en intuiciones: “usemos JSON porque es más estructurado”, “pongamos todo en el prompt”, “mientras más contexto, mejor”. Casi no había datos. Hasta ahora.
El estudio: 9.649 experimentos
En febrero de 2026, Damon McMillan (HxAI Australia) publicó Structured Context Engineering for File-Native Agentic Systems, uno de los primeros estudios empíricos a gran escala sobre esta pregunta.
El diseño fue amplio:
- 9.649 experimentos.
- 11 modelos de IA en tres niveles: modelos frontier (como Claude Opus, GPT-5.2 y Gemini 2.5 Pro), modelos intermedios de los mismos laboratorios y modelos open source (como DeepSeek, Llama, Qwen y Kimi).
- 4 formatos para describir la información: YAML, Markdown, JSON y TOON, este último un formato nuevo diseñado para ahorrar tokens.
- 2 formas de entregar el contexto: incluirlo completo en el prompt, o dejarlo en archivos que el agente explora por su cuenta, buscando lo que necesita (el enfoque llamado file-native).
- Esquemas de base de datos de 10 a 10.000 tablas.
La tarea fue generar consultas SQL correctas a partir de preguntas en lenguaje natural. Es un buen representante de lo que un agente hace cuando trabaja sobre sistemas reales: entender una estructura compleja, encontrar lo relevante y actuar con precisión.
Hallazgo 1: el formato no cambia la precisión
La primera sorpresa contradice una discusión muy común en los equipos técnicos. El formato no tuvo un efecto estadísticamente significativo en la precisión. YAML logró 75,4 %, Markdown 74,9 %, y JSON y TOON 72,3 % cada uno. Las diferencias están dentro de lo que se podría explicar por azar.
Hay un matiz: los modelos open source sí fueron más sensibles al formato, con diferencias de hasta 20 puntos entre un formato y otro. Los modelos frontier casi no se vieron afectados.
Hallazgo 2: el formato sí cambia el costo
Donde el formato sí importó fue en la eficiencia. Para resolver las mismas tareas, los agentes consumieron:
- YAML: La base de comparación, el más eficiente.
- JSON: 28 % más tokens.
- TOON: 38 % más tokens, pese a que sus archivos eran 25 % más pequeños.
- Markdown: 60 % más tokens.
El caso de TOON es el más interesante. Un formato diseñado para ser compacto terminó siendo más caro porque al agente le costaba más buscar dentro de él: necesitaba más intentos para encontrar lo que buscaba. El autor lo llama el “grep tax”, el impuesto de búsqueda. En el peor caso, un modelo necesitó 16 búsquedas con TOON frente a 3 con YAML.
La lección es útil: lo que parece eficiente para una persona no siempre lo es para un agente.
Hallazgo 3: lo que más pesa es el modelo
El factor que más influyó en los resultados fue la capacidad del modelo. Hubo una brecha de 21 puntos porcentuales entre los modelos frontier (86 % de precisión) y los open source (64,6 %). En las consultas más complejas la diferencia fue aún mayor: 64 % frente a 27 %.
En palabras del autor, esa brecha “eclipsa cualquier efecto de formato o de arquitectura”.
Incluso la forma de entregar el contexto dependió del modelo. Dejar el contexto en archivos para que el agente lo explore mejoró la precisión en los modelos frontier, aunque de forma moderada (+2,7 %). En los modelos open source, en cambio, empeoró los resultados en promedio (−7,7 %). No hay una arquitectura correcta para todos: depende de con qué modelo se trabaja.
Hallazgo 4: la escala se resuelve con estructura
Este es, a nuestro juicio, el hallazgo más relevante para empresas grandes.
Con el esquema en un solo archivo, los agentes navegaron con precisión casi perfecta hasta unas 1.000 tablas. Para llegar a 10.000 tablas manteniendo una alta precisión, hubo que particionar el esquema por dominio, en grupos de unas 250 tablas cada uno.
No fue más contexto lo que permitió escalar. Fue contexto mejor organizado: dividido según la lógica del negocio, para que el agente pudiera orientarse primero y profundizar después.
Es exactamente lo que haría una persona nueva en una organización grande. Nadie lee todo el sistema de una vez: primero entiende las áreas y luego entra al detalle de la que necesita.
Qué significa esto: de ingeniería de prompts a ingeniería de contexto
Durante los primeros años de la IA generativa, la habilidad clave fue escribir buenos prompts. Pero cuando los agentes trabajan sobre sistemas reales, con miles de archivos, tablas y dependencias, el prompt deja de ser el cuello de botella.
La industria ya lo está notando. Según el State of Context Management Report 2026 de DataHub, el 82 % de los líderes de TI y datos afirma que el prompt engineering por sí solo ya no es suficiente.
La disciplina que viene a llenar ese espacio se llama ingeniería de contexto: diseñar qué información recibe el agente, cómo está organizada y cómo la encuentra. Este estudio aporta tres principios concretos:
- Elija bien el modelo antes de optimizar el formato. Es la decisión que más pesa.
- Mida el costo, no solo la precisión. Dos formatos pueden dar el mismo resultado con consumos muy distintos.
- Organice el contexto como está organizado el negocio. A escala, la estructura por dominios es lo que permite que el agente no se pierda.
Cómo lo aplicamos en Tinet: la KDB de Suite Loica
Estos resultados son consistentes con lo que hemos visto en la práctica al construir Suite Loica.
No volcamos el repositorio del cliente en la ventana de contexto. Sería el equivalente a entregarle a una persona nueva todos los archivos de la empresa en una sola pila y pedirle que responda preguntas.
En su lugar, construimos la KDB, la memoria de la empresa, con dos capas complementarias:
- Búsqueda vectorial: Sobre el código, la documentación y los tickets, para encontrar el contenido relevante para cada pregunta.
- Un grafo de dependencias: Modela cómo se relacionan los módulos, las APIs, los datos y los flujos de trabajo. Es la estructura que le permite al agente orientarse por dominio antes de profundizar, justamente lo que el estudio identificó como clave para escalar.
La KDB se actualiza sola cada vez que cambia el código y vive solo en la infraestructura del cliente.
Sobre esa base trabaja GenDEV. Cuando lleva una idea de negocio hasta un diseño técnico, sabe qué ya existe, qué se puede reutilizar y qué se va a ver afectado, porque navega un contexto ordenado y no una pila de archivos. Y como en todo el proceso de Loica, una persona revisa y aprueba en cada etapa.
Loica trabaja antes del IDE
Esto explica también dónde se ubica Loica en el ciclo de desarrollo. Los asistentes de código, como Copilot, trabajan dentro del editor y ayudan a escribir código más rápido. Loica trabaja antes: define sobre qué realidad se va a escribir ese código. El asistente escribe; Loica se asegura de que lo que se construye esté conectado con el sistema que realmente existe.
Son piezas complementarias. Pero sin un contexto bien ordenado, incluso el mejor asistente de código trabaja a ciegas.
Tres preguntas para hacerse esta semana
- ¿Cómo reciben hoy el contexto sus agentes? Si la respuesta es “copiamos y pegamos lo que parece relevante”, el resultado depende de quién lo pegó.
- ¿Su contexto refleja la estructura de su negocio? Si sus sistemas tienen dominios claros (clientes, facturación, operaciones), el contexto que usan sus agentes debería respetarlos.
- ¿Quién es responsable de mantenerlo? El contexto que no se actualiza envejece igual que la documentación. Alguien, o algo, tiene que mantenerlo al día con el código.
Para cerrar
El estudio de McMillan deja una conclusión clara: con modelos cada vez más capaces, la discusión sobre formatos pierde importancia y la organización del contexto la gana. No se trata de darle más información a la IA, sino de dársela ordenada.
La pregunta ya no es qué formato usar. Es quién está ordenando su contexto.
En Tinet construimos Suite Loica con esa convicción. Si quiere ver cómo se vería aplicada a sus sistemas, le proponemos 45 minutos con nuestro equipo, sobre su código real y sin presentaciones. La primera conversación es un diagnóstico, no una demo.
