Aakash Gupta llevaba 1,500 horas construyendo dentro de Claude Code cuando publicó algo que va en contra de la intuición de casi todos los equipos que hoy experimentan con IA empresarial:

“La razón por la que la mayoría de los equipos obtiene resultados mediocres de Claude Code no tiene nada que ver con el modelo. Tiene todo que ver con cuánto espacio le dejaron para pensar. Los archivos CLAUDE.md deben estar casi vacíos.”

La intuición dice lo contrario. Si al modelo le doy más información, responde mejor. Si le doy la documentación completa, los manuales, los runbooks y las políticas, entonces tiene todo lo que necesita. Si la ventana de contexto es más grande, el modelo es más capaz.

Nada de eso es cierto. Y la mayoría de los pilotos de IA empresariales que se están estancando hoy están estancados por esta razón, no por el modelo.

La matemática de la compresión con pérdidas

Una ventana de contexto de 1 millón de tokens suena infinita. Anthropic lanzó Claude Sonnet con soporte para 1 millón de tokens, y Opus 4.6 también opera en esa ventana extendida. Eso son aproximadamente siete novelas de texto, uno al lado del otro, disponibles en una sola consulta.

Suena como resolver el problema de golpe. Y no lo es.

Los documentos reales de una empresa llenan esa ventana rápido. Haz el ejercicio con tu propio stack: los PRDs del trimestre, los manuales de onboarding, los runbooks de operaciones, las políticas de compliance, las notas de ventas de los últimos seis meses, los tickets abiertos, la arquitectura técnica documentada en Confluence, los contratos activos con proveedores. Siete novelas se consumen sin esfuerzo.

Y aquí está el problema que casi nadie audita: cuando la ventana de contexto se llena hasta cierto punto, el modelo empieza a funcionar peor. No porque “no le quepa”. Porque la atención dentro de la ventana no se distribuye uniformemente.

El paper que la mayoría de CTOs no ha leído

En 2023, Liu et al. publicaron “Lost in the Middle: How Language Models Use Long Contexts” (Stanford, UC Berkeley, Samaya AI, Percy Liang entre los autores). El paper midió algo concreto: ¿cómo cambia la capacidad de un LLM para responder preguntas según dónde esté enterrada la información relevante dentro del contexto?

El hallazgo es incómodo: los modelos son mucho mejores usando información que está al inicio o al final del contexto que información que está en el medio. La curva de precisión tiene forma de U. Mete 500 páginas de documentación y la información crítica del centro se pierde funcionalmente, aunque técnicamente esté dentro de la ventana.

Desde entonces la literatura solo ha crecido. El fenómeno tiene varios nombres — “lost in the middle”, “context rot”, “degradación de atención en contextos largos” — pero todos describen lo mismo: caber no es razonar.

Y este es el error de diseño que explica por qué tu piloto de IA se estancó. Tu equipo le metió todo el repositorio al modelo, toda la wiki, toda la documentación, y asumió que con suficiente contexto el modelo encontraría la respuesta. Pero el contexto que le metieron fue exactamente lo que lo degradó.

Ventanas más grandes no te están salvando

La industria lleva dos años resolviendo el problema equivocado. Cada release de modelo presume la ventana de contexto como métrica principal: 128K, 200K, 1M. Y cada equipo de producto interno lee esos anuncios como si fueran la solución a sus pilotos estancados. “Ah, ahora sí va a funcionar, ahora le cabe todo.”

No. “Fit” no es “razonamiento”. Son dos cosas distintas que la industria sigue confundiendo.

Este es el mismo patrón de error que expliqué cuando hablé de la brecha de activación en IA empresarial: el 60% de las organizaciones tiene acceso a herramientas de IA, pero solo el 34% logra transformar algo con ellas. La diferencia no la hizo el modelo. La hizo lo que había alrededor del modelo.

Aquí aplica la misma lectura. Tu problema probablemente no es Claude, GPT o Gemini. Tu problema es qué le estás pasando y en qué orden.

Divulgación progresiva: el patrón que ya estaba inventado

La solución no es nueva. Los ingenieros que han construido sistemas durante treinta años ya la resolvieron varias veces, en distintos dominios.

• Las bases de datos no cargan tablas enteras en memoria cada vez que ejecutas una consulta. Usan índices, resuelven rutas, y cargan solo las filas que necesitas. Si cada SELECT leyera todo el disco, Oracle habría muerto en los noventa.
• Los filesystems no exponen el contenido de todo el disco cuando abres una carpeta. Usan jerarquías. Entras al directorio que te importa y cargas solo ese listado.
• Las aplicaciones web modernas no descargan todo el HTML, JavaScript y CSS del sitio cuando abres la portada. Hacen lazy loading. Las rutas se cargan cuando las visitas.

El patrón tiene nombre desde los años ochenta en la literatura de diseño de interfaces: progressive disclosure, divulgación progresiva. Muestras lo mínimo que necesita quien está decidiendo, y permites profundizar bajo demanda.

Aplicado a IA es directo: un archivo raíz corto que siempre se carga, con punteros a dónde vive cada cosa. Archivos anidados por carpeta que funcionan como índices temáticos. El modelo lee el índice, va directo al archivo exacto que necesita para la consulta, carga solo eso. No hay tokens gastados en documentación irrelevante. No hay agentes de exploración escaneando todo el repositorio a ciegas. El espacio de razonamiento del modelo queda preservado.

Aakash lo probó de forma literal con archivos CLAUDE.md magros y archivos índice anidados por carpeta. Yo lo he visto funcionar en clientes donde el dolor era “el modelo alucina datos del trimestre anterior” y la causa real era que el equipo le estaba pegando seis meses de reportes al contexto con la esperanza de que el modelo supiera cuál era el último.

De truco de PM a Team OS empresarial

Y aquí es donde el tema deja de ser un ajuste de prompt y se convierte en arquitectura organizacional.

Al nivel de un PM individual trabajando con Claude Code, “progressive disclosure” se ve como un archivo CLAUDE.md de diez líneas y cinco archivos índice. Es personal. Cabe en la cabeza de una sola persona.

Al nivel de una empresa con cincuenta personas tocando la IA, el mismo principio se ve completamente distinto. Se parece a una capa de retrieval gobernada: quién es el dueño de cada índice, qué documentos son autoritarios versus archivo, quién aprueba cambios al índice raíz, cómo se versiona, qué nivel de confianza tiene cada fuente. Es infraestructura de información. No es una configuración de prompt engineering.

Aakash lo llama Team OS. Me parece un buen nombre. Captura que esto no es una herramienta ni un workflow: es un sistema operativo para cómo la organización le entrega contexto a sus modelos de IA.

Y sin ese Team OS, cada equipo improvisa. Un analista copia y pega reportes completos al chat porque no existe un índice. Un ingeniero le pasa el repo entero al agente porque no hay una convención. Un director de operaciones mantiene su propio folder personal de docs porque el wiki está desactualizado. Todo eso degrada al modelo en el momento exacto en el que lo estás usando para decisiones importantes.

La disciplina conecta con todo lo demás

Este es el mismo argumento que he venido haciendo desde hace meses, en distintos ángulos.

Cuando escribí sobre gobernanza de agentes de IA usando primitivas de Kubernetes, el punto era que los agentes necesitan RBAC, admission controllers y audit logs antes de tocar nómina o finanzas. Ese es el ángulo de control de acceso.

Cuando escribí sobre alucinaciones en IA financiera y la arquitectura tipo LLM Sandwich, el punto era que los modelos necesitan estar rodeados por capas de verificación antes y después. Ese es el ángulo de validación de salida.

Este post es el tercer ángulo del mismo argumento: la disciplina de entrada. Los agentes necesitan contexto estructurado antes de procesar nada. Y el contexto se diseña con los mismos principios que llevamos décadas aplicando a bases de datos, filesystems y aplicaciones web.

Los tres son la misma tesis escrita tres veces. La diferencia entre empresas que obtienen valor real de IA y empresas atrapadas en pilotos perpetuos no es el modelo que eligen. Es la disciplina de infraestructura que le ponen alrededor, antes, durante y después de cada inferencia.

Gartner ya puso número al costo

Gartner proyecta que más del 40% de los proyectos de IA agéntica serán cancelados antes de que termine 2027. La razón oficial: “controles de riesgo insuficientes, costos fuera de control, valor de negocio difuso”. Anushree Verma, la analista principal, fue directa al llamar a la mayoría “experimentos movidos por el hype, mal aplicados”.

Traduzco lo que significa eso en la práctica: estos proyectos se construyeron sin arquitectura de contexto, sin gobernanza, sin retrieval estructurado, sin Team OS. Alguien copió la documentación al prompt, le puso un modelo caro, y esperó resultados enterprise-grade. Por supuesto se cancelaron.

La parte incómoda es que la diferencia entre estar en el 40% cancelado y estar en el 60% que sobrevive rara vez es una decisión sobre modelos. Es una decisión sobre disciplina de infraestructura, tomada seis meses antes del punto donde el piloto se estanca.

Qué hacemos en IQ Source

La ingeniería de contexto no es una optimización de prompts. No la resuelve un prompt engineer iterando más versiones del mismo prompt. Es una disciplina de arquitectura que se audita, se diseña y se gobierna.

En IQ Source hacemos ese audit al nivel que importa: los prompts reales que tu equipo está enviando hoy (no los que deberían enviar según el playbook que nadie lee), las llamadas reales a retrieval, los dumps reales de documentación que alguien copió y pegó al chat porque no sabía otra forma. Partimos del estado actual, no de un diagrama ideal.

Después rediseñamos la capa de contexto alrededor de divulgación progresiva: índice raíz gobernado, archivos anidados por dominio, convenciones claras sobre qué se carga cuando, cuáles fuentes son autoritarias, cómo se actualizan. No es magia. Es el mismo tipo de disciplina que ya aplicamos para construir bases de datos y filesystems. Solo que ahora la estamos aplicando a los sistemas que toman decisiones de negocio dentro de tu empresa.

Si tienes un piloto de IA que se ha estancado a pesar de que el modelo ya es bueno y tu prompt engineer ya iteró diez veces, el problema probablemente no es ninguno de los dos. Tráeme ese piloto. En una sesión de trabajo mapeamos la arquitectura de contexto que realmente está llegando al modelo, identificamos dónde se está perdiendo fidelidad, y te entrego un plan de rediseño antes de que quemes otro trimestre en prompt tuning. Conversemos.