Lección 1: Más allá de la memoria está el estado

Objetivos de aprendizaje:

• Distinguir en una sola frase la «memoria» (el contexto que le das al modelo) del «estado de ejecución» (la escena en curso que sostiene el arnés), y dar un ejemplo de cada uno
• Nombrar al menos tres fundamentos concretos de por qué «una caída resulta especialmente letal para una tarea larga», y señalar a qué parte de la ejecución apunta cada uno
• Ante una lista de cosas que un arnés en ejecución hace malabares para sostener, decidir si cada una es memoria, estado de ejecución o salida en disco, y si sobrevive a que maten el proceso

Requisitos: Terminaste los cursos anteriores de esta serie y entiendes el bucle del arnés guiado por stop_reason de «Fundamentos del arnés de agente: bucles y control» y la gestión de contexto de «Ingeniería de contexto: gastar una atención finita donde más rinde» | Siguiente: Lección 2 >>

Turno 23, y matan el proceso

Imagina el arnés que escribiste en «Fundamentos del arnés de agente: bucles y control» ejecutando una tarea larga que toma 40 turnos: leer un lote de archivos, analizarlos de a uno y agregar conclusiones a un reporte sobre la marcha. En el turno 23, matan el proceso: quizá una actualización de despliegue, quizá el servidor perdió la corriente, quizá le erraste al Ctrl+C.

Revisas el disco: los archivos de reporte de los primeros 22 turnos están todos ahí; NOTES.md (ese resumen de progreso de la tarea que preparaste en «Ingeniería de contexto: gastar una atención finita donde más rinde») todavía registra «hasta qué archivo analicé y cuál fue la conclusión». Parece que no se perdió gran cosa: basta con reiniciar el proceso y retomar donde quedó.

Pero al reiniciar descubres que el arreglo messages de runAgent está vacío: hay que reconstruirlo desde [{ role: "user", content: userInput }]. El contador turns volvió a cero. tokensUsed también volvió a cero. Y si la caída se produjo en el turno 23 justo entre «el modelo nombró una herramienta» y «el resultado de la herramienta se empujó de vuelta a messages», esa llamada a herramienta —tanto si recién había empezado a ejecutarse como si ya había terminado— tampoco deja rastro alguno.

La tarea no se reanuda desde el turno 23: arranca de nuevo desde el turno 1. Los archivos en disco están todos ahí, pero el propio registro del arnés sobre «hasta dónde llegué» no dejó nada atrás.

Qué es la memoria, qué es el estado

Antes de que este curso pueda enseñar lo que vino a enseñar, tiene que trazar una línea frente a un concepto que se difumina con facilidad.

La memoria es el contexto que le das al modelo: el curso 5, «Memoria y estado del agente», cubre cómo persistirla entre sesiones, y el curso 8, «Ingeniería de contexto: gastar una atención finita donde más rinde», cubre exactamente qué le das a mirar al modelo en cada turno. Responde a la pregunta «¿qué ha visto el modelo?». NOTES.md es un vehículo para la memoria: ya está escrito en disco, y el turno siguiente o la sesión siguiente pueden leerlo de vuelta y soltarlo dentro del prompt.

El estado de ejecución es la escena en curso que sostiene el propio proceso del arnés: el arreglo messages, contadores como turns y tokensUsed, la llamada a herramienta que todavía no quedó registrada. Responde a la pregunta «¿recuerda el arnés hasta dónde llegó?».

La diferencia clave entre ambos no es «cuál es el contenido» sino «dónde vive ahora mismo». La memoria puede estar ya en disco (NOTES.md está en el sistema de archivos, y que el proceso viva o muera no cambia que siga ahí); el estado de ejecución, por omisión, vive solo en la memoria del proceso: eso que crea la línea let messages = [...] se recupera junto con la memoria en el instante en que el proceso termina, a menos que alguien lo escriba deliberadamente en disco. Nada de la sección anterior —messages, turns, tokensUsed, la llamada colgante a herramienta— se escribe en disco por su cuenta.

Este state es exactamente lo que este curso te va a enseñar a convertir en algo que se pueda escribir en disco y restaurar.

Por qué esto es decisivo para las tareas largas

Primero, hagamos las cuentas: "Agents can run for long periods of time, maintaining state across many tool calls."¹ (los agentes pueden ejecutarse durante largos periodos, manteniendo estado a lo largo de muchas llamadas a herramientas). Por eso justamente el arreglo messages del turno 23 no deja de crecer. Pero también significa que "Agents are stateful and errors compound."¹: los agentes tienen estado y los errores se componen; cuanto más estado se apila, en el momento en que algo de la cadena sale mal el costo no es lineal, se acumula.

Suma uno más: "Without effective mitigations, minor system failures can be catastrophic for agents."¹ (sin mitigaciones efectivas, fallas menores del sistema pueden ser catastróficas para los agentes). Poner «menor» y «catastrófico» uno al lado del otro describe exactamente la situación del turno 23: que maten el proceso es, por sí solo, un evento operativo corriente, pero borra de un solo golpe 22 turnos de estado de ejecución, y eso es lo que magnifica el costo.

Después de un error, "When errors occur, we can't just restart from the beginning: restarts are expensive and frustrating for users."¹ (cuando ocurren errores no podemos simplemente reiniciar desde el principio: los reinicios son costosos y frustrantes para los usuarios). Así que lo que conviene construir es un sistema en el que, "Instead, we built systems that can resume from where the agent was when the errors occurred."¹ (en cambio, construimos sistemas que pueden reanudar desde donde estaba el agente cuando ocurrieron los errores), que es la razón por la que «más allá de la memoria está el estado» no es una distinción académica sino el cimiento de si una tarea larga puede sobrevivir a una interrupción.

Cuanto más larga la tarea, más pesada esta cuenta: "The LLM will potentially operate for many turns, and you must have some level of trust in its decision-making."², y "The autonomous nature of agents means higher costs, and the potential for compounding errors."². Cuantos más turnos se ejecutan, más espeso es el estado de ejecución que acumula, y más puede borrar una sola interrupción.

Las caídas no son raras

Ese «mataron el proceso» del turno 23 suena a accidente de baja probabilidad, pero para una tarea larga que se ejecuta durante decenas de turnos, ser interrumpida a mitad de camino no tiene nada de inusual. Hasta la actualización de despliegue más rutinaria puede chocar con un agente en ejecución, que es la razón por la que los equipos deliberadamente "use rainbow deployments to avoid disrupting running agents, by gradually shifting traffic from old to new versions"¹ (usan despliegues arcoíris para no perturbar a los agentes en ejecución, desviando el tráfico gradualmente de las versiones viejas a las nuevas), y el motivo es que "whenever we deploy updates, agents might be anywhere in their process."¹ (cada vez que desplegamos actualizaciones, los agentes pueden estar en cualquier punto de su proceso).

Dicho de otro modo: hasta quienes están a cargo de la operación asumen que «el agente puede ser interrumpido en cualquier momento» es algo que va a pasar, y diseñan mecanismos específicamente para esquivarlo. Tu arnés no tiene motivo para suponer que va a tener más suerte.

La cura, en avance: la hoja de ruta de este curso

El estado de ejecución perdido en el turno 23 tiene una solución de cinco pasos, que es también el orden de las cinco lecciones siguientes:

1. Puntos de control (Lección 2): serializar periódicamente a un archivo de punto de control en disco el estado de ejecución, como messages, turns, tokensUsed y la llamada colgante a herramienta.
2. Reanudar desde un punto de control (Lección 3): después de que el proceso reinicia, leer ese estado de vuelta desde el archivo de punto de control, reconstruir messages y dejar que el bucle retome donde se rompió en vez de arrancar de nuevo desde el turno 1.
3. Efectos secundarios e idempotencia (Lección 4): lo más difícil de reanudar no es «el estado se perdió», es «algunas llamadas a herramientas quizá ya se ejecutaron de verdad»: qué herramientas se pueden volver a ejecutar sin riesgo y cuáles hay que proteger para que no se ejecuten dos veces.
4. Rebobinar y bifurcar (Lección 5): los puntos de control no sirven solo para recuperarse de desastres; también te permiten rebobinar a una escena anterior y reintentar, o bifurcar otro intento desde algún nodo.
5. Manos a la obra (Lección 6): tomar la maquinaria de las lecciones anteriores, encajarla en el arnés de «Fundamentos del arnés de agente: bucles y control» y llevar tú mismo una tarea larga por el recorrido «matada a mitad, reinicio, ejecución hasta el final».

Una hoja de ruta comunitaria de código abierto construida alrededor de la «ingeniería del arnés» lo resume en una línea: "Checkpoint state every node so you can resume, rewind, fork."³ (guardar el estado en un punto de control en cada nodo para poder reanudar, rebobinar y bifurcar). Es apenas una nota de encuadre de un documento comunitario sobre de qué se hace cargo el componente de persistencia, no una especificación que este curso copie al pie de la letra, pero el orden que señala coincide con los cinco pasos de arriba.

Proporción: no toda tarea necesita esto

No todo agente tiene que cargar con la maquinaria de puntos de control. Sobre agregar complejidad, "you should consider adding complexity only when it demonstrably improves outcomes."² (habría que considerar agregar complejidad solo cuando mejora los resultados de forma demostrable): una tarea que se resuelve en unos pocos turnos de llamadas a herramientas tiene apenas un puñado de entradas en messages, y si el proceso muere basta con volver a ejecutarla; el costo es preguntar una vez más, y no amerita diseñar todo un mecanismo de guardado y restauración.

Lo que sí necesita la maquinaria de este curso es un escenario como el del turno 23 del comienzo: una tarea que se ejecuta durante decenas de turnos, puede tomar de minutos a horas y acumula por el camino una pila grande de estado de ejecución sin persistir. Para decidir si traer puntos de control, hazte primero una pregunta: si la mataran ahora mismo, ¿podrías vivir con el costo de volver a ejecutarla? Si no puedes, ahí es donde entran las próximas lecciones.

Resumen

• Los agentes pueden ejecutarse durante largos periodos, manteniendo estado a lo largo de muchas llamadas a herramientas, y precisamente por eso tienen estado y los errores se componen¹: cuanto más estado se apila, más puede borrar una sola falla.
• Sin mitigaciones efectivas, una falla menor del sistema puede ser catastrófica para un agente¹; tras un error no puedes reiniciar desde el principio, porque los reinicios son costosos y frustrantes para los usuarios, así que se construyen sistemas que reanudan desde donde ocurrió el error¹.
• Las caídas no son raras: hasta una actualización de despliegue rutinaria exige despliegues arcoíris justamente para no perturbar a los agentes en ejecución, porque al momento de desplegar un agente puede estar en cualquier punto de su proceso¹.
• La operación autónoma acarrea de por sí costos más altos y el riesgo de errores que se componen²; cuanto más larga la tarea, más pesada esta cuenta, y más necesita un mecanismo que sobreviva a la interrupción.
• No toda tarea tiene que cargar con esta maquinaria: habría que agregar complejidad solo cuando mejora los resultados de forma demostrable², y para una tarea que se resuelve en unos pocos turnos el costo de simplemente volver a ejecutarla suele ser aceptable.
• La memoria (el contexto que se le da al modelo) y el estado de ejecución (la escena en curso que sostiene el arnés) son dos cosas distintas: la memoria puede estar ya persistida, el estado de ejecución vive por omisión solo en la memoria del proceso, y las próximas lecciones tratan de convertir también ese estado de ejecución en algo que se pueda escribir en disco y restaurar.

>> Lección 2: Puntos de control: escribir la escena de ejecución en disco