Habr AI Explicó Cómo Construir un Agente de Producción con Durable State, Pasos y Eventos

Para que los agentes de IA funcionen correctamente en producción, no es suficiente mantener todo en la memoria del proceso: después de un reinicio, el agente debe recordar exactamente qué pidió el usuario, qué plan ya fue construido, qué herramientas se han ejecutado y dónde se detuvo la ejecución. En la primera parte de un nuevo análisis práctico en Habr AI, el autor propone construir ese estado persistente en torno a tres entidades básicas — turno, paso y evento — y explica por qué, sin ellas, los escenarios largos de agentes se transforman rápidamente en un pipeline opaco y frágil. El punto de partida es simple: si un agente almacena estado solo en memoria, cualquier fallo de servicio anula la tarea.

Para una demostración esto es tolerable, pero un agente de producción puede analizar documentos, esperar confirmación del usuario y ejecutar una larga cadeia de acciones, por lo que después de un fallo necesita recuperarse de una base de datos, no de fragmentos de un prompt. Como conjunto mínimo de entidades persistentes, el autor enumera AgentTurn, AgentPlanItem y AgentEvent, y también señala que ApprovalGrant, SessionContext y BackgroundJob aparecen casi inevitablemente cerca. La idea es que el estado persistente describe no solo la respuesta final, sino todo el camino hacia ella: la solicitud original, el comando normalizado, banderas de confirmación, estados de ejecución y posibles errores.

AgentTurn en este esquema es un registro completo de un turno del usuario. Almacena un identificador de sesión y turn_id, texto del mensaje, comando normalizado y estado de procesamiento como created, planned, awaiting_approval, running, completed o failed. Es importante que el turno capture tanto el output_text final como el error, en caso de que la ejecución haya fallado.

Esto elimina la dependencia crítica de la "memoria" del modelo: el backend puede determinar en cualquier momento qué exactamente estaba sucediendo con la solicitud, incluso si el proceso fue reiniciado. Para tareas largas esto es especialmente importante porque una solicitud única rara vez se reduce a una única llamada del modelo — más bien implica una cadena de lecturas de archivos, invocaciones de herramientas, verificación y preparación de resultados. La siguiente capa es AgentPlanItem, es decir, un paso individual dentro de un turno.

Si un usuario solicita analizar un proyecto y preparar un informe, el agente puede descomponer la tarea en varias acciones: encontrar documentos, leer archivos relevantes, verificar datos y ensamblar la respuesta final. Para cada paso se propone almacenar su propio item_id, número ordinal, nombre de la herramienta, argumentos, modo de confirmación y estado. El artículo enfatiza particularmente que los modos safe_readonly, confirm_once y mutating son necesarios no por decoración: permiten pre-dividir operaciones de lectura seguras, acciones de confirmación única y mutaciones potencialmente peligrosas.

Como resultado, el sistema sabe no solo "el agente está haciendo algo," sino qué herramienta exacta debe iniciarse a continuación, qué ya se ha completado, qué se puede reintentar y dónde la ejecución se quedó atascada. La tercera entidad obligatoria es AgentEvent, es decir, una línea de tiempo de lo que está sucediendo. Son precisamente los eventos los que transforman un turno de una caja negra en un sistema observable.

En lugar de un único estado vago, la interfaz puede leer turn_started, tool_started, tool_progress, tool_completed, approval_requested, tool_failed y turn_completed, y luego mostrar progreso claro. El ejemplo del texto es fundamentado y, por lo tanto, útil: el agente ejecuta collect_documents, encuentra 12 documentos, luego en el paso analyze_documents reporta progreso 40 de 100, y en caso de fallo escribe timeout de servicio externo y marca el error como retryable. Para el usuario esto significa UX normal en lugar de infinito "el agente está pensando," y para el equipo de desarrollo — la capacidad de depurar el pipeline, realizar auditorías, analizar incidentes y recuperar tareas después del reinicio sin reconstrucción manual del historial.

La conclusión principal del material de Habr AI es que un agente de producción en 2026 no es un prompt afortunado con un wrapper, sino un sistema stateful con un registro de ejecución. Si un agente no tiene estado persistente a nivel de turno, paso y evento, sobrevive mal a fallos, es opaco para la interfaz y es casi imposible de mantener. Lo que significa que la siguiente etapa de evolución de aplicaciones de agentes reside menos en nuevos modelos que en disciplina de arquitectura backend: en cómo capturamos estado, controlamos aprobaciones y transformamos el trabajo del modelo en un proceso operacional reproducible.