Anthropic publica guía para agentes de larga duración | Keryc
La IA ya no es solo respuestas rápidas. Cada vez se le pide a los agentes que trabajen horas o incluso días en proyectos complejos, pero los contextos limitados rompen la continuidad. ¿Cómo lograr que un agente avance coherentemente cuando cada sesión empieza sin memoria?
El problema de los agentes de larga duración
Imagina un proyecto de software donde cada turno llega sin memoria de lo anterior. Eso es exactamente lo que pasa cuando un agente debe trabajar a través de múltiples ventanas de contexto: la sesión es discreta y la siguiente no recuerda nada.
Los modelos avanzados (por ejemplo Opus 4.5 en el Claude Agent SDK) tienen herramientas como compaction para ahorrar tokens y mantener información relevante. Sin embargo, compaction no basta: el agente puede intentar "hacerlo todo" en una sola sesión y dejar trabajo a medias, o bien declarar el proyecto terminado antes de verdad. ¿Resultado? Código incompleto, documentación ausente y sesiones que pierden tiempo tratando de entender el pasado.
Anthropic propone un arnés con dos piezas clave: un initializer agent que prepara el entorno en la primera sesión, y un coding agent que, en cada sesión posterior, hace progreso incremental y deja artefactos claros para la siguiente sesión.
Initializer agent
Crea el repo inicial con un init.sh para levantar el servidor.
Genera un archivo claude-progress.txt que registra lo que cada sesión hizo.
Produce un feature_list.json con una lista extensa de requisitos end-to-end (en su demo, más de 200 features para un clon de claude.ai).
Hace el primer commit en git para dejar un historial inicial.
La idea es dejar suficiente contexto fuera del modelo (en archivos y commits) para que cualquier nueva sesión pueda entender qué se ha avanzado.
Coding agent
Al inicio de cada sesión ejecuta comandos básicos como pwd, lee claude-progress.txt, feature_list.json y el git log.
Elige un solo feature de alta prioridad que aún no pase.
Implementa ese feature, lo prueba end-to-end (idealmente con browser automation), hace un commit con mensaje descriptivo y escribe un update en claude-progress.txt.
Este enfoque evita el "one-shot" y fuerza incrementos pequeños y verificables que facilitan la recuperación ante errores.
Gestión del entorno y archivos claves
Anthropic encontró que ciertos archivos reducen la ambigüedad entre sesiones:
init.sh: script para iniciar el servidor y pruebas básicas.
feature_list.json: lista de features como objetos JSON que incluyen pasos y un campo passes (booleano).
claude-progress.txt: log humano/máquina de cambios y decisiones.
Git history: permite regresar a estados estables.
Ejemplo de entrada en feature_list.json (simplificado):
{ "category": "functional", "description": "New chat button creates a fresh conversation", "steps": ["Navigate to main interface", "Click the 'New Chat' button", "Verify a new conversation is created"], "passes": false }
Anthropic recomienda no permitir que los agentes borren o reescriban las pruebas; solo deben cambiar passes a true tras verificaciones rigurosas.
Pruebas y verificación
Un fallo común fue marcar features como completas sin verificar end-to-end. La solución pasó por dar al agente herramientas de testing (por ejemplo Puppeteer MCP) y pedir explícitamente que haga pruebas como un usuario: abrir la app, crear un chat, enviar un mensaje y verificar la respuesta.
Limitaciones: la visión del modelo y las herramientas de automatización no son perfectas. Por ejemplo, Puppeteer puede no exponer modales nativos del navegador, y esos casos siguen siendo frágiles.
Flujo típico de una sesión
[Assistant] Me voy a poner al día con el estado del proyecto.
[Tool Use] bash - pwd
[Tool Use] read - claude-progress.txt
[Tool Use] read - feature_list.json
[Tool Use] bash - git log --oneline -20
[Tool Use] iniciar init.sh y verificar que el servidor corre.
[Assistant] Ejecutar pruebas básicas de funcionalidad.
[Tool Use] Empezar a implementar la feature seleccionada.
[Assistant] Hacer commit y escribir el update en claude-progress.txt.
Este patrón reduce tokens desperdiciados y prioriza restaurar un estado estable antes de añadir nuevo código.
Modos de fallo y contramedidas
Problema: el agente declara el proyecto terminado demasiado pronto.
Initializer: genera feature_list.json con requisitos end-to-end.
Coding agent: lee la lista y trabaja en una sola feature.
Problema: código desordenado o con bugs al final de la sesión.
Initializer: deja historial git y notas de progreso.
Coding agent: corre tests, hace commits descriptivos y actualiza claude-progress.txt.
Problema: marcar features como listas sin pruebas.
Initializer: estructura la lista de features.
Coding agent: auto-verifica y solo marca passes=true tras pasar pruebas.
Problema: el agente no sabe cómo ejecutar la app.
Initializer: escribe init.sh.
Coding agent: lo ejecuta al inicio.
Futuro y preguntas abiertas
Queda por probar si un agente generalista es mejor que una arquitectura multi-agente especializada (testing agent, QA agent, cleanup agent). También hay que validar si estas prácticas generalizan fuera de full-stack web apps, por ejemplo a investigación científica o modelado financiero.
Desde la práctica, esto es una lección clara: para hacer que la autonomía de IA funcione en horizontes largos necesitas trasladar parte de la memoria al disco y al control de versiones. ¿Suena obvio? Tal vez. ¿Funciona? En los experimentos de Anthropic, sí: mejora la coherencia, reduce tiempo perdido y facilita recuperación ante errores.
