Los agentes de IA necesitan estado

Un modelo puede razonar sobre el contexto actual, pero un sistema necesita estado para mantener continuidad a través del tiempo. Esa diferencia parece pequeña cuando un agente se implementa como una cadena de prompt, modelo, herramienta y respuesta. Se vuelve fundamental cuando el sistema debe ejecutar varios pasos, esperar un webhook, pedir confirmación, recuperarse de un error o continuar una tarea después de que la ejecución original terminó.

El problema no es que el modelo no pueda recibir más texto. El problema es que un prompt no debería ser la base de datos, el coordinador de procesos y el registro de auditoría de un sistema distribuido.

En el artículo anterior, RAG no es memoria, distinguí entre recuperar información y construir memoria persistente. Aquí aparece una tercera pieza: el estado. Para construir agentes que duren más que una sola inferencia, conviene separar tres conceptos:

• Contexto: la información que se presenta al modelo para una inferencia.
• Memoria: la información persistente que puede influir en ejecuciones futuras.
• Estado: la representación actual del sistema y del proceso que está ocurriendo.

El problema de la cadena prompt → modelo → tool

Muchos agentes comienzan así:

Usuario → LLM → Tool → Respuesta

Esta forma funciona para una pregunta aislada o una herramienta determinista. Los problemas aparecen cuando la tarea deja de ser una sola llamada: hay múltiples pasos, reintentos, herramientas asíncronas, confirmaciones humanas, errores, interrupciones o sesiones persistentes.

El modelo puede sugerir el siguiente paso, pero el runtime necesita saber en qué paso está, qué ya ocurrió y qué condiciones deben cumplirse antes de continuar.

Qué significa estado en un sistema de agentes

En software engineering, el estado es la representación de las condiciones actuales de un sistema. Para un agente, puede incluir mucho más que el historial conversacional:

• la tarea activa y su objetivo;
• el paso actual del workflow;
• herramientas ejecutándose o pendientes;
• argumentos, resultados y errores de herramientas;
• recursos seleccionados y su ownership;
• permisos y aprobaciones requeridas;
• eventos recibidos y eventos todavía esperados;
• reintentos, deadlines e idempotency keys;
• el estado de la sesión y del proceso de negocio.

Una estructura mínima podría verse así:

{
  "taskId": "reservation-1842",
  "status": "waiting_for_user",
  "currentStep": "confirm_selection",
  "selectedResource": "restaurant-27",
  "pendingAction": "create_reservation",
  "toolCalls": [{ "name": "check_availability", "status": "succeeded" }],
  "expectedEvent": "user_confirmation"
}

No existe un esquema universal. La decisión importante es que estos datos tengan una representación explícita, una semántica definida y un ciclo de vida independiente del prompt.

Contexto no es estado

El contexto es lo que el modelo puede usar ahora: instrucciones, conversación reciente, resultados de herramientas, memoria recuperada, permisos y datos del entorno. Es una vista construida para una inferencia concreta.

El estado es la fuente de verdad operacional. Puede usarse para construir contexto, pero no todo el estado debe enviarse al modelo. Un contador de retries, una idempotency key o un lock de concurrencia pueden ser esenciales para el runtime y completamente irrelevantes para el razonamiento.

Un prompt puede reconstruir parte del estado, pero hacerlo introduce problemas de tamaño, consistencia, concurrencia, recuperación, reproducibilidad y seguridad. Un resumen puede omitir el evento que explica una transición. Dos ejecuciones pueden reconstruir versiones distintas. Un historial mezclado puede filtrar datos entre sesiones o tenants.

El context builder debe seleccionar una vista útil del estado. No debe reemplazar al sistema que lo conserva.

Memoria tampoco es estado

La memoria responde a una pregunta histórica: ¿qué información o experiencia debe seguir influyendo en el futuro? El estado responde a una pregunta operacional: ¿qué está pasando ahora y qué debe ocurrir después?

Concepto	Pregunta	Ejemplo
Contexto	¿Qué necesita saber el modelo en esta inferencia?	Disponibilidad devuelta por una API.
Memoria	¿Qué conocimiento debe permanecer disponible?	El usuario prefiere restaurantes vegetarianos.
Estado	¿En qué punto está el proceso?	La reserva espera confirmación.

La memoria puede utilizar retrieval semántico, consultas estructuradas o eventos. El estado puede contener referencias a memorias relevantes. Pero recuperar una preferencia histórica no indica que una tool ya se haya ejecutado, ni que una operación esté autorizada.

Un agente como sistema con estado

Una arquitectura conceptual puede expresarse así:

User / Environment
        ↓
   Agent Runtime
        ↓
   Explicit State
    ↙     ↓      ↘
Context  Memory  Tools
Builder  /Retrieval  /Events
        
     State Update

El runtime coordina la ejecución. El estado representa la tarea. El context builder produce la vista para el modelo. La memoria conserva conocimiento o experiencia con políticas propias. Las herramientas producen efectos y eventos que deben actualizar el estado.

Es una separación conceptual, no una receta para dividir servicios desde el primer día. En una aplicación pequeña, varias piezas pueden vivir en el mismo proceso y en la misma base de datos. Lo importante es no confundir sus responsabilidades.

El estado alrededor de las herramientas

Una tool no es únicamente una función que devuelve JSON. En producción, el sistema necesita registrar qué herramienta se invocó, con qué argumentos, cuándo comenzó y terminó, si el resultado fue exitoso, qué error ocurrió, cuántos retries se hicieron, si la operación es idempotente y qué parte de la tarea dependía de ella.

Esto importa especialmente cuando la herramienta tiene efectos externos. Si el proceso se cae después de crear una reserva pero antes de guardar la respuesta, un retry ingenuo puede crear una segunda reserva. El estado y las claves de idempotencia permiten distinguir entre “no se ejecutó”, “se ejecutó y falló”, “se ejecutó pero no confirmamos el resultado” y “ya está completada”.

Los checkpoints guardan una versión recuperable del proceso. Pero un checkpoint no elimina la necesidad de diseñar transiciones, efectos idempotentes y políticas de compensación. Persistir un snapshot no vuelve transaccional a una API externa.

Procesos largos y eventos externos

Imagina que un agente inicia una verificación de identidad. El proveedor responde mediante un webhook diez minutos después. El modelo original ya no está ejecutándose. Cuando llega el evento, el sistema necesita encontrar la ejecución correcta, validar la firma, cargar su estado y decidir si puede continuar.

Debe saber qué proceso estaba activo, qué usuario y recursos le pertenecen, qué evento esperaba, si el webhook ya fue procesado, qué transición es válida y qué debe hacer después.

Una ejecución durable trata la pausa como un estado válido, no como una excepción:

RUNNING
   ↓
WAITING_FOR_TOOL
   ↓
WAITING_FOR_USER
   ↓
RUNNING
   ↓
COMPLETED

La forma exacta puede variar. Lo importante es que los estados sean reanudables y que las transiciones sean explícitas.

Estado efímero, de sesión y persistente

No todo debe conservarse para siempre:

• Runtime state: datos temporales de una ejecución, como un buffer o un lock.
• Session state: información necesaria mientras una sesión sigue activa.
• Workflow state: pasos, dependencias, retries y eventos de una tarea que puede pausarse.
• Persistent state: información que debe sobrevivir reinicios y nuevas sesiones.

La retención debe responder a requisitos del producto, seguridad, costo y cumplimiento. Guardar todo indefinidamente aumenta la superficie de riesgo y dificulta corregir información obsoleta. El estado también necesita ownership, versionado, expiración y políticas de acceso.

Por qué las state machines siguen siendo útiles

Usar un LLM no elimina la utilidad de las máquinas de estados. Una state machine permite declarar transiciones válidas e invariantes: no se puede confirmar una reserva sin disponibilidad, ni ejecutar una operación sensible sin autorización.

El modelo puede ayudar a interpretar una solicitud o elegir entre acciones permitidas. El runtime debería conservar el control sobre las transiciones críticas. Esto facilita debugging, recuperación, pruebas y auditoría.

No significa que todo agente deba modelarse como una máquina rígida. Algunas tareas son exploratorias y tienen decisiones difíciles de enumerar. Aun así, suele ser valioso hacer explícitos los límites: qué estados existen, qué eventos los cambian y qué efectos están permitidos en cada uno.

El ejemplo de la reserva

“Reserva una mesa mañana a las 8” parece una sola instrucción, pero contiene un proceso: buscar restaurantes, presentar opciones, registrar la selección, comprobar disponibilidad, esperar confirmación, crear la reserva y guardar el resultado.

Capa	Ejemplo
Contexto	Opciones disponibles, fecha, hora y resultado de la última consulta.
Memoria	Preferencia por restaurantes vegetarianos o una restricción alimentaria persistente.
Estado	Restaurante elegido, disponibilidad verificada, confirmación pendiente y reservation ID.

Si el usuario se desconecta después de elegir un restaurante y confirma horas más tarde, el sistema no debería pedirle que reconstruya toda la conversación. Debe cargar el estado de la tarea, validar que la disponibilidad siga siendo válida y continuar desde una transición conocida.

Observabilidad y producto

El estado explícito permite responder preguntas que un log de prompts no responde bien: ¿qué está haciendo el agente?, ¿por qué está esperando?, ¿qué herramienta falló?, ¿qué decisión tomó y con qué evidencia?, ¿desde dónde debe continuar?

Esto afecta la confiabilidad, pero también la experiencia de usuario. Un producto puede mostrar “esperando confirmación”, “verificando disponibilidad” o “reintentando una integración” en lugar de parecer congelado. Puede permitir cancelar una tarea, corregir una decisión o retomar una ejecución.

También afecta seguridad y auditoría: quién autorizó una acción, qué versión del estado se usó y qué efectos externos se produjeron. Un agente persistente necesita ser observable como sistema, no solamente evaluado por la calidad de su respuesta final.

Conclusión

Los modelos proporcionan capacidad de razonamiento. La memoria proporciona continuidad de conocimiento. El estado proporciona continuidad operacional.

Un agente puede funcionar sin estado explícito mientras la tarea sea corta, síncrona y tolerante a errores. Cuando necesita vivir durante múltiples turnos, coordinar herramientas, esperar eventos o recuperarse de interrupciones, el estado deja de ser un detalle de implementación y se convierte en una pieza arquitectónica.

La pregunta correcta ya no es únicamente “¿qué prompt necesita el modelo?”. También es: ¿qué necesita recordar el sistema para continuar correctamente una tarea aunque el modelo no tenga toda la historia dentro del prompt?

Responderla obliga a diseñar estados, eventos, transiciones, persistencia, permisos, reintentos y recuperación. Esa es la diferencia entre envolver un modelo en una cadena de llamadas y construir un sistema de agentes capaz de operar en el mundo real. Es también un problema central al diseñar sistemas persistentes como Nexa: la continuidad no puede depender de que una sola ejecución siga viva.

Referencias

1. LangChain, Persistence — LangGraph Documentation. Checkpoints, threads y recuperación del estado.
2. LangChain, Durable execution — LangGraph Documentation. Reanudación, efectos secundarios e idempotencia.
3. Temporal, Long-running workflows. Workflows pausables y reanudables alrededor de eventos externos.
4. Martin Fowler, Event Sourcing, 2005. Eventos como fuente para reconstruir el estado de una aplicación.
5. Joon Sung Park et al., Generative Agents: Interactive Simulacra of Human Behavior, 2023. Memoria, reflexión y planificación en agentes.
6. Charles Packer et al., MemGPT: Towards LLMs as Operating Systems, 2023. Gestión jerárquica de memoria alrededor de una ventana limitada.
7. Nelson F. Liu et al., Lost in the Middle: How Language Models Use Long Contexts, 2023. Límites prácticos del uso de contextos largos.