El segundo vector de coste de los agentes IA: durable execution con Temporal

Notación: importes en euros (N €), decimales con coma. No se usa el símbolo de dólar (en este sitio es delimitador de fórmula).

La tesis: los agentes tienen dos vectores de coste, no uno

Casi todo el discurso de coste de la IA agéntica se centra en un solo vector: el coste de inferencia (los tokens). Y es resoluble: FastMCP + vLLM en local elimina el coste de inferencia —sirves los modelos en tu hierro, el coste por token cae a tu coste amortizado, sin factura de API—. Pero hay un segundo vector que casi nadie mide y que mata más proyectos: el coste de la ejecución defectuosa. Un agente no es una llamada, es una secuencia de pasos (razonar, llamar a una herramienta, razonar, llamar a otra…), y cuando esa secuencia falla a la mitad sin estado persistido, el coste no es lineal: se duplica, se dispara con los reintentos y se infla en cada recuperación. Este artículo trata ese segundo vector, cómo lo ataca la durable execution (con Temporal como referencia), qué dice el estado del arte y los papers, y por qué es la causa real de tanta cancelación.

El marco que respalda la urgencia es el de Gartner: predice que más del 40 % de los proyectos de IA agéntica serán cancelados antes de finales de 2027, por costes crecientes, valor de negocio poco claro o controles de riesgo inadecuados (Gartner). “Costes crecientes” es exactamente este segundo vector: no el de servir el modelo, sino el de ejecutarlo mal.

Los tres gastos de un agente defectuoso

El coste de la ejecución defectuosa se descompone en tres fuentes concretas, y conviene verlas con números:

Vector 1: fallos que cobran doble

Sin estado persistido, un fallo en el paso 15 de 20 te cuesta los tokens de los 14 pasos anteriores (que ya pagaste) más el reintento completo desde cero. El coste desperdiciado de un agente sin checkpoint, por fallo, es:

$$\text{coste desperdiciado} = \text{tokens de los pasos completados} \times \text{coste por token} \times (\text{reintentos})$$

Cuanto más larga la secuencia y más tarde falle, más caro: un fallo al 75 % del trabajo tira el 75 % del coste. La durable execution checkpointa cada paso: si el worker cae a la mitad, otro retoma el workflow exactamente donde se quedó, no desde cero (Temporal). Temporal usa su Event History como registro de las decisiones pasadas; ante un fallo, reproduce el progreso hasta la fecha y reanuda en el punto exacto (CallSphere). El paso 15 falla → se reintenta el paso 15, no los 14 anteriores. El coste desperdiciado pasa de “los 14 pasos” a “el paso que falló”.

Vector 2: retries sin control

Los agentes que reintentan sin política disparan la factura de API o de cómputo: un bucle de reintentos ante un rate limit puede generar decenas de llamadas facturables por una sola tarea. La durable execution define retry policies por activity: límites duros de reintentos, backoff exponencial y timeouts que acotan el coste máximo posible de cada llamada. En vez de “reintenta hasta que funcione” (coste ilimitado), defines “máximo N reintentos con backoff y timeout de T” (coste acotado).

El estado del arte lo respalda con datos: el benchmark ReliabilityBench evalúa la fiabilidad de agentes bajo fallos controlados y encuentra que el rate limiting es el fallo más dañino de todos (arXiv 2601.06112). Es decir, justo el fallo que un retry sin política convierte en una espiral de coste. Acotar los reintentos no es higiene, es la defensa contra el modo de fallo que la literatura señala como el peor.

Vector 3: contexto inflado en recovery

Sin estado persistido, el agente reconstruye el contexto completo en cada recuperación: vuelve a cargar todo el historial de la conversación/tarea para “recordar” dónde estaba, pagando los tokens de ese contexto enorme en cada recovery. Con durable execution, el estado vive en el historial del workflow, así que el siguiente paso recibe solo el contexto necesario para ese paso, no la conversación entera. El ahorro es directo: menos tokens de entrada por paso, y sin la penalización de reconstruir el contexto tras cada fallo.

Ejemplo trabajado: el coste de un fallo

Pongamos números a los tres vectores. Un agente de 20 pasos que consume ~3.000 tokens por paso (razonamiento + llamada a herramienta), sobre inferencia propia a ~1,09 €/1M tokens, con un fallo al paso 15 y una tasa de fallo del 10 % de las ejecuciones:

La cifra absoluta parece pequeña porque la inferencia es propia y barata; pero el ratio es de ~15× menos desperdicio por fallo, y escala con la longitud de la secuencia y con el coste por token (si fuera una API externa a 10–30 €/1M, el desperdicio sin checkpoint se multiplicaría por 10–30). Y esto es solo el vector 1: súmale los retries sin control (vector 2), que pueden convertir un fallo en decenas de llamadas, y el contexto reconstruido en cada recovery (vector 3). El coste de la ejecución defectuosa no es el coste de inferencia × algo pequeño; es un multiplicador que crece con la complejidad del agente —y es exactamente lo que no aparece en la demo y sí en la factura de producción—.

Cómo funciona Temporal: workflows, activities y determinismo

Para entender por qué Temporal logra esto, sus dos primitivas:

• Workflow: la lógica de orquestación del agente (la secuencia de pasos, las decisiones). Tiene que ser determinista: ante el mismo Event History, produce las mismas decisiones. Eso es lo que permite reproducir la ejecución tras un fallo y llegar al mismo punto.
• Activity: cada paso con efectos secundarios (una llamada al LLM, a una herramienta, a una API). Las activities no son deterministas (el LLM es probabilístico), así que su resultado se persiste en el Event History: al reproducir, no se vuelven a ejecutar, se leen del historial.

El truco es esa separación: la lógica determinista (workflow) se reproduce barata desde el historial; los pasos caros y no deterministas (activities, las llamadas al modelo) se persisten y no se repiten. Por eso “el trabajo completado nunca se repite”: las activities completadas se leen, no se recomputan. Y las retry policies se definen por activity, así que cada llamada al modelo o a una herramienta tiene su propio límite de reintentos, backoff y timeout —el control de coste del vector 2, al nivel correcto—.

La durable execution: qué es y el panorama

La durable execution es un modelo de programación que garantiza que el código se completa pese a los fallos: cada paso se checkpointea automáticamente, y si un worker cae, otro retoma el workflow donde se quedó (Temporal). Cruzó a la “mayoría temprana” en 2025, con ofertas de AWS, Cloudflare y Vercel, impulsada precisamente por la infraestructura de agentes IA (Inngest).

El panorama de herramientas (la arquitectura de referencia de 2026 para agentes LLM durables): Temporal, AWS Step Functions Express, Restate, DBOS e Inngest como primitivas de durable execution; y el modelo de checkpointer de LangGraph (PostgresSaver, RedisSaver, DynamoDBSaver) en el lado de los frameworks de agentes (render.com). Temporal destaca por su modelo workflow-as-code y su Event History como fuente de verdad.

Para una plataforma soberana, los que se self-hostean (Temporal, Restate, DBOS) mantienen el estado en tu cluster; los SaaS (Step Functions) sacan la ejecución a una jurisdicción ajena. Temporal es la elección por madurez y por su despliegue on-prem completo.

El coste de la propia durable execution

Honestidad de datos: la durable execution no es gratis. Tiene dos costes a vigilar:

1. Overhead de ejecución: persistir el estado y reproducir el historial añade latencia y cómputo. Las arquitecturas de referencia lo cifran en torno a un 5–20 % de overhead en una carga de 100.000 ejecuciones/día (render.com).
2. Precio por paso: en las ofertas con precio por paso, orquestar muchas llamadas de modelo, reintentos por rate limit e interacciones complejas genera numerosos pasos facturables, y el coste puede dispararse (render.com).

La conclusión para una plataforma soberana: self-hostear el motor de durable execution (Temporal es open source y se despliega on-prem) elimina el precio por paso del SaaS, dejando solo el overhead de ejecución —un 5–20 % que se paga de sobra con lo que ahorra en los tres vectores anteriores—. El cálculo: si un fallo a mitad de secuencia te ahorraba el 50–75 % del coste recomputado, un 5–20 % de overhead es una ganga.

Observabilidad: de post-mortem manual a trazabilidad en tiempo real

El cuarto elemento de la ecuación: la capa de observabilidad. La integración con Braintrust y el historial completo de cada ejecución (el Event History de Temporal) convierten el análisis de coste de un post-mortem manual —reconstruir a mano qué pasó y cuánto costó tras un fallo— en trazabilidad en tiempo real: cada ejecución queda registrada paso a paso, con sus tokens, sus reintentos y su coste, lista para analizar. Esto cierra el bucle de FinOps del artículo de coste por token, pero a nivel de agente: no solo cuánto cuesta un token, sino cuánto cuesta una ejecución —y dónde se desperdicia—.

La ecuación completa

Juntando las piezas, la arquitectura de coste de un agente soberano:

FastMCP + vLLM en local elimina el coste de inferencia. Temporal elimina el coste de la ejecución defectuosa. Son complementarios —atacan vectores distintos del mismo problema—. Quien resuelve solo el primero (sirve barato pero ejecuta mal) sigue sangrando por el segundo; quien resuelve solo el segundo (ejecuta robusto pero paga API) sigue sangrando por el primero. La plataforma sostenible necesita los dos.

Estado del arte y papers

El usuario pedía papers, y los hay: la fiabilidad y el coste de los agentes es un área de investigación activa en 2026.

Dos lecturas para la propuesta. Primero, el trade-off fiabilidad–coste es real y está caracterizado: no se puede maximizar acierto ignorando coste ni al revés; la durable execution desplaza la frontera al abaratar la fiabilidad (checkpoint + retry acotado en vez de recomputar). Segundo, el checkpoint-restore de agentes tiene su propia superficie de seguridad (ACRFence): persistir estado introduce riesgos de rollback que hay que controlar —la durabilidad no es solo una decisión de coste, también de seguridad—.

El ángulo soberano

Para una plataforma soberana europea, la combinación encaja perfecto y toda on-prem: vLLM sirve los modelos (sin coste de API ni soberanía cedida), FastMCP expone las herramientas, y Temporal self-hosted orquesta con durabilidad (sin precio por paso de un SaaS ni datos de ejecución saliendo a una jurisdicción ajena). El historial de ejecución —que describe en detalle qué hace tu agente y con qué datos— se queda en tu cluster, igual que las inferencias. Frente a una pila de agentes sobre APIs externas + un orquestador SaaS estadounidense, la pila soberana elimina los dos vectores de coste y mantiene el dato bajo jurisdicción UE. Es el mismo argumento del resto de la serie, aplicado a la capa de agentes: coste acotado, medido y soberano.

FastMCP y la capa de herramientas

El otro componente de la ecuación es FastMCP, la capa que expone las herramientas al agente vía MCP (Model Context Protocol). El agente no llama a las APIs directamente: llama a servidores MCP que encapsulan cada herramienta (una base de datos, un buscador, un sistema interno), con un contrato uniforme. La conexión con el coste y la durabilidad: cada llamada a una herramienta MCP es una activity de Temporal, así que hereda su retry policy, su timeout y su persistencia. Es decir, FastMCP define qué herramientas hay y Temporal gobierna cómo se ejecutan con durabilidad y coste acotado. Y al ser MCP servidores propios, las herramientas y los datos que tocan se quedan on-prem —no se exponen a un proveedor externo—. La tríada vLLM (modelo) + FastMCP (herramientas) + Temporal (orquestación) es una pila de agentes completamente soberana: el modelo, las herramientas y la ejecución, todo bajo tu control y con el coste de los dos vectores acotado.

Patrones: human-in-the-loop y secuencias largas

Dónde más brilla la durable execution, por patrón de agente:

• Human-in-the-loop (HITL): los patrones de aprobación humana —esenciales para la seguridad de un agente— mapean directamente a las primitivas suspend/resume de la durable execution, permitiendo workflows que pausan horas o días esperando una aprobación sin perder estado (Inngest). Sin durabilidad, mantener un agente “esperando” consume recursos o pierde el contexto; con ella, el workflow duerme sin coste y despierta con todo su estado.
• Secuencias largas: cuanto más larga la cadena de pasos, mayor el ahorro del checkpoint (un fallo tardío tira más trabajo). Los agentes de varios pasos con herramientas son el caso de uso canónico.
• Multi-agente: cuando varios agentes colaboran, la fiabilidad se complica (los papers de BFT lo estudian); la durable execution da el sustrato de estado consistente sobre el que construir esa coordinación.

El patrón que no la necesita: una llamada de un solo paso sin estado (un clasificador, una extracción simple). Ahí el overhead de la durabilidad no compra nada. La regla: durable execution para secuencias con estado que fallan a la mitad; para lo demás, una llamada directa.

Cómo medir el segundo vector

Para gestionar el coste de la ejecución defectuosa hay que medirlo, y con el Event History y la observabilidad (Braintrust) los KPIs están al alcance:

El último es el que cierra el círculo con el coste por token: no solo “cuánto cuesta un token”, sino “cuánto cuesta una ejecución de agente, y cuánto de eso fue trabajo útil frente a desperdicio”. Sin estos KPIs, el segundo vector es invisible —y lo invisible no se optimiza, se cancela cuando la factura sorprende—. Con ellos, el coste de cada ejecución es un dato en tiempo real, y la decisión de durabilizar (o no) cada workflow se toma con números.

Límites y trampas (data-driven)

1. La durabilidad no es gratis. 5–20 % de overhead; en SaaS con precio por paso, puede dispararse. Self-hostea Temporal para quitar ese precio.
2. No todo agente la necesita. Una tarea de un solo paso sin estado no gana nada con durable execution; el valor está en las secuencias largas que fallan a la mitad.
3. El retry acotado puede ocultar fallos reales. Un límite de reintentos evita la espiral de coste, pero hay que alertar cuando se agota, no tragarse el fallo en silencio.
4. Checkpoint = superficie de seguridad. Persistir estado abre la puerta a ataques de rollback (ACRFence); protégelo.
5. El primer vector sigue existiendo. Temporal no baja el coste de inferencia; necesitas vLLM local para eso. Son complementarios, no sustitutos.

La conclusión que sostienen los datos y los papers: el coste de la IA agéntica tiene dos vectores, y el sector se ha obsesionado con el primero (inferencia) ignorando el segundo (ejecución defectuosa) —que es justo donde Gartner sitúa la causa del 40 % de cancelaciones—. FastMCP + vLLM resuelve el primero; Temporal el segundo. Una plataforma de agentes soberana y sostenible necesita atacar los dos, con observabilidad que convierta el coste de cada ejecución en un dato en tiempo real, no en una autopsia.

Cierre

El relato dominante sobre el coste de los agentes está medio cojo: trata el coste de inferencia como si fuera el único, cuando es solo el que se ve en la demo. El que mata proyectos —el que Gartner mete en “costes crecientes” dentro de su 40 % de cancelaciones— es el coste de la ejecución defectuosa: los fallos que cobran doble, los retries sin techo y el contexto que se reconstruye en cada recuperación. La ingeniería que lo ataca no es un truco de prompt ni un modelo mejor, es un modelo de ejecución: la durable execution, que checkpointea cada paso, acota cada reintento y pasa solo el contexto necesario. Temporal —open source, self-hosted— lo hace manteniendo el estado en tu cluster, y combinado con vLLM (modelo) y FastMCP (herramientas) compone una pila de agentes completamente soberana donde los dos vectores de coste están acotados y el dato no sale de la UE. El estado del arte y los papers confirman que el problema es real y caracterizable —el trade-off fiabilidad-coste, el rate-limiting como peor fallo, el checkpoint-restore como nueva superficie de seguridad—. Para quien quiera estar en el 60 % de proyectos agénticos que no se cancelan, la receta es la de este artículo: resolver los dos vectores, no uno, y medir el segundo con la misma seriedad que el primero.

Fuentes

• Gartner · más del 40 % de proyectos de IA agéntica cancelados antes de 2027 — https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
• Temporal · durable execution — https://temporal.io/
• CallSphere · Temporal para workflows de agentes (Event History, replay) — https://callsphere.ai/blog/temporal-ai-agent-workflows-durable-execution-workflow-as-code
• Inngest · durable execution, clave para agentes en producción — https://www.inngest.com/blog/durable-execution-key-to-harnessing-ai-agents
• render.com · plataformas de workflow durables para agentes/LLM (overhead, precio por paso) — https://render.com/articles/durable-workflow-platforms-ai-agents-llm-workloads
• ReliabilityBench (arXiv 2601.06112) — https://arxiv.org/abs/2601.06112
• Cost-Efficient LLM Agents (arXiv 2603.01548) — https://arxiv.org/pdf/2603.01548
• Byzantine Fault Tolerance multi-agente (arXiv 2511.10400) — https://arxiv.org/abs/2511.10400
• ACRFence · checkpoint-restore de agentes (arXiv 2603.20625) — https://arxiv.org/pdf/2603.20625
• The Six Sigma Agent (arXiv 2601.22290) — https://arxiv.org/html/2601.22290