Context compaction: gestionar la ventana en agentes

Todo el que ha construido un agente que hace algo no trivial se ha topado con el mismo muro. La tarea avanza bien durante un rato, el agente ejecuta acciones, acumula resultados, progresa. Y de pronto empieza a comportarse de forma errática: olvida lo que hacía, repite pasos, se contradice. Casi siempre la causa es la misma: la ventana de contexto se ha llenado, y el modelo ya no ve la información que necesita.

La compactación —context compaction— es la disciplina que resuelve este problema. Consiste en comprimir el historial acumulado de una tarea para que quepa en la ventana, conservando lo esencial y descartando lo prescindible. Suena simple. No lo es. Decidir qué es esencial y qué es prescindible, y hacerlo sin romper la coherencia de la tarea, es uno de los problemas más finos del desarrollo de agentes. Este artículo lo desglosa.

Por qué se llena la ventana#

La ventana de contexto de un modelo es finita. Aunque las ventanas han crecido mucho, siguen teniendo un límite, y hay dos razones por las que llegar a ese límite es un problema, no solo una restricción.

La primera es obvia: si el historial no cabe, algo hay que quitar, y si quitas lo equivocado, el agente pierde información crítica. La segunda es más sutil y a menudo se ignora: incluso cuando la información cabe, una ventana muy llena degrada el rendimiento. Los modelos no procesan igual de bien un contexto saturado que uno limpio. Hay un fenómeno bien documentado por el que la información en el medio de un contexto largo se atiende peor que la del principio o el final. Una ventana llena no es solo un problema de capacidad; es un problema de calidad de atención.

En un agente, la ventana se llena rápido porque cada iteración del bucle añade material: la acción propuesta, el resultado de ejecutarla —que puede ser voluminoso, como el contenido de un archivo o la respuesta de una API—, la verificación. Multiplica eso por decenas de iteraciones y el historial se dispara. La compactación es lo que impide que ese crecimiento ahogue la tarea. Y también lo que impide que crezca la factura, porque cada iteración vuelve a pagar el contexto acumulado: es una de las palancas de qué pagas de verdad en tokens.

Cuándo compactar: los disparadores#

El primer diseño que hay que tomar es cuándo activar la compactación. Compactar demasiado pronto desperdicia información útil; demasiado tarde, y ya has degradado el rendimiento o desbordado la ventana.

El disparador más común es un umbral de ocupación: cuando el contexto alcanza cierto porcentaje de la ventana —pongamos el 70 u 80 por ciento—, se activa la compactación. Es sencillo y funciona bien en la mayoría de casos. Deja margen para que la siguiente iteración quepa mientras se procesa la compactación. El disparador vive dentro de el ciclo que repite un agente hasta terminar, que es quien lo evalúa en cada vuelta.

Otros disparadores son más específicos. Se puede compactar tras completar una subtarea, cuando cierto bloque de contexto ya no será necesario. O compactar cuando se detecta que un resultado voluminoso —un log enorme, un archivo largo— ya ha sido procesado y solo hace falta su conclusión, no su contenido íntegro. La elección del disparador depende de la naturaleza de la tarea y de cómo crece su contexto.

Qué conservar y qué descartar#

Aquí está el corazón del problema. Compactar es, en esencia, decidir qué sobrevive. Hay varias estrategias, y las buenas implementaciones combinan varias.

La poda de resultados intermedios parte de una observación simple: muchos resultados voluminosos solo importan por su conclusión. Si el agente leyó un archivo de mil líneas para extraer un dato, una vez extraído el dato, las mil líneas pueden irse. Se conserva la conclusión, se descarta el material bruto que la produjo.

El resumen del historial sustituye una secuencia larga de pasos por un resumen conciso de lo ocurrido. En lugar de conservar cada acción y resultado de las primeras veinte iteraciones, se reemplazan por un párrafo que capta el estado alcanzado: qué se ha hecho, qué se ha aprendido, dónde está la tarea. Este resumen lo puede generar el propio modelo, en una llamada dedicada a compactar.

La preservación selectiva mantiene intactas ciertas piezas que nunca deben comprimirse: el objetivo original de la tarea, las restricciones clave, las decisiones irreversibles ya tomadas. Estas anclas garantizan que, por mucho que se comprima el historial, el agente no pierde de vista qué está intentando lograr ni qué límites debe respetar.

La combinación típica es una estructura por capas: el objetivo y las restricciones se preservan siempre; el historial antiguo se resume; los resultados intermedios ya procesados se podan; y las últimas iteraciones se conservan en detalle porque son las más relevantes para el siguiente paso. Es una jerarquía de importancia que refleja cómo la relevancia de la información decae con el tiempo, salvo para las anclas que siempre importan.

El riesgo de la compactación#

La compactación no es gratis, y conviene ser honesto sobre sus peligros. Cada vez que comprimes, corres el riesgo de descartar algo que resultará necesario más adelante. Un dato que parecía irrelevante en la iteración diez puede ser justo lo que el agente necesita en la treinta. La compactación agresiva ahorra espacio pero aumenta el riesgo de amnesia.

Hay también un coste computacional. Resumir el historial con una llamada al modelo consume tokens y tiempo. Compactar con demasiada frecuencia añade sobrecarga que puede superar el beneficio. Como todo en el harness engineering, es un trade-off que hay que calibrar: compactar lo justo para mantener la ventana sana, sin compactar tanto que el proceso se vuelva un lastre o que se pierda información valiosa.

Una salvaguarda útil es no descartar de forma irreversible. Algunos sistemas, en lugar de borrar el material compactado, lo archivan fuera de la ventana de contexto pero accesible mediante una herramienta. Así, si el agente necesita un detalle que fue compactado, puede recuperarlo. Esto convierte la compactación de una pérdida definitiva en un movimiento del material a un almacenamiento secundario. Es más complejo de implementar, pero mucho más robusto.

La conexión con el enfoque de archivos#

Aquí reaparece una idea que vimos al tratar el paso del prompt al context engineering: el enfoque basado en sistema de archivos. Cuando un agente trabaja con la información como archivos que puede leer bajo demanda, en lugar de cargarla toda en el contexto, el problema de la compactación se transforma. Ya no necesitas mantener todo el contenido en la ventana; mantienes referencias, y el agente lee lo que necesita cuando lo necesita.

Este patrón —tratar el sistema de archivos como memoria externa— es una de las formas más elegantes de gestionar el contexto en tareas largas. En lugar de compactar agresivamente un historial que lo contiene todo, mantienes una ventana ligera con referencias y dejas que el agente recupere detalles a demanda. Reduce la presión sobre la compactación al reducir cuánto necesita estar en la ventana en primer lugar.

Lo que hay que retener#

La compactación es lo que separa a un agente que abandona a las pocas iteraciones de uno que sostiene tareas largas y complejas. No es un detalle de optimización; es una capacidad fundamental que determina el horizonte de lo que un agente puede abordar, y una de las piezas del sistema que envuelve al modelo.

Las ideas clave son cuatro. Compactar no es solo un problema de capacidad, también de calidad: una ventana saturada degrada el razonamiento. El cuándo importa: umbrales de ocupación bien elegidos evitan tanto la pérdida prematura como el desbordamiento. El qué importa más: preservar anclas, resumir historial, podar lo procesado. Y el riesgo es real: la compactación agresiva ahorra espacio a costa de amnesia, y archivar en lugar de borrar es la salvaguarda más robusta.

Dominar la compactación es dominar el tiempo en un agente: la capacidad de mantener la coherencia a lo largo de una tarea que dura mucho más de lo que cabe en una sola ventana. Y en un mundo donde los agentes abordan tareas cada vez más largas, esa capacidad es cada vez más el factor que decide si funcionan.