Cuando un agente de IA dura más que la petición HTTP que lo lanzó
Diseñar agentes como peticiones HTTP síncronas rompe en cuanto el trabajo supera el timeout de la pasarela: llega un 504, el worker sigue gastando tokens y el reintento duplica la ejecución.
Un agente de IA que tarda minutos u horas no encaja en una petición HTTP, que está acotada por el cliente, los proxies y la pasarela. Cuando el primero sobrevive al segundo el usuario ve un 504, pero el worker sigue vivo: llamando herramientas, consumiendo tokens y, si tiene permiso para escribir, creando tickets o enviando correos. El problema no es el timeout. Es que se ha tratado la petición como si fuera el trabajo.
El desajuste es de ciclo de vida. Una petición HTTP se conecta, se procesa, responde y se cierra. Una ejecución de agente se encola, planifica, espera al modelo, espera a una herramienta, espera aprobación humana, reintenta, transmite progreso y solo entonces termina, falla o se cancela. HTTP asume que el servidor puede acabar rápido; un agente no puede prometer eso, porque además puede quedarse colgado en un rate limit, en un parser de documentos o en un sandbox de ejecución de código.
Lo que se rompe en producción
El primer síntoma es el comportamiento de cerebro dividido: el usuario cree que la operación falló y el sistema sigue mutando estado. Un timeout en una consulta de solo lectura molesta; un timeout en un agente que puede borrar registros es un incidente esperando su turno.
El segundo es el reintento. El cliente no ve resultado, vuelve a pulsar el botón, o la app móvil reintenta sola tras perder la red. Ahora hay dos ejecuciones solapadas para la misma intención y ninguna forma limpia de decidir cuál manda. Los agentes no son funciones puras: repetir desde cero puede dar decisiones distintas y duplicar efectos secundarios.
A eso se suman cuatro cosas más. El estado guardado en memoria del proceso desaparece en el siguiente despliegue, reinicio o scale-in. El streaming sirve para entregar progreso, no como fuente de verdad. Cada llamada a herramienta convierte la ejecución en una transacción distribuida que necesita idempotencia, reintentos y a veces compensación. Y la cancelación tiene que ser un protocolo cooperativo, no una esperanza: si el agente no consulta el flag de cancelación, seguirá trabajando.
Hay casos peores. Un flujo con pausas humanas puede quedarse días esperando, y el token de autenticación que usaba el agente caduca mientras tanto.
Qué hacer en su lugar
La propuesta es dejar de tratar la petición como el job. Se crea un recurso de ejecución, se devuelve un 202 Accepted con la cabecera Location apuntando al recurso y el trabajo se ejecuta de forma asíncrona en un worker o en un motor de workflows. El cliente recibe un identificador de ejecución al instante y consulta el estado por separado: un endpoint para lanzar, otro para consultar, otro para el flujo de eventos y otro para cancelar.
Encima de eso hacen falta claves de idempotencia para que un reintento no genere una segunda ejecución, estado persistido en almacenamiento duradero en lugar de en variables del proceso, SSE o WebSockets para el progreso y patrones de ejecución durable cuando haya pausas largas o flujos de varios pasos. El 202 no es un truco: es la respuesta honesta para un trabajo aceptado pero no terminado.
Nada de esto es exótico. Son las mismas piezas que cualquier sistema con colas y tareas de larga duración lleva años usando; lo nuevo es que ahora el trabajo lo ejecuta un agente que decide por su cuenta y toca sistemas externos. Quien despliegue agentes con efectos reales y siga colgándolos de una petición síncrona va a descubrir el problema en producción, con dos ejecuciones activas y ninguna autoridad clara.
