---
title: "El segundo vector de coste de los agentes IA: durable execution con Temporal"
url: https://blog.lo0.es/posts/temporal-durable-execution-coste-agentes/
markdown: https://blog.lo0.es/posts/temporal-durable-execution-coste-agentes/index.md
lang: es
date: 2026-06-14
lastmod: 2026-06-14
author: "José Manuel Román"
description: "Los agentes tienen dos vectores de coste: el de inferencia (que vLLM local elimina) y el de la ejecución defectuosa (fallos que cobran doble, retries sin control, contexto inflado en recovery). Cómo la durable execution con Temporal ataca el segundo, qué dice el estado del arte y los papers, y por qué el 40% de proyectos agénticos que Gartner da por cancelados muere ahí. Con fuentes."
tags: ["agentes","temporal","durable-execution","coste-por-token","finops","fastmcp","vllm","fiabilidad","serie-datos"]
translations:
  en: https://blog.lo0.es/en/posts/second-cost-vector-ai-agents-durable-execution-temporal/index.md
---

# 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](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)).
"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:

> **Diagrama:** Los tres gastos de un agente defectuoso: fallos que cobran doble, retries sin control, y contexto inflado en recovery — [verlo en la versión HTML](https://blog.lo0.es/posts/temporal-durable-execution-coste-agentes/)

### 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](https://temporal.io/)).
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](https://callsphere.ai/blog/temporal-ai-agent-workflows-durable-execution-workflow-as-code)).
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](https://arxiv.org/abs/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:

| Escenario | Tokens recomputados por fallo | Coste por fallo | Sobre 10.000 ejecuciones (10 % fallan) |
|---|---|---|---|
| **Sin estado** (reintento completo) | 14 pasos × 3.000 = 42.000 | ~0,046 € | ~46 € desperdiciados |
| **Con checkpoint** (reanuda en el 15) | 0 (solo reintenta el 15) | ~0,003 € | ~3 € desperdiciados |

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](https://temporal.io/)). Cruzó a la "mayoría temprana" en 2025,
con ofertas de AWS, Cloudflare y Vercel, **impulsada precisamente por la infraestructura de agentes
IA** ([Inngest](https://www.inngest.com/blog/durable-execution-key-to-harnessing-ai-agents)).

> **Diagrama:** Durable execution: una secuencia de pasos checkpointeados; ante un fallo, se reanuda desde el ultimo checkpoint, no desde cero — [verlo en la versión HTML](https://blog.lo0.es/posts/temporal-durable-execution-coste-agentes/)

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](https://render.com/articles/durable-workflow-platforms-ai-agents-llm-workloads)).
Temporal destaca por su modelo *workflow-as-code* y su Event History como fuente de verdad.

| Opción | Modelo | Self-hosted | Nota para soberanía |
|---|---|---|---|
| **Temporal** | workflow-as-code, Event History | sí (open source) | el más maduro; on-prem completo |
| **Restate** | durable RPC/handlers | sí | ligero, moderno |
| **DBOS** | durable sobre Postgres | sí | estado en tu Postgres |
| **Inngest** | event-driven, steps | SaaS / self-host | foco en DX |
| **AWS Step Functions Express** | state machine | no (SaaS AWS) | atado a AWS, no soberano |
| **LangGraph checkpointer** | checkpointer del framework | sí (tu backend) | a nivel de framework, no de plataforma |

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](https://render.com/articles/durable-workflow-platforms-ai-agents-llm-workloads)).
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](https://render.com/articles/durable-workflow-platforms-ai-agents-llm-workloads)).

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:

> **Diagrama:** La ecuación: FastMCP más vLLM local elimina el coste de inferencia; Temporal elimina el coste de ejecucion defectuosa; son complementarios — [verlo en la versión HTML](https://blog.lo0.es/posts/temporal-durable-execution-coste-agentes/)

**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.

| Paper | Aporta |
|---|---|
| **ReliabilityBench** ([2601.06112](https://arxiv.org/abs/2601.06112)) | benchmark de fiabilidad de agentes: consistencia, robustez y tolerancia a fallos de herramientas/API; **el rate limiting es el fallo más dañino**; ReAct más robusto que Reflexion bajo estrés |
| **Cost-Efficient LLM Agents** ([arXiv](https://arxiv.org/pdf/2603.01548)) | el **trade-off fiabilidad–coste**: enrutar cada decisión por el LLM mejora el acierto pero dispara el coste; los grafos pre-codificados abaratan pero son frágiles ante fallos compuestos |
| **Byzantine Fault Tolerance multi-agente** ([2511.10400](https://arxiv.org/abs/2511.10400)) | consenso BFT (CP-WBFT) para estabilizar sistemas multi-agente bajo tasas de fallo extremas (85,7 %) |
| **ACRFence** ([2603.20625](https://arxiv.org/pdf/2603.20625)) | seguridad del **checkpoint-restore** de agentes: prevenir ataques de *rollback* semántico |
| **The Six Sigma Agent** ([2601.22290](https://arxiv.org/html/2601.22290)) | fiabilidad enterprise vía ejecución descompuesta dirigida por consenso |

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](https://www.inngest.com/blog/durable-execution-key-to-harnessing-ai-agents)). 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:

| KPI | Qué indica | De dónde sale |
|---|---|---|
| **Tokens desperdiciados por fallo** | el coste del vector 1 | tokens recomputados tras un fallo |
| **Reintentos por activity** | el coste del vector 2 | retry count del Event History |
| **Tamaño del contexto en recovery** | el coste del vector 3 | tokens de entrada tras una recuperación |
| **Tasa de fallo por workflow** | la frecuencia del problema | ejecuciones fallidas / totales |
| **Coste por ejecución completa** | el dato de negocio | suma de tokens × coste/token por run |

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