La arquitectura de un agente de IA persistente

Un modelo de lenguaje puede razonar durante una inferencia. Un agente persistente necesita continuar existiendo después de que esa inferencia termina. Esa diferencia cambia la arquitectura completa.

El diseño inicial de muchos agentes se parece a esto:

Agente simple: usuario, modelo, herramienta y respuestaUsuarioLLMToolRespuestaFigura 1. El patrón mínimo puede servir para una interacción corta, pero no representa continuidad.

Funciona mientras la tarea sea síncrona, pequeña y tolerante a fallos. El problema aparece cuando el agente debe esperar un webhook, pedir aprobación, reintentar una operación, reaccionar a un evento externo o retomar una tarea después de un reinicio.

La tesis de este artículo es simple: el modelo es una parte del sistema, no el sistema completo. Un agente persistente necesita, según el problema, responsabilidades explícitas para identidad, estado, contexto, memoria, runtime, herramientas, eventos, persistencia y observabilidad.

1. El agente no vive dentro del modelo

Una inferencia es temporal. El modelo recibe una entrada, produce tokens o una decisión estructurada y deja de ejecutarse. No conserva por sí mismo un proceso pendiente, un permiso, una operación externa en vuelo ni la obligación de continuar mañana.

La continuidad debe vivir en otra capa. Esa capa tiene que saber quién es el agente, qué tarea está activa, qué ocurrió, qué evento espera y qué condiciones deben cumplirse para continuar.

Esto conecta con dos distinciones de artículos anteriores:

• Memoria: qué información o experiencia debe persistir y poder influir en el futuro.
• Estado: qué está ocurriendo actualmente en una tarea o sesión.
• Contexto: qué necesita recibir el modelo en esta ejecución concreta.

Las tres piezas pueden relacionarse, pero no deben colapsarse. La memoria no indica que una tool ya se ejecutó. El estado no debe enviarse completo al modelo. El contexto es una vista construida para razonar, no la fuente de verdad operacional.

2. Agent Runtime

El agent runtime es la capa que coordina el ciclo de ejecución. Puede ser un proceso sencillo en una aplicación pequeña o un conjunto de servicios y workers en un sistema de producción. Su responsabilidad no es “ser inteligente”, sino controlar cómo se ejecuta la inteligencia.

Entre otras cosas, el runtime coordina:

• modelo y configuración de inferencia;
• estado de la tarea;
• construcción de contexto;
• retrieval y memoria;
• selección y ejecución de tools;
• eventos externos y timers;
• reintentos, checkpoints y recuperación;
• permisos, aprobaciones y auditoría.

Una separación conceptual útil es la siguiente:

Agent Runtime coordinando estado, memoria, herramientas, contexto y modeloAgent RuntimeStateMemoryToolsContext Builder → ModelFigura 2. El runtime coordina varias fuentes y produce una vista de contexto para una inferencia.

No es una arquitectura universal ni exige dividir todo en microservicios. En una primera versión, runtime, estado y persistencia pueden vivir en el mismo módulo. La frontera importante es semántica: saber qué responsabilidad puede cambiar sin romper las demás.

3. Identidad y estado

Identidad

Un agente persistente necesita una identidad operativa: quién es, qué instrucciones lo gobiernan, qué capacidades tiene, qué permisos posee y a qué recursos puede acceder. La identidad puede incluir tenant, usuario propietario, configuración, versión de políticas y referencias a herramientas autorizadas.

La identidad no es lo mismo que el estado de sesión. La primera responde “¿qué entidad está operando y bajo qué reglas?”. El segundo responde “¿en qué punto está esta interacción o tarea?”. Mezclarlos puede provocar que una modificación temporal de una sesión cambie accidentalmente las capacidades permanentes del agente.

Estado

El estado representa la situación actual del proceso. Puede incluir tarea activa, paso actual, resultados intermedios, tools ejecutadas, operaciones pendientes, confirmaciones, errores, retries, deadlines y eventos esperados.

{
  "taskId": "meeting-1842",
  "status": "WAITING_FOR_APPROVAL",
  "currentStep": "confirm_time",
  "pendingAction": "create_calendar_event",
  "participants": ["a@example.com", "b@example.com"],
  "toolCalls": [{"name":"find_slots","status":"SUCCEEDED"}],
  "expectedEvent": "user_confirmation"
}

Cuando la ejecución puede durar más que una request HTTP, este estado debe persistirse. El prompt puede reconstruir una parte de la conversación, pero no debería ser la base de datos del workflow, el registro de auditoría y el mecanismo de recuperación al mismo tiempo.

4. Context Builder

El Context Builder es una responsabilidad explícita: construir el contexto que el modelo necesita ahora. No consiste en concatenar todo lo disponible.

Una ejecución puede combinar:

• instrucciones del sistema y políticas;
• identidad y capacidades autorizadas;
• estado actual relevante;
• conversación reciente;
• memoria recuperada;
• resultados de tools;
• información del entorno;
• la nueva solicitud del usuario.

El builder debe aplicar presupuesto de tokens, ranking, recencia, permisos, deduplicación y resolución de conflictos. También puede decidir que cierta información permanezca fuera del modelo porque sólo le importa al runtime: una clave de idempotencia, un lock o un contador de retries, por ejemplo.

Un contexto más grande no elimina este problema. Aumenta la capacidad de transportar información, pero también puede aumentar costo, latencia, ruido y contradicciones. La pregunta útil no es “¿cómo meto todo en el prompt?”, sino “¿qué vista necesita esta decisión y con qué autoridad?”.

5. Memoria

La memoria persistente responde qué información debe seguir influyendo en futuras ejecuciones. Puede incluir episodios, conocimiento semántico, preferencias, historial de interacciones o procedimientos. Cada tipo necesita políticas diferentes de captura, actualización, retrieval, expiración y borrado.

El working context de una tarea no debe confundirse con persistent memory. Los resultados de una consulta de disponibilidad pueden ser necesarios durante la tarea, pero no convertirse automáticamente en un recuerdo permanente. Del mismo modo, una preferencia del usuario puede recuperarse para personalizar una decisión sin convertirse en parte del estado del workflow.

La recuperación también necesita políticas. Una memoria no debe insertarse completa en cada ejecución. El sistema debe considerar identidad, alcance, sensibilidad, procedencia, recencia, confianza y relevancia. “Encontrar un embedding parecido” es una señal de retrieval, no una política de memoria.

6. Ejecución de tools

Una tool en un agente persistente es más que una función que recibe argumentos y devuelve JSON. La capa de ejecución debe registrar al menos:

• nombre y versión de la tool;
• argumentos validados;
• execution ID e idempotency key;
• status, timestamps y duración;
• resultado o error;
• retries y política aplicada;
• permisos y aprobación utilizada.

Los límites importan: timeouts, aislamiento, scopes y cancelación. Una operación externa puede completar aunque el worker se caiga antes de guardar la respuesta. Por eso el retry debe ser compatible con idempotencia o con compensaciones. Persistir un checkpoint no convierte una API externa en una transacción.

7. Eventos y procesos largos

Una arquitectura persistente debe reaccionar a eventos que llegan después de la inferencia original: webhooks, timers, jobs en background, finalización de una tool, eventos de un dispositivo o una respuesta humana.

El flujo puede ser:

Agent inicia operación
        ↓
Sistema externo procesa durante cinco minutos
        ↓
Webhook firmado llega al gateway
        ↓
Runtime localiza la tarea correcta
        ↓
Valida el evento y reanuda desde el estado conocido

La pausa no es necesariamente un error. Puede ser un estado válido como WAITING_FOR_TOOL o WAITING_FOR_APPROVAL. El evento debe ser deduplicable, estar asociado a una tarea y provocar una transición explícita. Aquí aparecen patrones de sistemas orientados a eventos y de ejecución durable: no se mantiene viva una request; se persiste el proceso y se reanuda cuando existe trabajo válido.

8. Persistencia, checkpoints y recuperación

No todo debe guardarse para siempre. Potencialmente se persisten identidad, estado de workflow, memoria, historial de ejecución, resultados de tools, eventos y checkpoints. La decisión depende de retención, seguridad, costo, cumplimiento y capacidad de depuración.

Un checkpoint es una versión recuperable del proceso. Permite continuar después de un reinicio, un timeout o una falla del proveedor. Pero debe acompañarse de versionado de esquemas, control de concurrencia, idempotencia y políticas de retry. También conviene distinguir entre:

• RUNNING: existe trabajo activo;
• WAITING: el sistema espera un evento o aprobación;
• FAILED: requiere retry, compensación o intervención;
• COMPLETED: la tarea terminó y sus efectos fueron registrados.

Un sistema que guarda todo indefinidamente acumula datos obsoletos y aumenta la superficie de seguridad. Persistencia es una política de ciclo de vida, no sólo una llamada a save().

9. Observabilidad

Un log de prompts no basta para operar un agente. Necesitamos responder: ¿qué está haciendo?, ¿por qué tomó esta decisión?, ¿qué contexto recibió?, ¿qué tool ejecutó?, ¿qué modelo utilizó?, ¿cuánto tardó?, ¿cuánto costó?, ¿qué falló y desde dónde puede reanudar?

Esto requiere correlación por agent ID, task ID, execution ID y event ID. También conviene capturar versiones de políticas, modelo, herramientas y estado, con cuidado de no exponer secretos o datos sensibles. La observabilidad no es sólo para debugging: permite mostrar al usuario que una tarea está esperando una aprobación, cancelar un proceso o auditar una acción de alto impacto.

10. Human-in-the-loop

La autonomía no debe ser un objetivo absoluto. Para ciertas acciones el runtime debe detenerse:

“Voy a enviar este correo a tres personas. ¿Confirmas?”

En ese punto el estado pasa a WAITING_FOR_APPROVAL. El usuario puede responder horas después. El sistema carga la tarea, verifica que la autorización siga siendo válida, reconstituye el contexto necesario y continúa. Sin persistencia real, esto se reduce a pedirle al usuario que repita la conversación o a mantener un proceso frágil en memoria.

11. Abstracción del modelo

Un runtime puede separar el ciclo de vida del agente de un proveedor concreto mediante un router:

Agent Runtime
      ↓
  Model Router
   ↙    ↓    ↘
Model A Model B Model C

La abstracción puede seleccionar por capacidad, costo, latencia, ventana de contexto o fallback. No es una obligación universal: agregar una capa sin necesidad también crea complejidad. La decisión correcta depende de si el producto necesita portabilidad, routing dinámico o control de costos. Lo importante es que la dependencia del proveedor no se filtre accidentalmente a identidad, estado y persistencia.

12. Seguridad y permisos

Un agente con tools puede leer, escribir, enviar, comprar o modificar información. La capacidad de razonar no sustituye los controles de seguridad.

Las herramientas deben tener boundaries claros, scopes y validación de argumentos. Las acciones sensibles pueden requerir aprobación, límites de monto, allowlists y audit logs. El runtime debe comprobar tenant y ownership en cada transición relevante, no sólo al crear la sesión. La memoria también necesita control de acceso: recuperar información del tenant equivocado es un incidente de seguridad, no un problema de relevancia.

13. Una arquitectura persistente completa

Arquitectura conceptual de un agente persistenteUsuario / EnvironmentEvents / GatewayAgent RuntimeIdentity / StateMemoryToolsPoliciesContext BuilderModelActionsPersistenceObservabilityFigura 3. Una forma de separar responsabilidades en un agente persistente. Es un modelo conceptual, no una topología obligatoria.

El flujo típico sería: un usuario o evento llega al gateway; el runtime carga identidad y estado; el Context Builder recupera memoria, resultados y restricciones; el modelo propone una decisión; el runtime valida permisos y ejecuta una acción; la acción produce resultados o eventos; finalmente se actualizan estado, memoria y observabilidad.

14. Ejemplo: organizar una reunión

“Organiza una reunión con tres personas” parece una instrucción breve, pero es un proceso largo:

1. El agente identifica participantes y restricciones.
2. Consulta calendarios mediante tools.
3. Propone horarios disponibles.
4. Guarda la selección y espera confirmación.
5. Recibe una respuesta horas después.
6. Vuelve a validar disponibilidad y crea el evento.
7. Notifica a los participantes y persiste el resultado.

El estado contiene participantes, opciones, confirmación pendiente y event ID. La memoria puede aportar preferencias como zona horaria o duración habitual, pero no debe decidir por sí sola el estado de la tarea. El contexto incluye sólo las opciones y restricciones relevantes para la inferencia actual. Las tools consultan calendarios y crean el evento. La respuesta del usuario y los cambios de disponibilidad llegan como eventos. La persistencia permite continuar aunque el proceso original ya terminó.

15. Qué no debería hacer el runtime

El runtime no debería convertirse en una mega clase con toda la lógica del producto, un prompt gigante que contiene cada decisión, una colección de if/else imposible de probar o una abstracción completamente acoplada al proveedor del modelo.

También conviene evitar la arquitectura inversa: crear diez servicios antes de entender el dominio. La separación puede comenzar como módulos dentro de un mismo proceso. La complejidad debe corresponder al problema: no todo agente necesita memoria episódica, ejecución durable o múltiples modelos desde el primer día.

Mi perspectiva actual

Un agente persistente se parece menos a “un chatbot con tools” y más a un sistema distribuido cuyo componente de razonamiento es un modelo. No porque todos los agentes deban convertirse en plataformas enormes, sino porque las propiedades difíciles —continuidad, recuperación, permisos, efectos externos y espera— viven fuera de la inferencia.

El modelo puede proponer el siguiente paso. El runtime debe decidir si ese paso está permitido, cómo ejecutarlo, qué guardar, qué evento esperar y desde dónde continuar si algo falla.

La pregunta central deja de ser únicamente “¿qué prompt necesita el modelo?”. También es: ¿qué necesita conservar el sistema para continuar correctamente una tarea aunque el modelo ya no esté ejecutándose?

Responderla lleva naturalmente a identidad, estado, contexto, memoria, tools, eventos, persistencia, checkpoints y observabilidad. Esa es la diferencia entre envolver un modelo en una cadena de llamadas y diseñar un sistema de agentes capaz de operar más allá de una sola request.

Referencias

1. LangGraph Documentation, Persistence. Checkpoints, threads y recuperación de estado.
2. LangGraph Documentation, Durable execution. Reanudación, efectos secundarios e idempotencia.
3. Temporal Documentation, Long-running workflows. Workflows que esperan eventos y continúan durante largos periodos.
4. Temporal Documentation, Workflows. Modelo de ejecución durable y recuperación.
5. Charles Packer et al., MemGPT: Towards LLMs as Operating Systems, 2023.
6. Joon Sung Park et al., Generative Agents: Interactive Simulacra of Human Behavior, 2023.
7. Nelson F. Liu et al., Lost in the Middle: How Language Models Use Long Contexts, 2023.
8. Microsoft AutoGen, AgentChat User Guide. Patrones de agentes, mensajes y ejecución coordinada.