El arnés, no el modelo: cuatro mecanismos para que un agente no pierda el hilo en tareas largas

Qué es en realidad un agente y por qué se rompe

Un agente, en su forma más simple, es un modelo de lenguaje que llama a herramientas dentro de un bucle: piensa, ejecuta una acción, mira el resultado y vuelve a empezar. Ese bucle funciona bien en encargos cortos. El problema aparece cuando la tarea dura una hora y acumula doscientas llamadas.

La guía de diseño de AWS Samples para agentes autónomos de programación en la nube nombra los fallos sin rodeos: los agentes superficiales sufren desbordamiento de contexto, se distraen —pierden el objetivo— y no mantienen el estado durante periodos largos. Y señala dónde está la solución: no en el modelo, sino en el arnés, que AWS describe como la capa que gestiona todo lo que no es el modelo.

Dicho de otro modo: cambiar de modelo no cura estos fallos. Lo que los cura es la maquinaria que decide qué entra en la memoria de trabajo del modelo, qué se resume, qué se guarda fuera y qué se vuelve a recordar en cada turno.

El arnés: la capa de la que casi nadie habla

Cuando alguien dice que un agente «es muy bueno», casi siempre está describiendo el arnés más que el modelo. El arnés decide qué información llega al modelo antes de la primera instrucción, qué se descarta a mitad de tarea, cuándo se resume la conversación y qué sobrevive de una sesión a la siguiente.

Cuatro mecanismos componen esa maquinaria: presupuesto y descarga de contexto, compactación, estado de tareas con recitación, y estrategia de memoria entre sesiones. Los cuatro persiguen el mismo objetivo con herramientas distintas: que el modelo llegue al final de la tarea con el encargo original todavía fresco.

Por qué una ventana más grande no arregla el problema

La reacción intuitiva es pedir una ventana de contexto mayor. Las pruebas dicen que ayuda menos de lo esperado. El informe Context Rot de Chroma evaluó dieciocho modelos, entre ellos GPT-4.1, Claude 4, Gemini 2.5 y Qwen3, y encontró que el rendimiento se vuelve cada vez menos fiable a medida que crece la entrada, incluso en tareas simples de recuperación de datos.

La guía de ingeniería de contexto de Anthropic explica el mecanismo: la atención crea n² relaciones por pares para n tokens, así que cada token añadido consume parte de un «presupuesto de atención» finito. El contexto no es un cubo que se llena: es un recurso con rendimientos decrecientes.

En un bucle de agente la cosa empeora. Manus informa de que una tarea típica necesita unas cincuenta llamadas a herramientas y de que la proporción entre tokens de entrada y de salida ronda 100:1. Cada observación aterriza en el contexto y se queda ahí. La instrucción original va quedando desplazada hacia el centro de la ventana, que es justo la zona donde la recuperación se degrada. La pérdida del objetivo no es solo un fallo del modelo: es el resultado esperable de un contexto sin gestionar en una tarea suficientemente larga.

Los dos fallos que hay que evitar

Conviene tener claros los dos síntomas, porque los cuatro mecanismos se entienden mejor como respuestas a ellos.

El desbordamiento de contexto es el fallo material: no cabe más. El agente ha ido acumulando salidas de herramientas, contenidos de archivos y razonamientos hasta agotar la ventana, y la tarea se corta.

La pérdida del objetivo es el fallo silencioso, y el más peligroso: el agente sigue funcionando, sigue llamando a herramientas y produciendo texto, pero ya no está haciendo lo que se le pidió. Nadie ve un error; simplemente el resultado no sirve.

Mecanismo 1: presupuestar el contexto y descargar lo que sobra

El primer trabajo de un arnés es decidir qué no entra nunca en la ventana. Deep Agents lleva de serie dos reglas de descarga con números concretos. Cuando la respuesta de una herramienta supera los 20.000 tokens, se escribe en el sistema de archivos y en el contexto se deja solo la ruta del archivo más una vista previa de las diez primeras líneas. Y cuando el contexto de la sesión rebasa el 85% de la ventana del modelo, las llamadas antiguas de escritura y edición —cuyo contenido completo ya está en disco— se recortan hasta dejar únicamente un puntero. Solo cuando la descarga se queda sin margen recurre el arnés al resumen.

Claude Code aplica el mismo criterio a lo que se carga antes incluso de la primera instrucción. La memoria automática está topada en las primeras 200 líneas o 25 KB. Los esquemas de herramientas MCP quedan diferidos por defecto: se listan solo los nombres y los esquemas completos se cargan bajo demanda mediante búsqueda de herramientas. Y tras una compactación, cualquier archivo releído que pase de 5.000 tokens vuelve como referencia de ruta en lugar de como contenido.

Subagentes: presupuestar a nivel de arquitectura

El patrón de subagente lleva la misma idea un escalón más arriba. La simulación de ventana de contexto de la documentación de Claude Code lo pone en cifras: un subagente de investigación lee 6.100 tokens de archivos y devuelve al agente principal un resultado de 420 tokens. Todo el desorden de la exploración se queda fuera de la ventana del coordinador.

La guía de Anthropic apunta que cada subagente puede consumir decenas de miles de tokens explorando, pero devuelve un resumen destilado, a menudo de entre 1.000 y 2.000 tokens. El recorrido de AWS con AgentCore construye exactamente eso: un coordinador lanza tres subagentes de navegación en paralelo, cada uno en su propia MicroVM, y un subagente analista recibe únicamente sus hallazgos estructurados. AWS calcula un tiempo de ejecución esperado de cuatro a seis minutos y señala que el procesamiento secuencial tardaría hasta el triple.

Mecanismo 2: compactación, o cómo resumir sin perder lo importante

Cuando la descarga ya no basta, el arnés resume. La compactación consiste en coger una conversación que se acerca al límite de la ventana, resumirla y reiniciar un contexto nuevo con ese resumen. Es también el momento en que más a menudo se pierde el objetivo, porque un resumen con pérdidas puede dejar fuera precisamente la restricción que importaba.

Las implementaciones se diferencian en qué prometen conservar. La instrucción de compactación de Claude Code preserva decisiones de arquitectura, errores sin resolver y detalles de implementación, y descarta salidas de herramientas redundantes. Justo después vuelve a leer hasta cinco de los archivos modificados más recientemente, recarga las reglas que corresponden a esos archivos y reinyecta los cuerpos de las skills invocadas, con un tope de 5.000 tokens por skill y 25.000 en total. La documentación es explícita: las instrucciones detalladas del principio de la conversación pueden perderse, y por eso las reglas persistentes deben vivir en el CLAUDE.md de la raíz del proyecto, que se reinyecta desde disco. El usuario puede orientar la pasada con /compact focus on the auth bug fix o mover el punto de activación con /autocompact.

Deep Agents convirtió la conservación del objetivo en una característica estructural. Su resumen es un documento con campos dedicados a la intención de la sesión, los artefactos creados y los siguientes pasos; el equipo de LangChain añadió esos campos después de que experimentos de resumen forzado mostraran que el cambio mejoraba el rendimiento. Además, la transcripción original completa se escribe en el sistema de archivos, de modo que un dato eliminado por el resumen puede recuperarse más tarde con read_file.

La compactación baja a la capa de API

El mecanismo ha dejado de ser cosa exclusiva de las aplicaciones. La Responses API de OpenAI ofrece compactación en servidor mediante context_management con un compact_threshold, y además un endpoint independiente /responses/compact que devuelve una ventana de contexto compactada con un elemento de compactación cifrado y opaco; OpenAI indica a los desarrolladores que pasen esa ventana devuelta sin modificar a la siguiente llamada. OpenAI afirma que Codex se apoya en este mecanismo para sostener tareas largas de programación.

La Claude Developer Platform expone una edición de gestión de contexto llamada compact_20260112, con instrucciones personalizadas y una opción pause_after_compaction para insertar contenido antes de que el modelo continúe. Un detalle importante: cuando se escriben instrucciones personalizadas ahí, sustituyen por completo a la instrucción por defecto. Una instrucción de compactación no es un ajuste menor, es una pieza de ingeniería en sí misma.

Mecanismo 3: estado de tareas y recitación del objetivo

La compactación protege el objetivo en el momento del resumen. El estado de tareas lo protege en todos los turnos intermedios. Manus lo describió sin adornos: su agente crea un todo.md y lo reescribe paso a paso, tachando lo ya hecho. Reescribir la lista recita los objetivos al final del contexto, empuja el plan global hacia el tramo de atención reciente del modelo y reduce la deriva del «perdido en el medio». No hace falta cambiar la arquitectura: es lenguaje natural usado para sesgar la atención del propio modelo.

La evidencia, eso sí, no es unánime. Deep Agents incluía por defecto una herramienta write_todos hasta la versión v0.7, de julio de 2026, cuando LangChain pasó TodoListMiddleware a modo opcional porque sus evaluaciones en tres categorías de tarea mostraron una recompensa ligeramente mejor y un coste menor con las tareas desactivadas. LangChain sigue recomendando activarlo en tareas largas de varios pasos, con modelos menos capaces y en interfaces que muestran progreso.

Claude Code mantiene una lista de tareas y reinyecta desde disco, tras la compactación, el plan escrito en modo plan. La guía de Anthropic llama al patrón general toma de notas estructurada: el agente escribe un NOTES.md o un archivo de tareas fuera de la ventana y lo recarga. Su ejemplo de Claude Plays Pokémon mantuvo recuentos a lo largo de miles de pasos de juego, releyó sus propias notas después de cada reinicio de contexto y retomó secuencias de varias horas.

El hilo común es que el objetivo existe como artefacto mutable, no solo como un mensaje en el historial. Los mensajes envejecen y acaban resumidos. Un archivo que se reescribe cada pocos turnos siempre es reciente, siempre es corto y sobrevive a cualquier reinicio. Que compense su coste por turno depende del modelo y de la duración de la tarea, que es exactamente lo que midieron las evaluaciones de Deep Agents.

Mecanismo 4: memoria entre sesiones

La última pieza es qué queda cuando la tarea termina. Claude Code reinyecta desde disco el CLAUDE.md de la raíz del proyecto y la memoria automática después de cada compactación. AgentCore Memory almacena eventos y ejecuta en segundo plano las estrategias de extracción configuradas, de manera que en la siguiente ejecución un coordinador puede llamar a una herramienta de recuperación en lugar de volver a investigar desde cero. AWS advierte de que, si no se configura al menos una estrategia de extracción, los eventos en bruto se guardan pero no se extrae nada que luego pueda recuperarse. La herramienta de memoria basada en archivos de Anthropic cumple la misma función en su plataforma.

El límite es que el contexto persistente no es gratis. El estudio de ETH Zurich que cubrimos en febrero encontró que los archivos de contexto de repositorio como AGENTS.md no mejoran de forma general el éxito en las tareas y sí elevan el coste de inferencia: los archivos generados por modelos incrementaron el coste un 20% y un 23% en los dos bancos de pruebas, y los escritos por desarrolladores hasta un 19%. La memoria que se recarga en cada sesión es un impuesto fijo sobre el presupuesto de atención.

La documentación de Claude Code da el consejo que encaja con ese dato: mantener el CLAUDE.md por debajo de 200 líneas y trasladar el material de referencia a skills o a reglas acotadas por ruta, que solo se cargan cuando hacen falta.

Cómo comprobar que el arnés aguanta de verdad

La gestión de contexto solo vale si el agente sigue siendo capaz de terminar la tarea y de recuperar detalles que ya no tiene delante. LangChain mantiene evaluaciones dirigidas a eso: pruebas que disparan el resumen a mitad de tarea y comprueban si el agente continúa hacia su objetivo, y casos de aguja en un pajar en los que un dato queda eliminado por el resumen y debe recuperarse buscando en el sistema de archivos.

Para generar suficientes eventos y poder comparar variantes de instrucción, el equipo dispara el resumen al 10-20% de la ventana en lugar del 85% por defecto, y usó un umbral del 25% con Claude Sonnet 4.5 en terminal-bench-2 para estudiar el efecto.

El fallo que hay que vigilar, según LangChain, es la deriva del objetivo: un agente que pide aclaraciones justo después de un resumen, o que declara la tarea terminada cuando no lo está. AgentCore Evaluations incluye un evaluador de tasa de éxito de objetivo capaz de puntuar esas mismas trazas. La regla práctica es contundente: si tienes un arnés en producción y nunca has forzado una compactación en una prueba, todavía no sabes qué está tirando tu instrucción de resumen.