Habr AI explica cómo construir un agente de producción con estado durable, pasos y eventos

Para que un agente de IA viva con normalidad en producción, no basta con mantenerlo todo en la memoria del proceso: tras un reinicio debe recordar qué pidió exactamente el usuario, qué plan se había construido, qué herramientas ya se ejecutaron 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 durable en torno a tres entidades básicas (un turno, un paso y un evento) y muestra por qué, sin ellas, los escenarios largos de agentes se convierten rápidamente en un pipeline opaco y frágil.

El punto de partida es sencillo: si el agente guarda su estado solo en memoria, cualquier caída del servicio borra la tarea. Para una demo es tolerable, pero un agente en producción puede analizar documentos, esperar la confirmación del usuario y ejecutar una larga cadena de acciones, así que tras un fallo necesita recuperarse desde la base de datos y no desde retazos de un prompt. Como conjunto mínimo de entidades persistentes, el autor enumera AgentTurn, AgentPlanItem y AgentEvent, y recuerda que casi inevitablemente aparecen también ApprovalGrant, SessionContext y BackgroundJob.

La idea es que el estado durable describe no solo la respuesta final, sino todo el camino hasta ella: la solicitud original, el comando normalizado, los indicadores de confirmación, los estados de ejecución y el posible error.

En este esquema, AgentTurn es el registro completo de un turno del usuario. Almacena el identificador de sesión y el turn_id, el texto del mensaje, el comando normalizado y un estado de procesamiento como created, planned, awaiting_approval, running, completed o failed. Es importante que el turno registre también el output_text final y el error si la ejecución falló.

Así se elimina una dependencia crítica de la «memoria» del modelo: el backend puede saber en cualquier momento qué ocurrió con la solicitud, incluso si el proceso se reinició. En tareas largas esto es especialmente importante, porque una solicitud rara vez se reduce a una sola llamada al modelo; lo habitual es que detrás haya una cadena de lectura de archivos, llamadas a herramientas, verificación y preparación del resultado.

La siguiente capa es AgentPlanItem, es decir, un paso individual dentro del turno. Si el usuario pide analizar un proyecto y preparar un informe, el agente puede dividir la tarea en varias acciones: buscar documentos, leer los archivos relevantes, comprobar los datos y componer la respuesta final. Para cada paso se propone guardar su propio item_id, número de orden, nombre de la herramienta, argumentos, modo de confirmación y estado.

El artículo subraya que los modos safe_readonly, confirm_once y mutating no están de adorno: permiten separar de antemano las operaciones de lectura seguras, las acciones que se confirman una sola vez y las mutaciones potencialmente peligrosas. Así, el sistema sabe no solo que «el agente está haciendo algo», sino qué herramienta debe arrancar a continuación, qué ya terminó, qué se puede reintentar y en qué punto se atascó la ejecución.

La tercera entidad obligatoria es AgentEvent, una línea temporal de lo que ocurre. Los eventos convierten el turno de una caja negra en un sistema observable. En lugar de un único estado difuso, el frontend puede leer turn_started, tool_started, tool_progress, tool_completed, approval_requested, tool_failed y turn_completed, y mostrar un progreso comprensible.

El ejemplo del texto es prosaico y por eso útil: el agente lanza collect_documents y encuentra 12 documentos; después, en el paso analyze_documents, informa de un progreso de 40 sobre 100 y, en caso de fallo, registra un timeout del servicio externo y marca el error como retryable. Para el usuario esto significa una UX decente en lugar de un eterno «el agente está pensando»; para el equipo de desarrollo, la posibilidad de depurar el pipeline, auditar, analizar incidentes y recuperar tareas tras un reinicio sin reconstruir el historial a mano.

La conclusión principal del material de Habr AI es que un agente de producción en 2026 no es un buen prompt con algo de cableado alrededor, sino un sistema con estado y un registro de ejecución. Si el agente no tiene estado durable a nivel de turno, paso y evento, sobrevive mal a los fallos, es opaco para la interfaz y casi imposible de mantener. Por tanto, la siguiente etapa en la evolución de las aplicaciones de agentes está menos en los nuevos modelos que en la disciplina de la arquitectura backend: en cómo registramos el estado, controlamos las confirmaciones y convertimos el trabajo del modelo en un proceso operativo reproducible.