La conexión puede morir; el agente no
El stream es una vista del trabajo, no el trabajo. Puede cerrarse y reabrirse; la identidad, el estado y la responsabilidad del run deben sobrevivir.
El incidente como síntoma
El diseño nació de un fallo en el que coincidieron tres factores: una ejecución seguía vinculada a la petición que la había iniciado, un flujo aplicaba presupuestos demasiado bajos para el trabajo real y dos componentes competían por el mismo recurso de persistencia.
El síntoma visible era un agente que parecía detenerse. La causa no era única: la infraestructura había tratado como equivalentes el final de una conexión, el agotamiento de un presupuesto y la ausencia temporal de progreso.
La corrección inmediata podía resolver aquella ejecución. El aprendizaje arquitectónico era más amplio: un sistema agéntico necesita representar la espera y la incertidumbre, no solo aumentar timeouts.
Esta edición no publica la traza ni las coordenadas operativas del incidente y, por tanto, no presenta esa atribución causal como un análisis reproducible por terceros. La utiliza únicamente como punto de partida para separar los tres relojes siguientes.
Tres relojes distintos
Conviene separar tres escalas:
- Transporte. Cuánto puede permanecer abierta una conexión concreta.
- Actividad. Cuánto tiempo puede pasar sin una señal de vida de la operación en curso.
- Misión. Cuánto trabajo, coste o tiempo admite la tarea completa.
Un timeout de transporte protege conexiones. Un lease de actividad detecta operaciones que quizá se han quedado atascadas. Un presupuesto de misión limita recursos y fuerza una revisión de rumbo. Aplicar un único contador a los tres problemas produce falsos positivos o ejecuciones sin control.
Extracto. El tiempo no debería dictar por sí solo que una misión ha fracasado. Debe aportar una señal para revisar si sigue viva, si necesita intervención o si debe concluir con el mejor resultado disponible.
El run como entidad duradera
El run debe adquirir una identidad antes de empezar a trabajar. El cliente recibe esa identidad y puede:
- consultar un snapshot de estado;
- observar eventos nuevos;
- reanudar la observación desde el último evento conocido;
- aportar información cuando se solicite;
- pedir cancelación;
- recuperar el resultado terminal.
Este patrón aparece en sistemas contemporáneos de agentes y workflows. A2A modela tareas con estados, actualizaciones y artefactos. OpenAI ofrece un modo de ejecución en segundo plano que desacopla la respuesta de la conexión original. LangGraph documenta persistencia e interrupciones apoyadas en checkpoints.
ALLAN adopta esas referencias como patrones compatibles, no como contratos idénticos. Por ejemplo, un cursor SSE basado en identificadores de evento es una decisión propia aunque persiga la misma propiedad de reanudación.
El log de eventos y sus límites
Una vista reanudable necesita una secuencia ordenada de eventos. El cliente recuerda el último identificador recibido y solicita los posteriores. Si el evento más antiguo disponible ya ha caducado, el servidor debe declarar el gap y entregar un snapshot nuevo; fingir continuidad produciría una historia incompleta.
La durabilidad del run y la del stream no son necesariamente iguales. Un log en memoria, incluso replicado de forma oportunista, no constituye por sí solo una fuente de verdad tras un reinicio. La publicación debe distinguir:
- reanudación de conexión dentro de la vida del proceso;
- replay persistente de eventos;
- recuperación del estado de ejecución después de un crash;
- reanudación segura de una operación con efectos externos.
La última propiedad depende de idempotencia o de mecanismos explícitos de reconciliación. Un checkpoint no puede deshacer un correo enviado ni una transacción externa ya confirmada.
Esperas como estado de primera clase
Una llamada a herramienta puede estar:
- ejecutándose con progreso observable;
- esperando a un proveedor externo;
- esperando a una persona;
- suspendida hasta una fecha o un evento;
- bloqueada sin señales de vida;
- terminada con éxito o error.
Reducir todas esas situaciones a «running» obliga al operador a inferir el estado a partir del silencio. El estado de espera debe registrar al menos el tipo de espera, el objeto esperado, la última señal de actividad, el lease vigente y el número de renovaciones.
Los leases, introducidos en sistemas distribuidos como concesiones limitadas en el tiempo, permiten renovar una operación que sigue viva sin concederle una espera infinita. El vencimiento no debe implicar automáticamente destrucción: activa al supervisor.
Un supervisor escalonado
La supervisión puede seguir una escalera de coste:
- Heurística. Si existe progreso reciente, renovar.
- Comprobación estructurada. Consultar estado, señal de vida o metadatos de la herramienta.
- Juicio semántico. Solo ante ambigüedad, pedir a un modelo rápido un veredicto limitado.
- Intervención. Renovar, recordar el objetivo, solicitar cierre o elevar a una persona.
Un veredicto estructurado puede recomendar renovar la espera, pedir una señal, intervenir para cerrar o cambiar de estrategia, o elevar el caso a criterio humano.
Esta taxonomía es una decisión de ALLAN, no un estándar de la industria. Su calidad debe medirse mediante evaluaciones de falsos positivos, coste y resistencia a contenido adversarial. Un modelo supervisor no debe recibir instrucciones desde el contenido que está juzgando como si fueran órdenes.
Presupuestos como puntos de control
Un presupuesto sigue siendo necesario. Limita coste, número de pasos, herramientas y grado de delegación paralela. La diferencia está en qué ocurre al alcanzarlo.
En lugar de cortar siempre, el runtime puede abrir un checkpoint:
- continuar con un tramo adicional si existe progreso y presupuesto;
- cambiar de estrategia;
- resumir y cerrar con el mejor resultado disponible;
- solicitar intervención humana.
El presupuesto deja de ser una guillotina ciega y pasa a ser un punto de decisión. Esto no significa que todos los límites sean renovables ni que el agente pueda ampliarlos por sí mismo: los topes económicos y de seguridad siguen siendo duros.
La espera también es experiencia de usuario
Un sistema durable puede parecer roto si su interfaz permanece en silencio. La persona debe poder saber:
- qué está haciendo el agente;
- qué está esperando;
- cuánto tiempo lleva en ese estado;
- si la conexión se ha reanudado;
- si puede aportar información o cancelar;
- qué partes del trabajo ya están preservadas.
La reconexión no debe duplicar mensajes ni simular que una desconexión ha cancelado el trabajo. Del mismo modo, cerrar el stream no equivale a cancelar el run: son acciones distintas y deben nombrarse de forma distinta.
Estado actual y trabajo pendiente
En la revisión examinada de ALLAN están presentes el desacoplamiento principal de la petición, eventos reanudables durante la vida del servicio, leases, supervisión escalonada y checkpoints de presupuesto en parte del runtime. La re-suscripción completa de la interfaz desde un cursor y la representación fiel de todos los estados de espera permanecen pendientes.
No debe afirmarse todavía que existe recuperación general tras cualquier reinicio, suspensión universal para toda clase de evento, cancelación remota completa, notificaciones push o paridad plena con el ciclo de vida A2A. La persistencia de eventos y la reanudación de efectos externos siguen requiriendo contratos más fuertes.
Referencias
Fuente editorial de ALLAN
docs/intelligent-wait-supervision-design.md, editado para anonimizar el incidente y reconciliar el estado descrito con la revisión examinada.
Fuentes externas
- A2A Project, Agent2Agent Protocol Specification 1.0.0, especificación oficial.
- OpenAI, Background mode, documentación oficial.
- LangChain, LangGraph durable execution y persistence, documentación oficial.
- WHATWG, Server-sent events, estándar vivo de HTML.
- Gray, C. y Cheriton, D., Leases: an efficient fault-tolerant mechanism for distributed file cache consistency, ACM SIGOPS Operating Systems Review, 1989.