Estado del Agente: Deadpool y el Arte de Recordar (y Recuperarse de Todo)
Cómo diseñar el estado de un agente para que sea persistente, inspeccionable y recuperable — con el Mercenario Bocazas como guía.
El único superhéroe que sabe en qué película está
Deadpool es el único personaje del universo Marvel que rompe la cuarta pared. Sabe que es un personaje de cómic. Sabe que hay un lector. Sabe que en la película anterior le pasó tal cosa. Y más importante: lo recuerda.
Eso es exactamente lo que separa a un agente bien diseñado de uno que falla a los 3 turnos: la memoria. El estado. La capacidad de saber en qué punto del proceso estás, qué pasó antes, y qué hacer si algo salió mal.
"Oye, tú. Sí, vos. El que está leyendo esto. ¿Sabés qué es el estado de un agente? No? Perfecto. Yo tampoco lo sabía hasta que me di cuenta de que mi cerebro regenerativo ES un checkpoint automático." — Deadpool, probablemente
En el capitulo anterior vimos cómo parar un agente y mantenerlo seguro. Ahora vamos un paso más allá: ¿qué pasa dentro del agente entre iteración e iteración? ¿Cómo sabe qué hizo antes? ¿Cómo sigue si algo falla? Eso es el estado del agente.
¿Qué es el estado de un agente?
El estado es todo lo que el agente necesita recordar para continuar haciendo su trabajo. No es solo el historial de mensajes con Claude — es mucho más amplio.
Pensalo como el cerebro de Deadpool después de que Weapon X le implantó el factor de curación. Tiene memoria de lo que pasó (historial), sabe en qué misión está (contexto activo), lleva la cuenta de cuántas veces casi murió (errores acumulados), y tiene un punto de recuperación si algo va muy mal (checkpoint).
Estado efímero vs estado persistente
Acá hay un punto clave que el examen te va a preguntar: no todo el estado es igual. Hay dos tipos principales.
Estado efímero — el Deadpool sin el factor de curación
El estado efímero vive en memoria RAM mientras el programa corre. Cuando el proceso termina, se va. Es rápido, es simple, pero es frágil. Si el agente crashea o reinicia, perdiste todo.
Estado persistente — el factor de curación activado
El estado persistente se guarda en disco, base de datos, o almacenamiento externo. El agente puede reiniciarse, crashear, pasar por un servidor diferente — y retomar exactamente donde lo dejó.
💡 EXAMEN: La diferencia entre estado efímero y persistente no es solo técnica — es una decisión de diseño. Para tareas críticas, largas, o que involucren datos del usuario, siempre usá estado persistente.
AgentState: el traje de Deadpool en Python
El patrón más limpio para manejar estado es encapsularlo en una dataclass. Así como el traje de Deadpool concentra todo lo que necesita (armas, bolsillos con chimichanga, radio de Cable), el AgentState concentra todo lo que el agente necesita.
El AgentState es el 'traje' del agente. Todo lo importante va adentro. Nunca uses variables sueltas flotando en el scope global — eso es como Deadpool guardando sus katanas debajo de la cama de un hospital.
Mantener contexto entre iteraciones
Cada vez que el agente llama a Claude, le tiene que pasar el historial completo de la conversación. Claude no tiene memoria entre llamadas — cada llamada es una instancia nueva desde cero. El agente es quien carga con el historial.
Esto es como Deadpool llevando su diario personal a cada misión. Cable tiene el dispositivo del tiempo, pero Deadpool es quien recuerda el contexto emocional. Si no lo trae, cada misión empieza de cero.
⚠️ Si le pasás solo el último mensaje a Claude (en vez del historial completo), el agente pierde todo el contexto previo. Va a tomar decisiones como si empezara de cero. Es como que Deadpool olvide que ya negoció el precio del contrato — y lo negocie de vuelta.
Estado inspeccionable: romper la cuarta pared del agente
Deadpool puede hablarle directamente al lector porque puede inspeccionar su propia realidad. Tu agente también tiene que poder inspeccionar su propio estado en cualquier momento.
Un estado inspeccionable es uno que podés serializar (convertir a JSON), logear, debuggear, y mostrar en un dashboard de monitoreo. Si algo sale mal y no podés ver el estado interno del agente, estás en el horno.
💡 EXAMEN: Estado inspeccionable = serializable + loggeable + que cualquier parte del sistema pueda leer sin side effects. No es solo 'que funcione' — es que otro sistema pueda monitorear el agente desde afuera.
El healing factor: checkpoints y recuperabilidad
La mayor superpotencia de Deadpool no son las katanas ni los chistes malos. Es que no puede morir permanentemente. Se regenera. Vuelve.
Tus agentes también tienen que poder recuperarse. Y eso se logra con checkpoints: instantáneas del estado en un momento conocido y válido. Si algo se corrompe, el agente puede rollback al último checkpoint y seguir desde ahí.
Cuando el estado se corrompe: el cerebro dañado de Deadpool
El cerebro de Deadpool está literalmente dañado por el factor de curación que pelea constantemente con el cáncer. Tiene lagunas, inconsistencias, momentos de confusión. Pero sigue funcionando porque hay mecanismos de compensación.
El estado de tu agente también se puede corromper: datos faltantes, tipos incorrectos, historial truncado, variables de contexto en estado inválido. Tenés que detectarlo y manejarlo.
⚠️ Un estado con mensajes en el orden incorrecto (por ejemplo, dos 'assistant' consecutivos) va a hacer que Claude falle con un error de validación. La API de Anthropic requiere que los mensajes alternen estrictamente entre 'user' y 'assistant'.
Demo completo: el agente multi-turno de Deadpool
Juntemos todo en un agente funcional que mantiene estado entre iteraciones, hace checkpoints, y puede recuperarse de errores.
Corrés este código y vas a ver exactamente cómo el historial crece iteración a iteración. Cada llamada a Claude tiene más contexto que la anterior. Eso es el estado multi-turno en acción.
Las 4 trampas del examen sobre estado del agente
Trampa 1: 'El historial de mensajes es el único estado que necesita un agente'
FALSO. El historial de mensajes es solo uno de los componentes del estado. Un agente también necesita variables de contexto, resultados parciales, contadores de iteraciones, y metadatos de control. Reducir el estado al historial es un error de diseño — y una trampa clásica del examen.
Trampa 2: 'Estado efímero es siempre suficiente para agentes cortos'
DEPENDE del contexto. Si el agente puede interrumpirse (por timeout, error de red, crash del proceso), incluso una tarea 'corta' puede perder estado. Para tareas que involucren operaciones externas o datos del usuario, la persistencia es recomendada independientemente de la duración esperada.
Trampa 3: 'El agente puede modificar el historial para corregir errores'
NO. El historial de mensajes es inmutable. No borrés ni editás mensajes previos para 'limpiar' el estado. Eso puede crear inconsistencias imposibles de debuggear. Si necesitás corregir un error, agregá un nuevo mensaje que lo aclare — no modifiques el historial existente.
Trampa 4: 'Los checkpoints garantizan que el agente siempre puede recuperarse'
Solo si los checkpoints son frecuentes y el estado guardado es válido. Un checkpoint guardado con estado corrupto es inútil. Siempre validá el estado ANTES de guardarlo en el checkpoint — igual que Deadpool revisa que tenga suficientes balas antes de guardar la mochila.
Lo que te llevás de M1V5
El estado del agente es su memoria de trabajo — todo lo que necesita recordar para completar una tarea multi-turno. Un buen diseño de estado tiene tres propiedades: es persistente (sobrevive reinicios), es inspeccionable (podés ver qué sabe el agente en cualquier momento), y es recuperable (podés volver a un punto válido si algo sale mal).
Deadpool puede trabajar en múltiples misiones, recordar contratos previos, y regenerarse de casi cualquier daño porque tiene un estado bien diseñado — aunque sea implícito. Tus agentes necesitan el mismo nivel de robustez, pero explícito y en código.
AgentState + checkpoints frecuentes + validación antes de guardar = el healing factor de tu agente.
En M1V6 cerramos el Dominio 1 con el tema que une todo lo anterior: comunicación entre agentes en sistemas multi-agente. Cómo se pasan mensajes entre orchestrators y sub-agentes, qué formato usan, y qué puede salir mal cuando dos agentes hablan al mismo tiempo.
Código del video.