El principiante cree que la ventana de 200K o 1M tokens es un cubo que se va llenando: cuanto más metes, más sabe el agente. La realidad es lo contrario. El contexto es un recurso finito, no-uniforme y degradable que tienes que curar en cada turno. Cada token irrelevante que añades no solo cuesta dinero y latencia. Cuesta precisión. Este módulo va de pensar el contexto como un sistema operativo administra la RAM, y de tener el vocabulario preciso para diagnosticar por qué tu agente "se vuelve tonto" conforme avanza la conversación.
El contexto se cura cada turno
La línea entre prompt engineering y context engineering es temporal. El prompt engineering optimiza una cosa estática que escribes una vez: el system prompt. El context engineering gestiona el flujo completo de tokens (historial, resultados de tools, memoria, ficheros) que cambia a cada paso del loop agéntico. El system prompt sigue importando, pero tratado como un artefacto aislado es un subconjunto del problema, no el problema.
El principio rector cabe en una frase de Anthropic: "find the smallest set of high-signal tokens that maximize the likelihood of your desired outcome." Eso convierte el diseño de contexto en una optimización con restricción, no en acumulación. La razón física: la atención del transformer es por pares, así que es O(n²), y los modelos tienen una cantidad limitada de parámetros entrenados para dependencias de largo alcance, de modo que la fiabilidad de recuperación se degrada conforme crece la longitud.
El marco más útil viene de MemGPT: trata la ventana de contexto como working memory limitada (RAM) y el almacenamiento externo como memoria de largo plazo (disco), con el LLM haciendo el paginado, decidiendo qué cargar y qué descargar, igual que un SO mueve páginas entre RAM y swap. La extensión pedagógica es mía: pensar el context bloat como thrashing (cuando un SO pasa más tiempo paginando que computando) explica por qué un agente con la ventana llena de basura razona peor aunque "todo quepa". [D]
Context rot: el hallazgo que rompe la intuición
La evidencia empírica central es el estudio Context Rot de Chroma, que evaluó 18 modelos frontera (Claude Opus 4, GPT-4.1, Gemini 2.5 y Qwen3 entre ellos) y mostró que los modelos no usan su contexto de forma uniforme: el rendimiento se vuelve crecientemente poco fiable conforme aumenta la longitud de entrada.
Por eso el clásico needle-in-a-haystack (NIAH) léxico engaña como prueba de capacidad long-context: da ~100% y oculta la degradación real, porque buscar una cadena exacta es trivial al lado de razonar semánticamente sobre el contenido. Para medir algo real hacen falta benchmarks multi-paso como LongMemEval o LOCOMO.
El resultado más contra-intuitivo de Chroma que casi nadie aplica: barajar el haystack (romper la coherencia lógica y estructural del relleno) mejoró el rendimiento de forma consistente en los 18 modelos evaluados. La estructura lógica del relleno puede confundir a la atención, lo que implica que "ordenar bonito" el contexto puede perjudicar activamente. Conviene señalar lo que el estudio no encontró: en la tarea estándar de needle-in-a-haystack no apareció ningún efecto notable de "lost in the middle" por posición (sin variación significativa entre las 11 posiciones de la aguja). Una ventaja de inicio de secuencia surgió solo en una tarea de generación aparte (el experimento Repeated Words), de modo que la conocida palanca de "poner lo crítico al frente" se sostiene mucho menos de lo que sugiere el folclore.
Las cuatro patologías: un vocabulario de diagnóstico
"Context rot" describe que el contexto largo falla. Drew Breunig da la taxonomía de por qué, que es lo que te entrega un vocabulario para depurar: cuando tu agente se atonta, ¿es poisoning o distraction?
El caso canónico de poisoning lo documenta Google DeepMind: en su agente que jugaba Pokémon con Gemini 2.5, una alucinación entró al contexto y se reforzó al citarse en turnos posteriores, desviando la estrategia. Esto conecta directo con seguridad: el poisoning es primo del prompt injection, porque un dato hostil inyectado vía conversación puede contaminar todos los turnos futuros. [D]
Just-in-time retrieval: el agente explora, tú no precargas
En vez de precargar todos los datos en la ventana (estilo RAG de embeddings que inyecta un blob), el agente mantiene identificadores ligeros (paths, queries, links) y carga datos bajo demanda con tools, descubriendo relevancia progresivamente: el tamaño de un fichero insinúa complejidad, los nombres insinúan propósito, los timestamps insinúan recencia. El centro de gravedad pasa de "pipeline de recuperación" a "agente que explora".
Indexas todo el corpus, recuperas top-k por similitud, inyectas el blob en la ventana. Pagas el pipeline, la indexación y el drift, y el agente recibe lo que el retriever decidió. Sigue siendo la opción correcta para corpus enormes y heterogéneos.
El agente usa grep/glob/read sobre ficheros y decide qué leer turno a turno. Sin embeddings, sin indexación. Para corpus acotados iguala o supera a RAG, y esquiva por completo el problema del drift del índice. El criterio del retriever lo reemplaza el del agente. [C]
El trade-off es real: just-in-time significa exploración más lenta en runtime y más turnos navegando. Para un conjunto pequeño de documentos que cambia seguido, es un buen trato. Para un millón de PDFs heterogéneos no lo es, y un híbrido (pre-indexar lo obvio, explorar el resto) suele ganar.
Compaction y memoria: descartar sin perder lo crítico
Compaction no es "resumir". Es una operación con pérdida donde eliges qué tirar, con el riesgo de tirar contexto sutil pero crítico (una decisión de arquitectura, un bug sin resolver). La recomendación de Anthropic es maximizar recall primero, preservar de más, y luego iterar sobre la precisión eliminando lo superfluo.
Pero compaction sola no basta en horizontes muy largos. Anthropic lo dice sin rodeos: incluso un modelo frontera como Opus 4.5 se queda corto en tareas de larguísimo horizonte solo con compaction. La complementas con memoria en filesystem (ficheros como claude-progress.txt, feature_list.json, git) más verification loops. Eso es structured note-taking: memoria long-term write-through que sobrevive a los resets de contexto.
La distinción arquitectónica clave es short-term vs long-term. La memoria de corto plazo es el turno o la sesión (el transcript de la sesión). La de largo plazo cruza sesiones (un fichero de notas por usuario). Frameworks como Mem0 van más allá de la memoria "plana": añaden extracción y consolidación para recuperación selectiva, en vez de recargar el fichero entero cada vez.
Profundizar: cómo aproxima la compaction un harness real
Un harness no necesita un paso explícito de compaction-LLM para sacar casi todo el beneficio. Un patrón común: rotar a una sesión nueva tras N turnos, persistir solo un puntero más el conteo de turnos, y reanudar con un fallback de recap si el resume del SDK falla (distinguiendo el abort por timeout de un error real). La memoria long-term es entonces un save write-through: la base de datos es la fuente de verdad, el fichero de notas local es la cache del turno. El transcript de la sesión es memoria de corto plazo; el fichero de notas es de largo plazo. Nada de esto es compaction "de verdad", pero la combinación de rotación más notas externalizadas cubre el mismo fallo que pretende prevenir: la ventana llenándose de turnos viejos.
La tensión ignorada: pruning vs prompt caching
Aquí está el conocimiento de producción que casi todos pasan por alto: comprimir o podar el historial invalida los prefijos cacheados. El prefix caching (el KV cache) exige prefijos estables. Si rotas o recortas el principio del prompt, el cache se rompe y vuelves a pagar el prefijo entero.
El remedio es el layout cache-aware (dynamic-content-at-the-end): pon los prefijos estables (system prompt, definiciones de tools, persona) al inicio para maximizar el cache, y mueve lo que cambia cada request (timestamps, session ids, input del usuario) al final.
[ system prompt ] prefijo estable, cacheable (~0.1x en hits)
[ defs de tools ] prefijo estable
[ persona ] prefijo estable
[ historial ] semi-estable
[ timestamp, session_id, input del usuario ] volátil, va AL FINALEl conflicto es real y es una decisión de arquitectura, no un detalle: gestión agresiva de contexto (pruning, compaction) contra hit rate del cache. El experto elige el trade-off coste-precisión-latencia de forma deliberada. Un matiz de durabilidad: este conocimiento de caching es efímero (las APIs cambian sus mecanismos), mientras que el presupuesto de atención es atemporal. [D]
Aislamiento vía sub-agentes, y su contra-tesis
Un sub-agente con ventana limpia puede explorar con decenas de miles de tokens y devolver solo 1-2K tokens destilados al coordinador, manteniéndolo sin contaminar. Es aislamiento de contexto puro. Pero hay un debate genuino que un ingeniero serio tiene que saber arbitrar.
Para investigación read-heavy y paralela con tareas self-contained, los sub-agentes funcionan: cada uno trae su hallazgo condensado y no coordinan a mitad de tarea. El régimen donde el multi-agente se gana su sitio es la investigación paralela, intensiva en lectura.
Las acciones llevan decisiones implícitas; los sub-agentes paralelos toman decisiones conflictivas que no se reconcilian. El ejemplo: pides un Flappy Bird y sale algo medio Super Mario. El argumento es single-threaded más un LLM de compresión dedicado.
Lo que el consenso sobrevalora y lo que ignora
Sobrevalorado: la obsesión con ventanas más grandes (1M tokens) como solución; el context rot demuestra que llenar la ventana degrada la precisión, lo que importa es la densidad de señal, no la capacidad. El prompt engineering como disciplina autónoma; es un subconjunto del context engineering. El NIAH léxico como prueba de capacidad. El multi-agente "por defecto porque escala". El RAG de embeddings como respuesta automática a "no cabe".
Ignorado o subutilizado: existe una ventaja modesta al inicio de la secuencia (apareció en la tarea de generación de Chroma, aunque no en retrieval puro), así que poner instrucciones y reglas HITL al frente es una palanca barata que casi nadie aplica a propósito — eso sí, no esperes que ponerlo al frente rescate una aguja enterrada en el medio. Las tools también son contexto: definiciones bloated o ambiguas causan confusion, así que reducir y desambiguar el set de tools es context engineering, no solo diseño de API. La memoria sin verificación es deuda: una memoria write-through sin gate de calidad puede persistir datos envenenados que contaminan todos los turnos futuros. Y la estructura ayuda: headers Markdown o XML y secciones mejoran el seguimiento de instrucciones frente a "todo en un blob".
Errores comunes
El hilo conductor es un reflejo. Cuando el agente se degrada en una corrida larga, no busques una ventana más grande. Nombra la patología, encuentra los tokens viejos y decide qué descartar.