La compactación se come tus decisiones: gestionar la ventana de contexto

Este es un fallo que he visto más de una vez. Al principio de una sesión larga, le digo al agente una restricción: este servicio tiene que seguir siendo idempotente, el proveedor reintenta. Tres horas después, metido en el trabajo, el agente escribe un handler que no es idempotente. No está siendo descuidado. De verdad ya no sabe la restricción, porque la ventana se llenó, la sesión compactó, y mi instrucción de la primera hora se resumió hasta desaparecer. La decisión que hacía correcta la tarea entera ya no está, y nada anunció su marcha.

Ese es el coste silencioso de la ventana de contexto. Es un contenedor de tamaño fijo, y un run largo produce más material del que cabe. Algo tiene que ceder, y lo que cede suele ser lo que dijiste una vez, pronto, y nunca repetiste: la restricción, la decisión, el motivo. El agente no para cuando lo olvida. Sigue con la misma seguridad, ahora optimizando contra un contrato que ya no puede ver. En cualquier trabajo lo bastante largo como para importar, la ventana deja de ser infinita y pasa a ser un presupuesto que tienes que gestionar.

Qué tira de verdad la compactación

Cuando una sesión se queda sin ventana, la herramienta compacta: resume los turnos viejos para hacer sitio. Útil, y necesario, pero resumir tiene pérdidas por diseño, y no las tiene al azar. Se queda con lo que parece importante localmente en el flujo reciente y suelta lo que parece detalle viejo. Una restricción de una línea que dijiste hace tres horas y nunca volviste a mencionar parece exactamente detalle viejo desechable, aunque sea la frase que más sostiene el edificio de todo el run.

Así que la compactación tiene un sesgo: preserva la forma de la conversación reciente y erosiona las decisiones que anclaron el principio. El “nunca debemos hacer X” del principio se comprime hasta nada mientras los últimos veinte minutos de detalle de implementación se quedan nítidos. Este es el mecanismo detrás de toda una clase de fallos de run largo, y es por qué un run deriva en medio en vez de crashear: el agente no se rompió, olvidó, y luego siguió construyendo con seguridad sobre el hueco.

El propio relato de Anthropic sobre context engineering efectivo para agentes de IA deja claro el punto de fondo: la atención es finita, y más tokens en la ventana no es lo mismo que más entendimiento. Pasado un punto, añadir contexto degrada el agarre del agente sobre lo que importa en vez de mejorarlo. La ventana es un recurso con techo, y tratarla como ilimitada es como consigues una amnesia con seguridad.

La ventana es un presupuesto, no un almacén

El cambio mental que arregla casi todo esto es dejar de tratar la ventana de contexto como almacenamiento y empezar a tratarla como un presupuesto que gastas a propósito. Un almacén es donde metes todo y asumes que estará ahí después. Un presupuesto es finito, y cada token que gastas en ruido es un token no disponible para la decisión que importa.

Dos cosas se siguen de ese marco.

Primero, qué entra en la ventana es una elección, no un default. Volcar el repo entero, la historia completa y cada fichero de reglas en cada llamada no es minuciosidad, es gastar tu presupuesto en cosas que el agente no necesita para esta tarea, que es el argumento central de context engineering para agentes de código: cura lo que el agente ve, no lo inundes. Un trozo preciso de los ficheros correctos gana al árbol entero.

Segundo, las decisiones que deben sobrevivir no pueden vivir solo en la ventana. Si la única copia de “esto tiene que seguir siendo idempotente” es un mensaje en el transcript, la compactación puede comérsela y se la comerá. El arreglo no es repetirla más fuerte. Es guardarla en algún sitio que la ventana no posea, un fichero, una tarea, un contrato, y volver a suministrarla cuando importa, para que la restricción dure más que cualquier resumen. Este es el gemelo dentro de sesión de perder contexto entre sesiones: el mismo fallo a menor escala de tiempo, con el mismo arreglo.

Presupuestar la ventana en trabajo largo

En concreto, así evito que los runs largos se olviden de sí mismos, todo posible hoy:

• Mantén el contrato fuera del transcript. Las restricciones y los criterios de aceptación viven en un artefacto, no solo en algo que el agente dijo pronto. Así la compactación no las puede borrar, y cualquier sesión resumida o traspasada puede releerlas. Es la misma razón por la que un handoff limpio carga un paquete destilado en vez de la historia en bruto.
• Gasta el presupuesto en la tarea, no en el archivo. Carga los ficheros que este paso necesita, no el repo entero. Un contexto más pequeño y afilado cabe mejor y produce mejor output.
• Vuelve a anclar en las fronteras. En cada frontera de episodio, reafirma las restricciones vivas en el contexto de trabajo. Cuesta unos tokens y te compra un agente que aún sabe las reglas.
• Vigila los ficheros de reglas. Cada línea de un fichero de reglas que el agente autocarga es presupuesto gastado en cada llamada. Un fichero de reglas obsoleto e inflado no solo despista, es caro, desplazando el contexto que la tarea de verdad necesita.
• Haz checkpoint antes de que la compactación muerda. Si un run se acerca al techo, un checkpoint con el estado actual escrito significa que una sesión fresca puede continuar desde un contexto limpio y pequeño en vez de uno compactado y con pérdidas.

El patrón bajo todo ello: la ventana sostiene el conjunto de trabajo, no la fuente de verdad. Todo lo que tiene que sobrevivir al run entero vive fuera de la ventana y se vuelve a suministrar bajo demanda.

Dónde encaja PaellaDoc

La compactación se come decisiones porque la ventana es finita y resumir está sesgado contra la restricción vieja que ancló el trabajo, y el arreglo es guardar lo que debe sobrevivir fuera de la ventana y volver a suministrarlo cuando cuenta. Ese es el mecanismo, y es por qué no creo que una ventana más grande sola resuelva esto: un presupuesto mayor también se llena, y también erosiona el ancla primero, que es la misma razón por la que los agentes necesitan un runtime, no un modelo más grande. PaellaDoc guarda el contrato y las decisiones como artefactos fuera de la ventana de cualquier sesión y le da al agente el trozo que necesita, así que un run largo se sostiene contra restricciones que no puede olvidar en vez de contra unas que resumió y perdió. La persona que vuelve a anclar al agente a mano cada vez que deriva es el runtime, hasta que la ventana se gestiona por ella.

FAQ

¿Por qué mi agente olvida instrucciones durante una sesión larga?

Porque la ventana de contexto es de tamaño fijo, y cuando se llena la sesión compacta resumiendo los turnos viejos. Resumir tiene pérdidas y está sesgado a quedarse con el detalle reciente, así que una restricción de una línea del principio que nunca repetiste es exactamente el tipo de cosa que se borra, mientras la charla de implementación reciente sobrevive. El agente entonces sigue trabajando sin la instrucción, sin saber que ya no está.

¿Una ventana de contexto más grande arregla esto?

Sube el techo pero no cambia el mecanismo. Una ventana mayor también se llena en trabajo largo, y la compactación sigue erosionando primero las decisiones de anclaje del principio. Más tokens tampoco es lo mismo que más entendimiento, pasado un punto el contexto extra degrada el foco del agente. El arreglo duradero es guardar las restricciones que deben sobrevivir fuera de la ventana y volver a suministrarlas, no confiar en un almacén más grande.

¿Cómo evito que la compactación pierda decisiones importantes?

Sácalas del transcript. Guarda las restricciones y los criterios de aceptación en un artefacto que la ventana no posea, reafirma las vivas en cada frontera de episodio, haz checkpoint antes de tocar el techo, y carga solo los ficheros que un paso de verdad necesita en vez de inundar la ventana. La ventana debería sostener el conjunto de trabajo; la fuente de verdad vive fuera de ella.