dale a Claude una tarea lo suficientemente grande y la abandonará a mitad de camino, convencido de que ya terminó. El trabajo no está hecho. Simplemente no recuerda haberlo empezado.
Un agente no trabaja en una tarea larga como uno pensaría. Trabaja por turnos.
Imagina un proyecto de software atendido por ingenieros que trabajan en turnos, donde cada nuevo llega sin memoria de lo que pasó en el turno anterior. Eso no es una metáfora de cómo se sienten los agentes. Es mecánicamente lo que son. La ventana de contexto es finita, la mayoría del trabajo real no cabe en una sola, así que el agente trabaja en sesiones discretas – y cada nueva sesión comienza sin memoria de la anterior.
Anthropic realizó exactamente este experimento y publicó lo que falló. Esa es la parte que vale la pena leer, porque no es un blogger diciendo que la herramienta es débil. Es el equipo que construye Claude documentando dónde Claude se desmorona.
Por qué una sola ventana no puede terminar el trabajo
Dale a un modelo de código de frontera un prompt de alto nivel – "construye un clon de claude.ai" – ponlo en un bucle a través de muchas ventanas de contexto, y falla en producir una aplicación funcional. No a veces, sino de manera confiable. Y esto es Opus ejecutándose en el propio marco de agente de Anthropic, con la compactación de contexto activada, toda la configuración hecha para mantenerlo funcionando.
Falla de dos maneras específicas, y ambas son problemas de transferencia de turno.
La primera: el agente intenta hacer todo a la vez. Intenta resolver la aplicación completa en una sola ventana, se queda sin contexto a mitad de una funcionalidad, y la sesión termina con algo a medio construir y sin documentar. El siguiente turno llega, ve un desorden que no hizo, y tiene que adivinar qué estaba pasando. Así que pasa toda su sesión solo tratando de que la aplicación básica funcione de nuevo, en lugar de avanzar.
La segunda aparece más tarde, una vez que existen algunas funcionalidades. Un agente nuevo mira alrededor, ve que se ha hecho un progreso real, y decide que todo está terminado. Pero no lo está – la mitad de las funcionalidades nunca se construyeron, y nadie escribió cuáles. El turno lo dio por terminado sin revisar la lista.
Ambos fallos tienen la misma raíz. El turno que se va no dejó nada atrás, así que el turno que llega está volando a ciegas. La solución no es un modelo más inteligente. Es lo que el turno escribe antes de salir.
Lo que el turno que se va escribe
La respuesta en la que Anthropic se decidió tiene dos partes: un agente que configura el sitio antes de que comience cualquier trabajo, y luego los trabajadores por turnos que aparecen sesión tras sesión para avanzar.
El agente de configuración se ejecuta una vez, al principio. Su único trabajo es dejar el entorno en un estado donde cada turno futuro sepa cómo se ve "terminado". La pieza clave que escribe es una lista de funcionalidades – un archivo estructurado que detalla cada una de las cosas que la aplicación terminada debe hacer.
Para el clon de claude.ai, eso significó más de 200 funcionalidades. Cosas como "un usuario puede abrir un nuevo chat, escribir una consulta, presionar Enter y ver una respuesta". Cada una marcada como fallando al inicio. Cada entrada se veía más o menos así:
1{2 "description": "El botón de nuevo chat crea una conversación nueva",3 "steps": ["hacer clic en Nuevo Chat", "verificar conversación nueva", "revisar estado de bienvenida"],4 "passes": false5}
Ese "passes": false en cada entrada es el punto clave. Es una casilla sin marcar, y hay 200 de ellas.
Esa lista de fallos es lo que evita que un agente declare victoria antes de tiempo. Un turno no puede mirar alrededor y decidir que el trabajo está terminado, porque hay un archivo justo ahí con 200 casillas sin marcar. El trabajo está definido antes de que se escriba la primera línea.
Un pequeño detalle que te dice lo cuidadoso que tuvo que ser esto: usaron JSON para ese archivo, no Markdown. La razón es que el modelo es menos propenso a reescribir o eliminar silenciosamente un archivo JSON que uno en Markdown. Y las instrucciones al respecto son contundentes a propósito – es inaceptable eliminar o editar pruebas, porque eliminar una prueba es cómo una funcionalidad desaparece silenciosamente. El turno puede marcar una casilla. No puede borrar una.
La nota sobre el escritorio
Configurar el trabajo es la mitad. La otra mitad es asegurarse de que cada turno deje el lugar lo suficientemente limpio para que el siguiente pueda entrar.
Dos cosas hacen eso. El agente confirma su trabajo en Git con un mensaje real que describe lo que cambió, y escribe un archivo de progreso simple – un registro continuo de lo que se ha hecho. Ese registro junto con el historial de Git es lo que permite a un agente nuevo, comenzando desde cero, entender el estado de las cosas en unos minutos en lugar de tener que hacer ingeniería inversa durante una hora.
Git hace algo más aquí también. Cuando un turno hace un cambio malo, el siguiente puede revertir a la última versión funcional en lugar de tratar de desenredar el daño. El archivo de progreso dice dónde estamos. El historial de commits es el botón de deshacer.
Y "limpio" tiene un significado específico. Significa el tipo de código que estarías bien fusionando en una rama principal – sin errores importantes, ordenado, documentado. No "técnicamente hice progreso". El estándar es: la siguiente persona podría comenzar una nueva funcionalidad sin tener que limpiar primero tu desorden.
Cómo el siguiente turno se registra
Pon esas dos cosas en su lugar y cada turno comienza de la misma manera. Antes de tocar algo nuevo, el agente ejecuta una rutina de apertura fija para orientarse – lo mismo que hace un buen ingeniero al llegar a un proyecto que no ha visto en un tiempo.
1ejecuta pwd para ver en qué directorio estás – ese es el único lugar donde puedes editar2lee el archivo de progreso y el registro de git para ver qué pasó recientemente3lee la lista de funcionalidades y elige lo de mayor prioridad que aún no esté hecho4inicia la aplicación y ejecuta una verificación básica de que las funcionalidades principales aún funcionan5solo entonces, comienza a construir
Ese cuarto paso importa más de lo que parece. Antes de escribir una sola funcionalidad nueva, el agente inicia la aplicación y confirma que lo básico aún funciona – abre un chat, envía un mensaje, recibe una respuesta. Si el turno anterior dejó algo roto, esto lo detecta de inmediato, antes de que el nuevo turno acumule trabajo fresco sobre una base rota y lo empeore.
Este es todo el truco, y es casi aburrido lo simple que es. El turno que se va escribe lo que hizo y lo que queda. El turno que llega lee eso antes de hacer cualquier cosa. La transferencia es todo el juego.
Tus tareas largas también tienen turnos
Nada de esto es realmente sobre construir aplicaciones web. Anthropic lo probó en código porque el código es fácil de verificar, pero la forma subyacente es la forma de cada tarea larga que le das a un agente.
Cualquier cosa que no quepa en una ventana tiene turnos. Escribir un informe largo capítulo por capítulo. Ejecutar un proyecto de investigación a través de una docena de chats. Trabajar en un análisis grande durante días. Cada vez que comienzas una nueva sesión en la misma tarea, un trabajador nuevo se está registrando sin memoria del anterior – y si no dejaste una transferencia, comienza adivinando.
Entonces deja una. Antes de que termine una sesión larga, haz que el modelo escriba lo que se hizo, lo que aún está pendiente, y qué debería retomar primero la próxima sesión. Guarda esa nota en algún lugar donde la lea al entrar. Es la diferencia entre un proyecto que avanza cada sesión y uno que sigue reconstruyendo lo mismo una y otra vez.
El mismo modelo esta noche y mañana. Lo único que cambia es si la sesión de mañana entra a ciegas, o entra leyendo la nota de anoche.
Nunca se trató de lo inteligente que es el turno. Se trata de lo que deja para el que viene después.
Más análisis como este – https://t.me/+xYv1MgmIuds5YTli
