Los agentes de IA de larga duración necesitan canales duraderos

La documentación de OpenAI sobre el modo en segundo plano ya describe un problema normal de los agentes: las tareas de razonamiento pueden tardar minutos; los desarrolladores pueden consultar una respuesta por ID, cancelarla y reanudar un flujo desde un número de secuencia registrado.¹

¿Cuáles son las ideas principales?

• Una ejecución larga de un agente necesita una dirección. El cliente debe poder reconectarse al mismo trabajo, reanudar la transmisión desde un cursor conocido, enviar un comando para orientar el trabajo, cancelar la ejecución e inspeccionar la evidencia.
• El sondeo por sí solo ofrece un contrato débil. Puede informar el estado, pero el trabajo serio de agentes también necesita comandos, historial de eventos, flujos reanudables, artefactos, autorización y puntos de control.
• La ejecución duradera resuelve solo una parte del sistema. Los flujos de trabajo al estilo Temporal preservan el estado de ejecución y el historial de eventos, pero el usuario todavía necesita una superficie de comunicación duradera alrededor del trabajo en curso.²³
• Los WebSockets ayudan, pero un socket no es toda la dirección. Una conexión caída no debería borrar la ruta del usuario de regreso a la ejecución del agente.
• La superficie del producto importa. El usuario debería ver una ejecución coherente, con evidencia, decisiones y próximas acciones, no registros dispersos y texto de estado optimista.

Los agentes de IA de larga duración no encajan en el viejo molde de solicitud-respuesta. Una solicitud normal tiene un punto de conexión, una respuesta y un tiempo límite. Una ejecución seria de un agente tiene duración, historial de eventos, artefactos intermedios, interrupciones del usuario, estado del modelo y de las herramientas, reglas de cancelación y una persona que puede irse y volver.

El objeto que falta no es otro mensaje de chat. Lo que falta es un canal duradero: una dirección estable para una pieza de trabajo en ejecución.

Ya sostuve que los agentes administrados están absorbiendo la infraestructura de ejecución y que las trazas de ejecución de agentes se están convirtiendo en el contrato del entorno de ejecución. Los canales duraderos se ubican entre esas dos ideas. Una traza prueba qué ocurrió. Un entorno administrado mantiene vivo el trabajo. Un canal duradero permite que el producto y el usuario hablen con ese trabajo mientras sigue vivo.

¿Qué se rompe en el viejo modelo de solicitud?

El viejo modelo web supone que el cómputo termina dentro de una solicitud o se mueve a un trabajo en segundo plano. La base de datos guarda el estado duradero. El servidor de la aplicación sigue siendo sin estado. Un cliente puede actualizar la página, llegar a otro servidor y leer la misma fila de la base de datos.

El trabajo de agentes tensiona ese modelo de tres maneras. Puede ejecutarse durante minutos u horas. Lleva un estado de proceso que no se reduce limpiamente a un solo registro de base de datos. Necesita control bidireccional: observar, interrumpir, aprobar, redirigir, cancelar y reanudar.

Zak Knill describió la misma presión como un problema de enrutamiento. En su publicación de mayo de 2026, sostiene que el trabajo de agentes largo, con estado e interactivo necesita una primitiva enrutable que pueda apuntar al proceso que hace el trabajo, no solo a la base de datos que almacena sus salidas.⁴ Lo útil de ese marco es esto: el cliente quiere poder decir “entrega el comando Y a la ejecución X”, incluso si el socket, worker, pestaña o proceso original desapareció.

Los trabajos en segundo plano todavía sirven para tareas simples. Redimensionar una imagen, exportar una factura o ejecutar una sincronización nocturna quizá solo necesite estar en cola, en ejecución, completado o fallido. El trabajo de agentes cruza otra línea cuando el usuario necesita dirigirlo antes de que termine.

¿Por qué el sondeo se queda corto?

El sondeo le da al cliente una forma de preguntar: “¿ya terminaste?”. Pero no le da un contrato completo de interacción.

El modo en segundo plano de OpenAI incluye sondeo porque resuelve el problema del tiempo límite. La documentación indica a los desarrolladores que recuperen una respuesta en segundo plano mientras el estado siga como queued o in_progress, y que se detengan cuando llegue a un estado terminal.¹ La misma página también expone cancelación y reanudación de flujos con un cursor sequence_number, lo que apunta más allá del sondeo básico hacia un contrato de ejecución más rico.¹

Un producto que se queda solo en el sondeo suele repartir el estado del agente en demasiados lugares:

El sondeo puede seguir siendo una vía de acceso. El error es tratarlo como el contrato del producto.

¿Qué debería contener un canal duradero?

Un canal duradero es un contrato de comunicación con nombre alrededor de una ejecución. La implementación puede usar un motor de flujos de trabajo, una cola, una tabla de eventos, WebSocket, un flujo SSE, un tema pub/sub, una sesión de agente administrado o una mezcla de esas piezas. El contrato del producto importa más que el transporte.

El contrato mínimo tiene nueve partes:

Cada evento necesita tipo, número de secuencia, marca de tiempo, actor, referencia a la carga útil y política de redacción. Sin esa estructura, el registro de eventos se convierte en otra transcripción de chat.

El canal también necesita criterio. No transmitas cada token cuando el usuario necesita decisiones. No ocultes fallas de herramientas detrás de un spinner amable. No conviertas un agente en ejecución en una tormenta de notificaciones. Un buen canal muestra los pocos eventos que ayudan al usuario a confiar en el trabajo, dirigirlo o detenerlo.

¿Cómo apuntan los sistemas existentes hacia este patrón?

Temporal le da al lado de ejecución un vocabulario maduro. Una ejecución de flujo de trabajo tiene historial de eventos, reproducción, código determinista de flujo de trabajo y actividades para trabajo con el mundo exterior, como llamadas API, consultas a bases de datos, llamadas LLM y E/S de archivos.² La documentación de Temporal sobre paso de mensajes en TypeScript describe los flujos de trabajo como servicios con estado que reciben consultas, señales y actualizaciones. Los clientes pueden recuperar un identificador de flujo de trabajo por ID de flujo de trabajo, consultar estado, enviar señales y ejecutar actualizaciones.³

Ese modelo encaja bien con el trabajo de agentes. Las consultas responden “¿qué estado reporta la ejecución?”. Las señales responden “cambia de rumbo, por favor”. Las actualizaciones responden “haz un cambio registrado y devuelve un resultado”. El historial de eventos responde “¿qué pasó?”. Un equipo no necesita Temporal para aprender de esta forma, pero la forma les da a los productos de agentes un vocabulario mejor que “trabajo en segundo plano más chat”.

Cloudflare Durable Objects apunta a otra pieza: coordinación direccionable. Cloudflare describe cada Durable Object como una instancia globalmente única con almacenamiento, útil para coordinar estado entre varios clientes.⁵ Su documentación de WebSocket describe conexiones bidireccionales de larga duración e hibernación, que mantiene a los clientes conectados mientras el objeto duerme y luego lo despierta cuando llega un mensaje.⁶ Eso no convierte a Durable Objects en un entorno universal de ejecución para agentes. Sí muestra por qué un objeto de coordinación direccionable se siente natural para superficies de agentes en vivo.

El artículo de Anthropic sobre agentes de larga duración agrega el lado del trabajo humano. La publicación dice que los agentes todavía tienen dificultades al atravesar muchas ventanas de contexto y describe un patrón donde sesiones posteriores avanzan de manera incremental mientras dejan artefactos claros para la siguiente sesión.⁷ Los canales duraderos deberían llevar esos artefactos a la superficie del producto, no enterrarlos en registros privados.

¿Qué construiría primero?

Empezaría con un servicio pequeño de ejecuciones, no con una gran plataforma de orquestación.

Crea una tabla runs con propietario, estado, marcas de tiempo y resumen actual. Crea una tabla o flujo run_events con números de secuencia crecientes. Guarda cargas útiles grandes y artefactos por separado, y luego haz referencia a ellos desde los eventos. Agrega un punto de conexión de flujo reanudable y un punto de conexión de señal tipada. Haz que la cancelación sea idempotente. Pon cada transición de estado en el registro de eventos.

Después, limita el vocabulario de eventos:

La UI ahora puede mostrar una ejecución coherente. El usuario puede irse, volver, revisar eventos, inspeccionar artefactos y dirigir el trabajo desde la misma dirección. El agente puede dejar de afirmar éxito en prosa y empezar a adjuntar evidencia a las transiciones de estado.

¿Qué deberían evitar los equipos?

Evita tres atajos.

Primero, evita una transcripción de chat pura. El chat puede iniciar trabajo y recoger aclaraciones. No debería servir como único objeto de ejecución para una tarea larga.

Segundo, evita que la transmisión cruda de tokens sea la superficie principal de progreso. Los flujos de tokens ayudan a un desarrollador a depurar latencia, pero la mayoría de los usuarios necesita hitos, bloqueos, artefactos y decisiones. Un canal duradero todavía puede exponer eventos crudos para inspección experta.

Tercero, evita filtrar procesos privados. Una superficie pública de producto debería mostrar evidencia, no prompts privados, cuerpos de hooks, rutas de archivos locales ni mecanismos internos de puntuación. El usuario necesita lo suficiente para confiar en el trabajo. No necesita cada truco interno que lo hizo posible.

Esa línea de privacidad también aplica a la escritura pública sobre sistemas de agentes. Comparte el contrato. Mantén privada la maquinaria privada.

¿Cómo cambia la evaluación un canal duradero?

Un canal duradero hace que la evaluación sea menos teatral.

En lugar de preguntar si la respuesta final suena plausible, quien evalúa puede inspeccionar la ejecución:

• ¿La ejecución empezó con el propietario, los permisos y el alcance correctos?
• ¿El agente emitió un plan antes de actuar?
• ¿Cada artefacto mencionado salió de un evento registrado?
• ¿Las fallas produjeron puntos de control útiles?
• ¿Las señales del usuario cambiaron la ejecución de la manera esperada?
• ¿La cancelación terminó con un solo estado terminal?
• ¿El informe final citó evidencia del registro de eventos?

Esa lista convierte la puerta de evidencia en algo que el entorno de ejecución puede sostener directamente. También se conecta con la capa de limpieza: muchos productos de agentes ganarán haciendo que las ejecuciones desordenadas sean comprensibles, reanudables y revisables.

Resumen rápido

Los agentes de IA de larga duración necesitan canales duraderos porque el usuario necesita una ruta estable para volver al trabajo. El sondeo puede informar el estado, pero no puede cargar todo el contrato por sí solo. Una buena ejecución de agente necesita un ID de flujo de trabajo, eventos ordenados, flujos reanudables, señales tipadas, cancelación idempotente, referencias a artefactos, permisos y puntos de control legibles para humanos. La ejecución duradera mantiene vivo el trabajo; los canales duraderos permiten que el usuario y el producto interactúen con él.

Preguntas frecuentes: agentes de IA de larga duración y canales duraderos

¿Los agentes de IA de larga duración requieren Temporal?

No. Temporal les da a los equipos un vocabulario sólido de flujos de trabajo y un modelo de ejecución maduro, pero el contrato de canal duradero puede funcionar sobre infraestructura más simple. Empieza con ID de ejecución estables, eventos ordenados, flujos reanudables, comandos tipados y artefactos. Pasa a un motor de flujos de trabajo cuando los reintentos, la reproducción, los temporizadores y la escala operativa lo justifiquen.

¿Los WebSockets bastan para mostrar el progreso de un agente?

No. Los WebSockets dan una conexión bidireccional en vivo. El producto todavía necesita una dirección duradera, historial de eventos, cursor de reconexión, permisos y estados terminales. Un socket puede transportar un canal, pero no debería definir todo el canal.

¿El sondeo siempre es malo?

No. El sondeo funciona para verificaciones simples de estado y puede seguir siendo una ruta de respaldo. Los problemas empiezan cuando se convierte en la única forma de observar, dirigir o recuperar la ejecución larga de un agente.

¿Qué debería construir primero un equipo pequeño?

Construye un recurso runs y un registro run_events de solo anexado. Agrega un flujo reanudable una vez que el registro de eventos tenga números de secuencia. Agrega señales tipadas solo para comandos que el producto pueda cumplir con seguridad: aprobar, pausar, revisar, agregar contexto y cancelar.

¿Qué debe incluirse en los eventos de ejecución de un agente?

Registra transiciones de estado, planes, inicios y finales de herramientas, creación de artefactos, señales humanas, bloqueos, cancelaciones, fallas y finalizaciones. Mantén las cargas útiles sensibles fuera del texto en línea de los eventos. Guarda detalles privados detrás de referencias redactadas y verificaciones de acceso.

Referencias