Durable Execution for AI Agents: Temporal vs Restate vs Inngest (2026)
Temporal raised a $300 million Series D at a $5 billion valuation in February 2026, led by Andreessen Horowitz, on a single explicit thesis: durable execution is the layer that makes AI agents production-ready (Temporal, 2026). Seven months later it raised again: a $550 million Series E at $12.55 billion, led by Lightspeed (Temporal, 2026). Valuations don’t more than double in seven months because workflows are exciting. They do it because every AI team trying to ship a real agent has hit the same wall.
The wall looks like this. You build an agent in LangGraph. It works in your demo. Then you run it for real. Twelve hours, fifty tool calls, a model-provider rate limit, a Redis hiccup, a deploy in the middle, and you watch it die and realize you have no way to resume it from where it crashed. That’s not a LangGraph bug. It’s the gap between graph state and durable execution, and it’s why a generation of agent teams is migrating to Temporal, Restate, and Inngest right now.
This piece breaks down what durable execution actually means for agents, how the three serious contenders differ on the things that matter (durability guarantees, idempotency primitives, replay semantics, human-in-the-loop), and which one you should pick.
Key Takeaways
- IDC research with Lenovo found 88% of AI proofs of concept never reach widescale deployment: for every 33 POCs, only four graduated to production (CIO, 2025).
- Durable execution treats every tool call as a side effect with an idempotency key and a replay log, so agents survive crashes, deploys, and retries.
- Temporal is the heavyweight: 1.9 trillion-plus Cloud actions in August 2026 alone, 4,300+ paying customers including OpenAI, and integrations with OpenAI, Pydantic, and Vercel. Best for serious scale.
- Restate is the lightweight log-based alternative: invocation idempotency keys, HTTP/Lambda-friendly, SOC 2 + HIPAA on Restate Cloud since February 2026, flow control for LLM concurrency in 1.7, and a $20M Series A in September 2026.
- Inngest’s Durable Endpoints (February 2026) bring step-level durability to existing Next.js and Bun handlers, the lowest-friction option if you’re already serverless.
primer on how AI agents plan, reason, and call tools autonomously
What Is Durable Execution and Why Do AI Agents Need It?
Datadog’s State of AI Engineering report found that in February 2026, 5% of all LLM call spans returned an error and 60% of those errors were exceeded rate limits; in March, rate limits caused almost a third of errors, nearly 8.4 million rate-limit errors in total (Datadog, 2026). Durable execution is the discipline of writing code that survives those failures without manual intervention. It treats every external call as a side effect that gets logged, retried, and resumed from exactly where it broke.
The mental model is simple. You write a workflow. The runtime records every step it takes, every LLM call, every tool invocation, every database write, into an append-only log. If the process crashes, deploys mid-flight, or hits a network partition, the runtime replays the log on a different worker and picks up at the first step that hadn’t completed. The agent doesn’t know it died. It just keeps running.
That guarantee changes what you can build. A “research agent” that takes ninety seconds is a different category of software from one that runs for twelve hours, calls forty tools, pauses for a human to approve a refund, and resumes the next morning. Without durable execution you cannot build the second kind. Period.
The reason this is suddenly urgent is that agent workloads have flipped. Agentic framework adoption nearly doubled in a year, from just over 9% of organizations in early 2025 to almost 18% by the start of 2026 (Datadog, 2026). Most agents are still simple: Datadog found 59% of agentic requests made a single service call. But the 18% that made three or more are exactly the long, stateful, tool-heavy runs where crashes hurt. The orchestration layer can’t be an afterthought for those.
For the request-hardening primitives that durable runtimes build on top of, see idempotency keys, dedup stores, and atomic claim wrappers.
Why Is LangGraph State Failing in Production?
LangGraph 1.0 shipped in October 2025 with durable state as a headline feature (LangChain, 2025), and the 1.x line has kept moving (1.2 landed in May 2026). It’s a real framework with real production users. But “checkpointed graph state” and “durable execution” are not the same thing, and the gap is exactly where production agents fall over.
Here’s the difference. LangGraph persists graph state to a checkpointer (Postgres, Redis, or your own backend) at node boundaries. If a node fails, you can reload the state and re-enter the graph. That works fine for short, deterministic flows. It breaks down when you have side-effecting tool calls inside a node, parallel fan-out across many tools, or runs that span hours and survive deploys. There is no native idempotency primitive for tool calls. There is no deterministic replay of arbitrary code. Retries get hand-rolled at the workflow level, and “where exactly did we leave off?” becomes an operational question your team answers in Slack at 2am.
Grid Dynamics ran into this in production. Their team built a deep-research agent for a Fortune 500 manufacturer with more than 100 plants, originally on LangGraph. They hit Redis state fragility, hand-rolled retry logic, and an operational footprint that grew faster than the agent itself. They migrated the same agent to Temporal and reframed the problem: instead of treating state “as a separate, fragile object,” Temporal let them “make state an integral part of the workflow itself” (Temporal, 2025).
Our take: LangGraph is fine for prototypes and short, single-process agents. The moment your agent needs to survive a deploy, retry tool calls without duplicating side effects, or pause for a human and resume tomorrow, you’re in durable-execution territory and LangGraph isn’t the right tool.
how multi-agent systems coordinate parallel work in production
How Does Temporal Solve Long-Running Agent Workflows?
At its February 2026 Series D, Temporal reported 9.1 trillion lifetime action executions on Temporal Cloud, 1.86 trillion of them for AI-native companies, with OpenAI, Replit, Lovable, Abridge, and ADP named as agent users; revenue had grown more than 380% year over year and weekly active usage 350% (Temporal, 2026). By the September Series E, Temporal Cloud was processing more than 1.9 trillion actions in a single month (August), up over 350% year over year, for 4,300+ paying customers (Temporal, 2026). The thing AI teams keep buying isn’t the framework, it’s the durability guarantee.
Temporal’s model is event-sourced. You write a workflow function. The runtime records every action, every activity call, timer, signal, and child workflow, into an immutable history. When the worker crashes, a different worker replays the history deterministically up to the last completed step and continues from there. Activities (your side effects, including LLM calls and tool invocations) get retried automatically with configurable backoff, and each one carries an idempotency identity so you don’t double-charge a customer because the second retry succeeded after the first one’s response got lost.
Here’s the rough shape of an agent loop in Temporal Python:
from temporalio import workflow, activity
from temporalio.common import RetryPolicy
from datetime import timedelta
@activity.defn
async def call_llm(prompt: str) -> dict:
return await openai_client.responses.create(model="gpt-6.1-sol", input=prompt)
@activity.defn
async def run_tool(name: str, args: dict) -> dict:
return await tool_registry[name](**args)
@workflow.defn
class ResearchAgent:
@workflow.run
async def run(self, brief: str) -> str:
history = [{"role": "user", "content": brief}]
for _ in range(50):
decision = await workflow.execute_activity(
call_llm, history,
start_to_close_timeout=timedelta(minutes=2),
retry_policy=RetryPolicy(maximum_attempts=5),
)
if decision["stop"]:
return decision["answer"]
tool_result = await workflow.execute_activity(
run_tool, decision["tool"], decision["args"],
start_to_close_timeout=timedelta(minutes=10),
retry_policy=RetryPolicy(maximum_attempts=3),
)
history.append({"role": "tool", "content": tool_result})
The interesting parts aren’t visible. The for loop can run for hours. If the worker process dies on iteration 23, a different worker picks it up at iteration 23 with the full conversation history reconstructed from the event log. The retry policies aren’t application code; they’re enforced by the runtime. Signals, Temporal’s name for external events, let you pause the loop on a “needs human approval” interrupt and resume when an operator clicks a button in your dashboard, even if that button click happens four hours later.
Temporal Nexus, which went GA in March 2025, lets one workflow call into another team’s workflow across services without sharing a database, which matters when your agent needs to call into an existing payment or document-processing workflow (Temporal, 2025). Temporal Cloud also sells 99.99% high-availability options with multi-region replication, so a regional outage doesn’t have to take your agents down (Temporal). And Temporal lists framework integrations with OpenAI, Pydantic, and Vercel, so the OpenAI Agents SDK and Pydantic AI plug in without a rewrite.
Tool calls now look exactly like other production side effects: each one needs idempotency, retries, and a place in a replay log. Temporal’s $12.55B valuation rests on the bet that this convergence is permanent (Temporal, 2026).
The cost is operational weight. Temporal Cloud is pay-as-you-go from $50 per million actions (dropping to $25 per million with volume), plus support billed at 10% of usage (Temporal). Self-hosted Temporal needs a persistence cluster (Cassandra, PostgreSQL, or MySQL), often with Elasticsearch for advanced visibility. You don’t reach for it for a 200-line script.
What Makes Restate’s Approach Different?
Restate 1.6 shipped in February 2026 with pause-and-resume for invocations, simpler multi-cloud operation, and less tuning, and Restate Cloud added SOC 2, enterprise SSO, HIPAA support, and client-side journal encryption the next day (Restate, 2026). Restate 1.7 followed in July with flow-control primitives, starting with concurrency limits per scope, which is exactly what you want when every concurrent agent invocation is real model spend (Restate, 2026). Then in September it raised a $20M Series A led by Singular (Restate, 2026). The pitch is durable execution as a lightweight runtime: a single Rust binary, log-based journal replay, native invocation-level idempotency keys, and HTTP/Lambda-friendly handlers. If Temporal is Kafka, Restate is more like NATS.
The model differs from Temporal in two ways that matter for agents. First, every invocation gets an idempotency key as a first-class HTTP header, idempotency-key: <uuid>, and Restate dedups at the runtime level, not at your application layer. That’s exactly the primitive AI agent tool calls need, because tool calls are basically RPCs to flaky external services.
Second, Restate uses a journal per invocation rather than a global event-sourced history. Each handler writes deterministic journal entries for the side effects it performs, and on failure the runtime replays the journal to reconstruct the local state. Awakeables, Restate’s name for HITL interrupts, let a handler suspend on a promise that gets resolved by an external HTTP callback, durably, with no polling.
Here’s a sketch of an agent step using the Restate TypeScript SDK:
import * as restate from "@restatedev/restate-sdk";
const agent = restate.service({
name: "ResearchAgent",
handlers: {
runStep: async (ctx: restate.Context, input: AgentInput) => {
const decision = await ctx.run("llm", () =>
callLLM(input.history)
);
if (decision.stop) return decision.answer;
const toolResult = await ctx.run("tool", () =>
runTool(decision.tool, decision.args)
);
const approval = await ctx.awakeable<boolean>();
ctx.run("notify", () => notifyHuman(approval.id, toolResult));
const approved = await approval.promise;
return approved ? toolResult : "rejected";
},
},
});
Each ctx.run call is journaled. If the process crashes between ctx.run("llm", ...) and ctx.run("tool", ...), the next replay sees the LLM result already in the journal and skips re-running it. The awakeable survives across deploys, an operator who approves the action three days later still resumes the same agent invocation. Thoughtworks has Restate in Assess on its Tech Radar (April 2025), noting a team was assessing it in a large insurance system and was “quite happy with its performance so far” (Thoughtworks, 2025). The licensing caveat is mine: the Restate server is under the Business Source License 1.1, which bars offering it as a public Restate platform service and converts each version to Apache 2.0 four years after release (Restate LICENSE).
Restate’s 2026 blog cadence is almost entirely AI-focused: Google ADK integration on January 12, OpenAI Agents SDK on January 15, Pydantic AI on April 2, Langfuse observability on April 9. They are racing the same use case Temporal is, with a smaller footprint as the wedge.
why prompt caching matters when agents make repeated calls under retries
Where Does Inngest Fit in the Stack?
Inngest shipped Durable Endpoints to public beta on February 10, 2026, letting Next.js and Bun developers wrap any HTTP handler with inngest.endpoint() and break it into retriable step.run calls without leaving their existing app (Inngest, 2026). This is the lowest-friction path to durability of the three: no separate worker fleet, no event store to operate, no SDK rewrite.
The model is step-level. You wrap each side effect in step.run("name", () => ...) and Inngest stores the result. If the function reruns, because of a crash, a deploy, or a scheduled retry, already-completed steps short-circuit and return their cached result, while incomplete steps execute. It’s coarser than Temporal’s event-sourced replay and lighter than Restate’s journal, but for the majority of agents that are an LLM loop with a handful of tool calls, it’s enough.
import { Inngest } from "inngest";
const inngest = new Inngest({ id: "agent" });
export const researchAgent = inngest.createFunction(
{ id: "research-agent" },
{ event: "agent/research.requested" },
async ({ event, step }) => {
let history = [{ role: "user", content: event.data.brief }];
for (let i = 0; i < 50; i++) {
const decision = await step.run(`llm-${i}`, () => callLLM(history));
if (decision.stop) return decision.answer;
const toolResult = await step.run(`tool-${i}`, () =>
runTool(decision.tool, decision.args)
);
history.push({ role: "tool", content: toolResult });
}
}
);
Inngest’s strength is operational simplicity and integration breadth. It runs against your existing Vercel or Netlify deploy, supports schedules and cron natively, and the Agent Skills release on February 18, 2026 shipped six pre-built skills for coding agents like Claude Code, Cursor, and Windsurf (Inngest, 2026). Since then the changelog has leaned hard into AI observability: LLM-as-a-judge scoring in June and an AI Overview dashboard for model calls, cost, and latency in August. Pricing starts with a free tier of 50,000 executions a month, and Pro starts at $99 a month for 1 million (Inngest).
The trade-offs are real. Self-hosting is supported (there’s an official Helm chart), but the server is source-available rather than permissively licensed, and the managed Cloud is where most of the newer features land first. Each step also executes inside your own platform’s request limits, so a single long-running step on a serverless host is bounded by that host’s function timeout, even though the overall function can sleep and resume for much longer. For most product teams that’s fine. For an autonomous research agent with steps that crunch for hours, it isn’t.
How Do the Four Stack Up Side by Side?
Datadog’s traces show how often the ground shifts under an agent: 5% of LLM call spans errored in February 2026, and rate limits caused 60% of those errors; in March the error rate fell to 2%, but rate limits still produced nearly 8.4 million errors (Datadog, 2026). The remaining errors were other 4xx responses, provider and gateway 5xx failures, and miscellaneous issues. Every one of those failures is something your runtime has to handle without losing the agent’s state. Here’s how the four contenders actually compare on the primitives that matter.
The capability matrix below condenses what the docs and production users say. Use it as a starting point, not gospel, every team’s constraints differ.
| Capability | LangGraph 1.2 | Temporal | Restate 1.7 | Inngest |
|---|---|---|---|---|
| Durability model | Checkpointed state (Postgres/Redis) | Event-sourced workflow history | Per-invocation log/journal | Step-level event log |
| Tool-call idempotency | Hand-rolled by the user | Activity identity + retry policy | Native invocation idempotency keys | step.run(id, fn) cache |
| Replay semantics | Resume from last checkpoint | Deterministic replay from history | Journal replay | Step-level short-circuit |
| Human-in-the-loop | interrupt() primitive (1.0+) |
Signals + Updates | Awakeables | waitForEvent |
| Long runs (12h+) | Possible, fragile under deploys | Native (years supported) | Native | Yes, but each step bound by host timeout |
| Multi-region | Not built-in | Cloud HA options (99.99%) | Self-host or Cloud | Cloud-managed |
| Self-host license | MIT | MIT | BSL 1.1 → Apache 2.0 after 4 years | Source-available |
| Operational footprint | Framework + your DB | Cluster (DB + optional Elasticsearch) | Single Rust binary | Cloud-managed (or self-hosted via Helm) |
What I’ve seen on real teams: the choice usually comes down to three questions. Are you already on a Temporal-class workflow engine for non-AI workloads? Do you need to self-host for compliance? And how long do your agents actually run? Most teams overestimate the third, they pick Temporal for “future-proofing” and then operate a cluster for an agent that runs for ninety seconds.
why rate limits dominate LLM error budgets and how to design around them
Which Engine Should You Choose?
Gartner predicts 40% of enterprise apps will feature task-specific AI agents by 2026, up from less than 5% in 2025 (Gartner, 2025). That growth pulls in a wide range of teams with different operational maturity, and the right engine depends on which slot you’re in.
Pick Temporal if you have an SRE function, your agent workload is core revenue (not a side feature), you expect runs longer than a day, you need multi-region, or you’re already integrating with the OpenAI Agents SDK or Pydantic AI in production. The customers Temporal names for agent workloads, OpenAI, Replit, Lovable, Abridge, are not picking it casually.
Pick Restate if you want durable execution semantics without operating a Cassandra cluster, you need invocation idempotency at the HTTP layer, you have compliance requirements (SOC 2, HIPAA) and prefer a managed Cloud, or your agents fit a request-driven HTTP/Lambda shape. The BSL licensing is the main thing to check with your legal team before you commit.
Pick Inngest if your agent lives inside an existing Next.js, Bun, or serverless app, you don’t have an infra team, your runs fit comfortably under your plan’s timeout, and you want step-level durability with the smallest possible blast radius. Durable Endpoints (Feb 10, 2026) collapse the on-ramp to a single import.
Stay on LangGraph if your agent runs inside one process, completes within a few minutes, doesn’t need to survive deploys mid-run, and your tool calls are read-only or trivially safe to retry. That’s a real category of agent: chat assistants, single-turn research, classification pipelines. Durable execution is overkill there.
The thing to avoid is building a fragile orchestration layer on top of LangGraph because you assume durable execution is something you can swap in later. In my experience, migrating an agent codebase from “checkpointer plus our retry helpers” to a durable runtime takes weeks, and the bill compounds with every additional tool. Pick the right tier early.
What’s Next for Durable Execution and AI Agents?
Temporal’s own Series E announcement says it plainly: as companies race to adopt agentic AI, “most efforts stall at the pilot stage” (Temporal, 2026). The story of the next year is how much of that gap closes, and the runtimes are converging on a shared set of primitives that suggest it can close fast.
Three convergence trends matter. First, idempotency keys are becoming the default API contract for tool calls, not an afterthought; both Restate and Temporal expose them as first-class, and the OpenAI Agents SDK and Pydantic AI now plug into them directly. Second, human-in-the-loop is moving from “polling for approval” to a true interrupt primitive: Temporal Signals, Restate Awakeables, Inngest waitForEvent are different names for the same idea. Third, multi-region is becoming table stakes for any agent backing customer-facing flows, which favors the runtimes with mature replication.
The interesting open question is whether LangGraph, LlamaIndex, and the next generation of agent frameworks ride on top of these runtimes (Temporal-compatible activities) or compete with them at the orchestration layer. Bet on the first. The framework layer wants to focus on prompts, memory, and tool catalogs; the runtime layer wants to handle replay, idempotency, and HITL. Those are different jobs, and the teams shipping production agents in 2026 already separate them.
how solo founders pick the right agent stack without an infrastructure team
Frequently Asked Questions
Is durable execution overkill for a simple AI chatbot?
Probably yes. If your agent is a single LLM call wrapped in a router, finishes in seconds, and doesn’t take side-effecting tool actions, durable execution adds operational weight you don’t need. The threshold is when you have multi-step tool calls with side effects, runs that must survive a deploy, or human approvals. Datadog found only 18% of agentic application requests make three or more service calls, while 59% make just one (Datadog, 2026).
Can I migrate from LangGraph to Temporal incrementally?
Yes, and Grid Dynamics is the public template for it. Wrap each LangGraph node as a Temporal activity, move the loop into a Temporal workflow, and migrate state from your checkpointer into workflow inputs. The Grid Dynamics team did this for a deep-research agent and reported that “state became an integral part of the workflow itself rather than a separate, fragile object” (Temporal, 2025).
How does idempotency work for non-deterministic LLM calls?
The retry doesn’t have to produce the same answer, it just has to not produce duplicate side effects. Durable runtimes record the result of the first successful LLM call (or tool invocation) in their event log. On replay, the runtime returns the cached result instead of calling the LLM again. The same pattern that powers idempotency keys for webhook handlers applies to AI tool calls.
What’s the cost difference between self-hosted and managed?
Temporal Cloud starts at $50 per million actions with no base fee; Restate Cloud bills per durable action with a free tier of 100,000 actions a month; Inngest bills per execution, free up to 50,000 a month and $99 a month for Pro (Temporal, Restate, Inngest). Self-hosted Temporal needs a database cluster (often plus Elasticsearch) and at least one engineer who knows it. For most teams shipping AI agents in 2026, managed wins on total cost of ownership until your action volume crosses into millions per day.
Does durable execution slow down my agent?
There’s a small overhead per recorded step (a network round-trip to the runtime), but it’s dwarfed by LLM call latency. The bigger consideration is throughput, high-fanout agents that call thousands of tools in parallel can saturate the runtime. Temporal Cloud documents per-namespace rate limits, and Restate 1.7’s concurrency rules let you cap fan-out deliberately instead of discovering the ceiling in production.
Wrapping Up
The migration off in-memory graph state and onto durable runtimes isn’t speculative, it’s already happening, and the funding flows confirm it. Temporal at $12.55B, Restate raising a Series A after adding HIPAA and flow control, Inngest collapsing the on-ramp to one import. The teams shipping production AI agents in 2026 have stopped treating orchestration as a framework concern and started treating it as a runtime concern, the same way payment systems stopped treating idempotency as a framework concern fifteen years ago.
If you’re starting an agent project today, the cheapest mistake to make is to skip the orchestration choice for now and assume you’ll fix it later. You won’t. Pick the right tier on day one, even if your agent is small. The pattern is converging, and the cost of being on the wrong side of the convergence is weeks of migration work for every agent you ship.
For the foundation underneath durable runtimes: atomic claim wrappers, transactional dedup stores, retry semantics. Start with the idempotency key pattern for APIs and webhooks.
