El problema del turno de noche: cómo los agentes trabajan mientras lo olvidan todo

Dale a Claude una tarea lo suficientemente grande y abandonará a la mitad, convencido de que ya terminó. El trabajo no está hecho. Simplemente no recuerda haber empezado.

Un agente no trabaja en una tarea larga como uno pensaría. Trabaja por turnos.

Imagina un proyecto de software con ingenieros que trabajan por 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 dentro de una, así que el agente trabaja en sesiones discretas — y cada nueva sesión comienza sin memoria de la anterior.

Anthropic hizo exactamente este experimento y publicó lo que se rompió. 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 falla Claude.

Por qué una sola ventana no puede terminar el trabajo

Dale a un modelo de codificación 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 no logra producir una aplicación funcional. No a veces, sino de forma fiable. Y esto es Opus ejecutándose en el propio framework de agente de Anthropic, con compactación de contexto activada, toda la configuración hecha para mantenerlo en marcha.

Falla de dos maneras específicas, y ambas son problemas de traspaso de turno.

La primera: el agente intenta hacerlo todo a la vez. Intenta resolver toda la aplicación de una sola vez en una ventana, se queda sin contexto a medio camino de una funcionalidad, y la sesión termina con algo a medio construir y sin documentar. El siguiente turno llega, ve un desastre que no hizo, y tiene que adivinar qué estaba pasando. Así que se pasa toda su sesión solo volviendo a poner en marcha la aplicación básica, en lugar de avanzar.

La segunda aparece más tarde, una vez que existen algunas funciones. 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 funciones nunca se construyeron, y nadie anotó cuáles. El turno lo dio por terminado sin revisar la lista.

Ambos fallos tienen la misma raíz. El turno saliente no dejó nada atrás, así que el turno entrante opera 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 saliente escribe

La respuesta en la que Anthropic se quedó 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. Todo su trabajo es dejar el entorno en un estado donde cada futuro turno sepa cómo se ve "terminado". La pieza clave que escribe es una lista de funcionalidades — un archivo estructurado que detalla cada cosa que la aplicación terminada necesita hacer.

Para el clon de claude.ai, eso significó más de 200 funciones. Cosas como "un usuario puede abrir un nuevo chat, escribir una consulta, presionar Enter y ver una respuesta". Cada una marcada como fallando al principio. 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", "comprobar estado de bienvenida"],
4  "passes": false
5}

Ese "passes": false en cada entrada es todo el punto. Es una casilla sin marcar, y hay 200 de ellas.

Esa lista fallida es lo que impide que un agente declare victoria antes de tiempo. Un turno no puede mirar alrededor y decidir que el trabajo está hecho, porque hay un archivo justo ahí con 200 casillas sin marcar. El trabajo se define antes de que se escriba la primera línea.

Un pequeño detalle que muestra 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 deliberadamente directas: es inaceptable eliminar o modificar pruebas, porque eliminar una prueba es cómo una función 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, empezando en frío, entender el estado de las cosas en unos minutos en lugar de tener que hacer ingeniería inversa durante una hora.

Git también hace algo más aquí. Cuando un turno hace un cambio malo, el siguiente puede revertir a la última versión funcional en lugar de tratar de desenredar el desastre. 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 en fusionar a una rama principal — sin errores graves, ordenado, documentado. No "técnicamente hice progreso". El estándar es: la siguiente persona podría empezar una nueva función sin tener que limpiar tu desorden primero.

Cómo el siguiente turno llega

Pon esas dos cosas en su lugar y cada turno empieza igual. 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 editar
2lee el archivo de progreso y el registro de git para ver qué pasó recientemente
3lee la lista de funcionalidades y elige la prioridad más alta que aún no esté hecha
4inicia la aplicación y ejecuta una comprobación básica de que las funciones principales aún funcionan
5solo entonces, empieza a construir

Ese cuarto paso importa más de lo que parece. Antes de escribir una sola función nueva, el agente arranca la aplicación y confirma que lo básico aún funciona — abre un chat, envía un mensaje, recibe una respuesta. Si el último turno dejó algo roto, esto lo detecta de inmediato, antes de que el nuevo turno amontone trabajo fresco sobre una base rota y lo empeore.

Este es todo el truco, y es casi aburrido lo simple que es. El turno saliente escribe lo que hizo y lo que queda. El turno entrante lee eso antes de hacer nada. El traspaso es el juego completo.

Tus tareas largas también tienen turnos

Nada de esto trata realmente de 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 gran análisis durante días. Cada vez que empiezas una nueva sesión en la misma tarea, un trabajador nuevo llega sin memoria del anterior — y si no dejaste un traspaso, empieza adivinando.

Así que deja uno. Antes de que termine una sesión larga, haz que el modelo escriba qué se hizo, qué queda abierto, y qué debería retomar primero la próxima sesión. Guarda esa nota en algún lugar que pueda leer 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 llega a ciegas, o llega 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