El problema que ves después de la décima llamada

¿Alguna vez viste un agente que en las primeras tres acciones hace lo correcto, pero en la sexta olvida una restricción que le diste al principio y falla? Sucede cuando la tarea es larga: los requisitos iniciales, los intentos fallidos, los subobjetivos abiertos terminan enterrados en el historial o más allá del límite de la ventana de contexto. El agente actúa solo sobre lo que ve en las últimas líneas, y pierde el estado decisional que cuenta.

El paper llama a este problema behavioral state decay, la degradación del estado conductual: la información relevante está en algún lugar de la trayectoria, pero el agente no la vuelve a traer a la superficie cuando necesita decidir.

Por qué te importa

Si estás construyendo un agente para tareas que duran más de algunos pasos, encuentras el problema de inmediato. Un debug de sistema que requiere diez comandos, un análisis que pasa por varios archivos, una configuración con dependencias para respetar: cada vez que la trayectoria se alarga, el estado relevante se dispersa. Hoy la solución más común es meter todo en el prompt del sistema o resumir periódicamente a mano, pero ninguna de las dos escala bien.

El paper propone una memoria activa que no espera a que le pregunten: un agente separado que observa la trayectoria reciente, actualiza una memoria estructurada y decide autónomamente si inyectar un recordatorio al agente de acción o permanecer en silencio. El módulo se adjunta a un agente existente sin modificarlo, y funciona con los frameworks que ya usas.

Si tienes un agente que pierde información en tareas largas, esta arquitectura te da un punto de partida concreto.

Qué dice el paper

Los autores construyeron un memory agent que corre en paralelo al action agent (el agente que decide las acciones). En cada paso:

1. Recibe la trayectoria reciente (últimas acciones, observaciones, outputs)
2. Decide si actualizar la memoria estructurada (un diccionario con claves como task_requirements, environment_facts, failed_attempts, diagnoses, open_subgoals)
3. Decide si inyectar un recordatorio textual al action agent o dejarlo trabajar sin intervención

La memoria no es una base de datos pasiva para consultar: el agente de memoria elige cuándo intervenir, y lo hace solo si cree que el estado relevante ya no es visible para el action agent.

Lo probaron en dos benchmarks:

• Terminal-Bench 2.0: tareas de terminal Linux que requieren secuencias largas (configuraciones de sistema, debug multi-paso)
• τ²-Bench: tareas en interfaces web y aplicaciones de escritorio, donde el agente debe recordar objetivos a través de múltiples páginas

Resultados en pass@1 (porcentaje de tareas completadas en el primer intento):

• Terminal-Bench: +8.3 puntos porcentuales con el agente de memoria versus el action agent solo (tanto para agentes más débiles como más fuertes)
• τ²-Bench: +6.8 puntos porcentuales

Los autores compararon cinco variantes:

1. Memory agent proactivo (el propuesto): inyecta recordatorios solo cuando decide que es necesario
2. Bank expuesto pasivamente: el action agent ve siempre el estado de memoria completo
3. Inyección continua: cada actualización se inyecta, siempre
4. Solo asesor: el agente de memoria propone acciones, no gestiona el estado
5. Retrieval genérico: recupera información bajo demanda, como RAG

La intervención selectiva supera todas las alternativas. Inyectar siempre crea ruido, exponer todo pasivamente no garantiza que el action agent lo use en el momento correcto, y el retrieval bajo demanda requiere que el agente sepa qué buscar.

Como prueba de concepto para una política de memoria open-weight, entrenaron Qwen3.5-27B en un dataset llamado SETA con supervised fine-tuning y GRPO (un algoritmo de reinforcement learning). El modelo mejora en validación y muestra transferencia parcial en Terminal-Bench, pero sigue siendo un experimento preliminar.

Cuánta confianza tener

Este paper trabaja sobre resúmenes e información de la página arXiv: el PDF completo no era accesible. Lo que sabemos:

• Las mejoras se miden en dos benchmarks específicos (Terminal-Bench 2.0 y τ²-Bench), que cubren tareas de terminal e interfaces gráficas, pero no representan todas las tareas largas posibles. Las ganancias en otros dominios aún quedan por verificar.
• La arquitectura es plug-and-play con agentes existentes, pero requiere un segundo agente LLM que corra en paralelo: hay un costo computacional y de latencia. El paper no reporta cuántas llamadas adicionales se necesitan por tarea, ni el tiempo total de ejecución.
• El entrenamiento de una política de memoria open-weight (Qwen3.5-27B) se describe como paso preliminar con transferencia parcial, no como solución lista para usar.
• Los ablations muestran que la intervención selectiva supera las alternativas probadas, pero no sabemos cuánto depende de la calidad del prompting del agente de memoria: una política más simple podría funcionar casi igual de bien.
• No está claro cómo escala el banco de memoria cuando las tareas duran decenas o cientos de pasos: en algún punto el estado estructurado también se llena.

En resumen: los resultados en los benchmarks son sólidos, la idea es clara y comprobable, pero los detalles de implementación y los límites prácticos requieren el paper completo para ser evaluados completamente.

Qué hacer con esto

Si estás construyendo un agente en tareas que duran más de cinco a diez pasos y ves que pierde información relevante, prueba esta arquitectura:

1. Agrega un segundo agente que observe la trayectoria reciente y mantenga un diccionario de estado (requisitos de la tarea, hechos del ambiente, intentos fallidos, subobjetivos abiertos).
2. Dale una política de intervención simple: inyecta un recordatorio solo si ve que el action agent está a punto de violar una restricción o repetir un error, de lo contrario permanece en silencio.
3. Prueba con y sin: mide el pass@1 en tus tareas. Si no mejora, el problema no es la memoria distribuida, es otra cosa (prompt inicial poco claro, observaciones ambiguas, ambiente demasiado inestable).

El error a evitar: pensar que basta exponer un log completo al action agent. El paper muestra que la intervención activa selectiva supera la exposición pasiva de memoria, porque reduce la carga cognitiva e inyecta la información solo cuando importa.

Otra implicación: si tu agente usa retrieval (tipo RAG sobre documentación), la memoria proactiva es complementaria, no alternativa: el retrieval recupera conocimiento estático bajo demanda, la memoria mantiene el estado decisional de la tarea en curso e inyecta sin esperar a que se le busque.

Dónde profundizar

En el sitio:

• Lección “Estado y memoria en agentes” (aún no publicada, en roadmap): cómo los agentes mantienen contexto en tareas multi-paso
• Scaffolding “Arquitectura de dos agentes” (por crear): esquema base para separar el agente de acción del agente de supervisión

Fuera del sitio:

• Paper en arXiv
• Terminal-Bench y τ²-Bench (busca los repos oficiales para las tareas de referencia)