La crisis de tiempo de espera: por qué la web moderna se está rompiendo bajo el peso de la IA agentic

Si ha utilizado algún agente de IA avanzado recientemente, ya sea O1 de OpenAI, Devin o un agente de razonamiento empresarial personalizado, probablemente lo haya visto. La rueca que gira durante exactamente 60 segundos. Seguido de la pantalla en blanco. Seguido por el temido: “504 Gateway Timeout”.

No es un error en el código. No es una caída del servidor. Es una incompatibilidad arquitectónica fundamental entre la Internet que construimos (Web 2.0) y la carga de trabajo de la Internet que estamos construyendo (IA agente).

La web moderna se enfrenta a una crisis de tiempo de espera, y solucionarla requiere derribar la suposición central de que la web es “rápida”.

El antiguo contrato: DESCANSO y la regla de los 30 segundos

Durante los últimos 20 años, la web se ha optimizado para una cosa: Capacidad de respuesta. El paradigma dominante es REST (Transferencia Representacional del Estado). El contrato entre Cliente y Servidor es sincrónico y sencillo:

1. Solicitud: El cliente solicita datos (p. ej., “Consígueme el perfil de usuario”).
2. Proceso: El servidor recupera datos (consulta de base de datos: ~50 ms).
3. Respuesta: El servidor devuelve los datos.

Si el paso 2 tarda más de 30 segundos (o 60 segundos en algunas nubes), la infraestructura entra en pánico. Load Balancer (NGINX, AWS ALB, Cloudflare) supone que el servidor está muerto, “zombificado” o atrapado en un bucle infinito. Corta la conexión para proteger el sistema. Esta era una característica, no un error. Impidió que los procesos colgados consumieran RAM y subprocesos de CPU. Impuso una disciplina de “fallo rápido”.

Ingrese la IA agente: la carga de trabajo que hace temblar el tiempo

Clásicamente, las computadoras eran rápidas. Si una consulta tardó 5 minutos, su SQL era incorrecto. Pero la IA agente no se trata sólo de “consultar”. Es “pensar”.

Un modelo de razonamiento de clase “O1” o un flujo de trabajo agente no se limita a buscar datos. Eso:

1. Descompone un mensaje en un plan.
2. Navega por la web (buscando 10 sitios).
3. Escribe código.
4. Ejecuta código en un entorno limitado.
5. Analiza los registros de errores.
6. Refactoriza el código.
7. Itera.

Este proceso no se mide en milisegundos. Se mide en minutos. A veces horas. Cuando fuerzas un proceso de pensamiento de 5 minutos en una tubería REST de 30 segundos, la tubería estalla. El Cliente (navegador) todavía está esperando, pero el Intermediario (Load Balancer) ya colgó el teléfono. El Agente termina su trabajo 4 minutos después, pero no tiene con quién hablar. El resultado es una tarea perdida, un usuario frustrado y créditos informáticos desperdiciados.

El cambio arquitectónico: de lo sincrónico a lo impulsado por eventos

Para sobrevivir a la Era Agentic, estamos viendo el cambio arquitectónico más significativo desde la muerte de SOAP/XML. Estamos pasando de Solicitud/Respuesta síncrona a Arquitectura asincrónica basada en eventos (EDA).

El sistema de “billetes”

En el nuevo paradigma, cuando le pides a una IA que “constrúyame un sitio web”, el servidor no se mantiene firme.

1. Solicitud: El cliente envía el mensaje.
2. Confirmación: El servidor responde inmediatamente (HTTP 202 aceptado): “Lo tengo. Aquí está su ID de ticket n.° 1234. Estoy trabajando en ello. Adiós”.
3. La desconexión: La conexión HTTP se cierra. El navegador es libre de hacer otras cosas.
4. Procesamiento: El Agente trabaja en segundo plano (minutos/horas).
5. Notificación: Cuando termina, el servidor envía una Señal.

Protocolos de señalización: ¿Cómo lo sabe el navegador?

Estamos viendo una guerra de protocolos para manejar el Paso 5:

• Encuesta: El navegador pregunta cada 5 segundos: “¿Ya terminaste?” (Simple, pero requiere muchos recursos).
• Webhooks: El servidor llama a una URL específica cuando termina (excelente para servidor a servidor, malo para navegadores).
• Eventos enviados por el servidor (SSE): Un canal persistente unidireccional donde el servidor envía actualizaciones (“Escaneando…”, “Escribiendo código…”, “Listo”). Este se está convirtiendo en el estándar para la transmisión de tokens LLM.
• WebSockets: Comunicación bidireccional completa. Excesivo para la mayoría de la generación de texto, pero necesario para agentes de voz/vídeo en tiempo real.

La ejecución duradera explota

La crisis del tiempo de espera ha impulsado el aumento explosivo de plataformas de ejecución duradera como Temporal, Inngest y Hatchet.

En un script estándar de Python/Node, si el servidor se reinicia o falla mientras el Agente lleva 4 minutos en una tarea, esos 4 minutos de trabajo se pierden. La IA tiene “amnesia”. Los motores de ejecución duradera introducen un registro persistente. Guardan el “estado” de la función en cada paso.

• Paso 1: Plan generado (Guardado).
• Paso 2: Scrape Google (Guardado).
• CRASH (reinicio del servidor).
• Recuperación: el servidor se activa, ve que se realizó el paso 2 y se reanuda inmediatamente en el paso 3.

Esto es fundamental porque la IA es no determinista y cara. No puede darse el lujo de volver a ejecutar una llamada API de $2.00 solo porque se reinició un pod. La ejecución duradera garantiza que una vez que se inicia un Agente, terminará, garantizado.

El futuro: A2A (Agente a Agente)

Nos acercamos rápidamente a un mundo en el que la mayor parte del tráfico de Internet no es de persona a servidor, sino de agente a agente (A2A). A estos agentes no les importa “cargar spinners” o “latencia percibida”. Se preocupan por la fiabilidad y la corrección.

Estamos viendo el nacimiento de nuevos protocolos (como MCP - Model Context Protocol) diseñados específicamente para permitir que los agentes se descubran y hablen entre sí durante largos periodos de tiempo. La era de la “Web instantánea” está llegando a su fin. La “Web reflexiva” está comenzando. Sólo tenemos que dejar de cronometrar.

Fuentes (4)

• temporal.io Durable Execution
• platform.openai.com OpenAI: Optimizing Latency
• aws.amazon.com Asynchronous Patterns
• inngest.com Event-Driven Systems