Agentes de IA duraderos: una lista de verificacion para elegir runtime en flujos de trabajo de produccion en 2026

Por que los agentes de IA duraderos son una decision de runtime, no solo una decision de modelo

Los agentes de IA duraderos no son prompts mas fuertes con unas cuantas herramientas conectadas. Son flujos de trabajo de produccion que pueden sobrevivir a retrasos, fallos parciales, eventos duplicados, revision humana, cambios de proveedor y reinicios de workers. Esa distincion importa porque la mayoria de las demos de agentes ocultan la parte mas dificil. El modelo responde, una herramienta se ejecuta y la pagina parece convincente. Produccion hace una pregunta menos favorecedora: que pasa cuando la aprobacion llega manana, el worker muere a mitad del proceso o el mismo webhook llega dos veces?

Mi opinion: muchos equipos eligen la infraestructura de agentes demasiado tarde. Escogen un modelo, construyen un bucle de chat, conectan unas cuantas herramientas internas y luego descubren que el producto real es un motor de flujos de trabajo con una interfaz de IA. Para entonces, el estado esta disperso entre prompts, registros, memoria temporal y efectos secundarios. El runtime ya se ha elegido por accidente.

Para la planificacion de 2026, la pregunta mas segura no es que modelo deberia ejecutar el agente. Es que runtime deberia poseer el estado, los reintentos, los permisos, las aprobaciones y la recuperacion. La documentacion de Durable AI de Temporal parte de conceptos de orquestacion de flujos de trabajo. Cloudflare Agents y Durable Objects son relevantes para agentes con estado y coordinacion en aplicaciones alojadas en Cloudflare. Los agentes de Convex encajan con equipos que ya construyen backends de aplicaciones reactivas. Val Town encaja con automatizacion programable ligera. Un stack personalizado puede funcionar cuando el control importa mas que la velocidad, pero tambien significa que el equipo posee las partes incomodas.

La matriz de ajuste para agentes duraderos

Un proceso practico de seleccion necesita menos adjetivos de proveedores y mas pruebas de fallo. La matriz de ajuste para agentes duraderos compara runtimes en cinco ejes.

Temporal es un candidato fuerte cuando el flujo de trabajo es de larga duracion, con estado y lleno de bordes de procesos de negocio. Vale la pena leer su documentacion de IA si el equipo ya piensa en terminos de workflows, activities, signals y reintentos: https://docs.temporal.io/ai. La contrapartida es que los equipos deben aprender el modelo de flujos de trabajo y tratar el comportamiento del agente como parte de un sistema distribuido mas amplio.

Cloudflare Agents, junto con Durable Objects, sirven a equipos que quieren agentes con estado en aplicaciones web alojadas en Cloudflare. La documentacion relevante esta en https://developers.cloudflare.com/agents/ y https://developers.cloudflare.com/durable-objects/. Este camino puede ser atractivo para sesiones de agente orientadas al usuario, coordinacion y estado de baja latencia dentro de la plataforma de Cloudflare. La salvedad es el ajuste de plataforma. Si el resto del sistema vive lejos de Cloudflare, las decisiones de integracion importan.

Los agentes de Convex encajan con equipos de producto que ya usan Convex o quieren que el estado del agente este cerca de los datos reactivos de la aplicacion: https://docs.convex.dev/agents/overview. La ventaja es menos pegamento entre el estado de la aplicacion y el estado del agente. El riesgo es el mismo que con cualquier runtime nativo de la aplicacion: puede ser perfecto para flujos de producto y menos natural para la orquestacion entre sistemas.

Val Town debe tratarse mejor como una capa rapida de automatizacion, no como una plataforma universal de agentes: https://docs.val.town/. Es util para pequenas herramientas internas, scripts, tareas programadas, prototipos y codigo de union. Es menos apropiado cuando el flujo de trabajo necesita auditabilidad estricta, aprobaciones de varios pasos, permisos complejos o respuesta profunda a incidentes.

Un runtime personalizado, construido con colas, bases de datos, workers, planificadores y gateways de modelos, puede ser la respuesta correcta para entornos regulados o restricciones de arquitectura inusuales. Da control sobre almacenamiento, redes, enrutamiento de modelos y politicas. Tambien significa que el equipo debe disenar directamente idempotencia, reintentos, observabilidad, reproduccion, evaluaciones, flujos de aprobacion y controles de coste. Eso no es un proyecto de fin de semana.

Un manual practico de evaluacion

No evalues runtimes de agentes duraderos con una demo de camino feliz. Elige un flujo de trabajo real y haz que falle a proposito. Por ejemplo, usa un flujo de triaje de soporte que lee un ticket, comprueba el contexto de la cuenta, redacta una respuesta, espera aprobacion, actualiza un CRM y envia un mensaje. Luego prueba las partes que suelen romperse.

Mata el worker despues de la llamada al modelo pero antes de la accion de escritura. Entrega el mismo webhook dos veces. Cambia el esquema de respuesta de una herramienta. Retrasa la aprobacion humana durante 24 horas. Devuelve un timeout parcial desde el CRM. Rota una clave de proveedor de modelos. Pide al agente que reanude desde la mitad. Si el runtime no puede convertir esos casos en algo rutinario, no esta listo para ese flujo de trabajo.

Una pequena prueba de durabilidad debe responder estas preguntas:

1. Donde se almacena el estado del flujo de trabajo y quien lo posee?
2. Puede el flujo de trabajo reanudarse despues de reiniciar un proceso sin repetir acciones inseguras?
3. Las llamadas a herramientas son idempotentes o estan protegidas por claves de idempotencia?
4. Puede una persona aprobar, rechazar o editar una accion propuesta sin romper la ejecucion?
5. Puede un operador inspeccionar el historial y explicar por que actuo el agente?
6. Los prompts, esquemas de herramientas, versiones de modelos y salidas se registran lo bastante bien para evaluacion?
7. Que ocurre cuando el modelo da una mala respuesta pero el runtime se comporta correctamente?

Esa ultima pregunta es facil de saltar. Tambien es donde muchos programas de agentes se vuelven caros. Un runtime duradero puede hacer que el fallo sea recuperable, pero no puede convertir un diseno de tarea debil en uno bueno. Los equipos siguen necesitando conjuntos de evaluacion, controles de politicas y rutas claras de escalado.

La seguridad y la gobernanza cambian la decision de runtime

La seguridad de agentes no es solo un problema de prompt. Es un problema de arquitectura de runtime. El marco de la trifecta letal de Simon Willison es una lente util porque conecta tres condiciones: acceso a datos privados, exposicion a contenido no confiable y una forma de exfiltrar informacion: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/. Cuando las tres aparecen en el mismo flujo de agente, el riesgo de inyeccion de prompts se vuelve mas concreto.

Por tanto, la seleccion del runtime debe separar rutas de lectura, rutas de escritura y rutas de comunicacion saliente. Un agente de investigacion que lee documentos internos no deberia tener automaticamente permiso para enviar correos a destinatarios arbitrarios. Un agente de compras que puede redactar una orden de compra no deberia poder aprobarla sin controles de politicas. Un agente de desarrollo que lee codigo fuente deberia tener reglas estrechas para publicar datos fuera del workspace.

La aprobacion humana sigue siendo util, pero solo si es especifica. Aprobar esta ejecucion es vago. Aprobar el envio de este correo exacto a estos destinatarios con estos adjuntos es mejor. El runtime debe conservar la accion propuesta, el revisor, la decision y la llamada final a la herramienta. De lo contrario, la aprobacion es solo gobernanza debil con una marca de tiempo.

En que se equivocan los equipos

El primer error es tratar los reintentos como inteligencia. Reintentar una mala llamada a herramienta puede arreglar un fallo transitorio. Reintentar un mal plan puede hacer que el dano se repita mas rapido. Los runtimes duraderos necesitan politicas de reintento, pero tambien condiciones de parada, escalado humano y registros que muestren que se reintento y por que.

El segundo error es confundir memoria con fuente de verdad. La memoria conversacional es contexto util. No deberia ser el unico lugar donde viven aprobaciones, estado de clientes, acciones financieras o decisiones de cumplimiento. Los flujos de trabajo duraderos necesitan una fuente de verdad real, y el runtime debe dejar claro ese limite.

El tercer error es omitir la proteccion contra duplicados. Los webhooks se repiten. Los usuarios hacen doble clic. Los planificadores se solapan. Los proveedores agotan el tiempo de espera despues de completar una solicitud. Cualquier flujo de trabajo que escriba en sistemas externos necesita claves de idempotencia, IDs externos u otro patron de control de duplicados.

El cuarto error es construir una plataforma antes de probar un flujo de trabajo. El trabajo de plataforma parece productivo porque crea abstracciones. El mejor primer movimiento es un flujo de trabajo estrecho con bordes dolorosos. Si el runtime lo maneja bien, las abstracciones se basaran en evidencia en lugar de gusto.

El quinto error es ignorar coste y latencia hasta el lanzamiento. Los agentes duraderos pueden llamar a multiples modelos, herramientas, bases de datos y controles de politicas. Algunos flujos de trabajo necesitan eso. Otros necesitan un camino mas simple, como recuperacion mas una recomendacion redactada. Mide la ejecucion completa, no solo la latencia del modelo.

Rutas recomendadas

Para equipos de producto que agregan agentes a una aplicacion existente, empieza con el runtime mas cercano al estado de la aplicacion. Convex puede encajar si el producto ya usa Convex. Cloudflare puede encajar con sesiones con estado orientadas al usuario dentro de aplicaciones alojadas en Cloudflare. El factor decisivo suele ser la propiedad operativa: las personas que envian la funcionalidad tambien deben poder inspeccionar y depurar el agente.

Para equipos de plataforma que orquestan procesos de negocio largos, Temporal merece una evaluacion seria. Convierte la duracion, los reintentos, las senales y el historial del flujo de trabajo en preocupaciones de primera clase. Eso es util cuando los agentes pasan a formar parte de procesos de incorporacion, finanzas, operaciones, compras o soporte.

Para equipos de desarrollo que construyen automatizaciones internas, Val Town puede ser un buen punto de partida cuando la tarea es pequena y reversible. Manten el alcance honesto. Si la automatizacion empieza a tocar datos sensibles, aprobaciones o escrituras irreversibles, mueve el flujo de trabajo a un runtime con controles mas fuertes.

Para equipos con cumplimiento estricto, redes inusuales o necesidades personalizadas de enrutamiento de modelos, un stack personalizado puede estar justificado. El equipo debe presupuestar mas que workers y colas. Necesitara aplicacion de politicas, rastros de auditoria, almacenamiento de evaluaciones, herramientas de reproduccion, procedimientos de incidentes y mantenimiento continuo.

La lista de verificacion de planificacion

Antes de que empiece el trabajo de produccion, escribe las respuestas en lenguaje claro:

El mejor runtime no es el que tiene mas branding de agentes. Es el que hace que el fallo sea comprensible, limita las acciones inseguras y da a los operadores un camino limpio de vuelta a un estado conocido. Eligelo con un flujo de trabajo real, no con una presentacion.