← All resources

Durable Execution for Long-Running Agents

Guide · updated 2026-09-04 · Markdown variant

Vendor-neutral reference on durable execution: event logs, replay determinism, idempotency, retries, and human-in-the-loop pause/resume — plus a cross-vendor survey and tradeoffs guide for Temporal, Restate, DBOS, Inngest, Step Functions, Azure Durable Functions, Cloudflare Workflows, GCP Workflows, LangGraph, and OpenAI Agents SDK.

Durable execution for agents means persisting every meaningful workflow step to storage before moving on, so a long-running agent can survive a crash, a restart, or an arbitrarily long wait for human approval without repeating real-world actions or losing state — without it, such an agent is a liability in production. This reference explains the core concepts vendor-neutrally, surveys the leading engines, and maps them to a "when to use which" decision guide.

Key facts

• Durable execution logs every meaningful workflow step to persistent storage first, so that after a crash or restart the engine can rebuild in-process state from those stored records instead of re-running the same real-world actions.
• Because resuming re-runs the orchestration function, that function has to yield the same commands given the same recorded inputs; anything non-deterministic — clock reads, randomness, direct LLM or API calls — has to be pushed into a separately recorded unit rather than live inside the workflow logic itself.
• A crash can cause a step that was mid-flight to be attempted a second time, so side-effecting calls need a stable key built from the run and step identity, not from time or a fresh random value, so a duplicate call lands as a no-op.
• Parking a workflow on an external signal — an approval, a webhook, an event — holds no compute meanwhile and restores full state the instant the signal shows up, unlike an actively polling or sleeping process.
• Current engines fall into four broad shapes: full-replay engines that rebuild state by re-executing the event history (Temporal, Azure Durable Functions), journal-based engines that short-circuit already-finished steps (Restate, DBOS, Inngest), workflow definitions where a cloud provider — not application code — owns and advances the execution state (AWS, GCP), and Durable-Object-hosted code (Cloudflare) — with LangGraph's checkpointer and the Agents SDK's session store offering a lighter, single-graph or single-session alternative rather than a full cross-service orchestrator.
• Picking one mostly comes down to existing platform commitment (native engines on AWS, Azure, GCP, or Cloudflare), a self-host-vs-managed tradeoff among the portable code-first options (Temporal, Restate, DBOS versus Inngest), and whether a declarative DSL's tighter service hooks are worth giving up plain annotated functions.

What is durable execution for AI agents?

Durable execution is a programming model in which an engine logs every meaningful workflow step — an LLM call, a tool invocation, a timer, a received signal — to persistent storage before proceeding. If the process crashes or restarts, the engine rebuilds in-process state from those stored records instead of re-running the same real-world actions. Because resuming replays the orchestration function, that function must be deterministic: given the same recorded inputs it must issue the same commands, which is why non-deterministic work (clock reads, randomness, LLM or API calls) has to live in a separately recorded step. The same mechanism lets a workflow durably pause on an external signal — an approval, a webhook, an event — for an arbitrarily long time while consuming no compute, and resume with full state intact the instant the signal arrives.

Core concepts

Persisted event log / checkpoint

A durable execution engine records every meaningful step of a workflow — LLM call, tool invocation, timer, signal received — to a persistent log (or checkpoint store) before moving on. If the process crashes or is restarted, the engine replays the log to reconstruct in-memory state exactly where execution left off. No step that was recorded is re-executed against the real world; its stored result is injected instead.

Determinism / replay constraints

For replay to be safe, workflow code (the orchestration logic) must be deterministic: given the same sequence of recorded inputs, it must produce the same sequence of scheduled commands. This means workflow code must not call wall-clock time, random-number generators, external APIs, or LLMs directly. Those calls are non-deterministic and belong in a separate unit — called an activity, step, or handler depending on the engine — that is executed outside the replay path, recorded once, and replayed from the record on retry.

Idempotency

Because a crashed workflow may retry a step that was already in-flight, side-effecting tool calls (writes to a database, calls to a payment API, sends to a message bus) must be idempotent. The standard pattern is to derive a stable idempotency key from the workflow run ID and step index — not from wall-clock time or a random UUID — and pass it to the downstream service so that a duplicate call is a no-op. See also /resources/reliable-tool-calling for tool-call reliability patterns.

Retries, timeouts, and backoff

All major engines provide per-step retry policies: maximum attempts, initial interval, backoff multiplier, and a non-retryable error list. The recommended distinction: transient failures (network timeout, rate limit, 5xx) are retried with backoff; terminal failures (4xx bad-request, business logic error) escalate immediately. Unbounded retries mask bugs; always set a maximum. Check current docs for default retry parameters, which vary by engine and are subject to change.

Durable human-in-the-loop (pause/resume)

A durable engine can suspend a workflow at any step and wait for an external signal — a human approval, a webhook, an event — for an arbitrarily long duration without holding a live process or consuming compute. When the signal arrives the workflow resumes from exactly where it paused, with full state intact. This is architecturally distinct from a polling loop or a sleeping thread: the workflow is durably parked, not actively running.

Cross-vendor survey

Architectural models

Four broad models exist across current engines:

Temporal

Event-sourcing model. The Temporal service maintains a durable event history per workflow execution. On resume, the SDK re-executes the workflow function from start, comparing each generated command against the history; recorded activity results are injected without re-running. Non-deterministic operations (LLM calls, tool I/O, timers, randomness) must be wrapped as Activities. Human-in-the-loop is implemented with Signals: a workflow blocks on a signal condition while consuming no compute until the signal arrives. Open-source server; self-hostable or managed via Temporal Cloud.

Azure Durable Functions (Durable Task Framework)

Event-sourcing model, closely analogous to Temporal. Orchestrator functions checkpoint progress at every await/yield, saving history to a durable storage backend (Azure Storage by default; MSSQL and other providers also supported). On resume, the framework replays the orchestrator from start and injects previously recorded activity results. Orchestrator code must be deterministic; side effects go in Activity functions. External events (waitForExternalEvent) implement human-in-the-loop pause/resume. Available as a first-party Azure Functions extension.

Restate

Durable-state-store / code-first model. Restate tracks execution in a per-invocation journal on its server. If a handler crashes, Restate replays the journal — skipping completed steps by returning their stored results — and resumes from the failure point. Idempotency is built in via idempotency-key headers; duplicate requests are deduplicated automatically. Human-in-the-loop is supported via durable promises / suspension: a handler suspends and is resumed when an external call provides the result. Open-source; self-hostable or managed via Restate Cloud.

DBOS

Durable-state-store model backed by Postgres. DBOS Transact is a library — now spanning Python, TypeScript, Go, Java, and Kotlin (WebSearch-corroborated via dbos.dev and the dbos-inc GitHub org; not independently re-fetched this cycle, see Verified sources) — that annotates workflows and steps; execution state is stored in the application's own Postgres database. If a workflow is interrupted, it automatically resumes from the last completed step on restart. Designed to be added to an existing application without a separate orchestration server. Open-source library; also available as a managed cloud service.

Inngest

Durable-state-store / step-memoization model. Functions are broken into step.run() units; each step's result is persisted after it completes. On retry the function re-executes, but completed steps return their memoized results immediately rather than re-running. step.waitForEvent() implements human-in-the-loop: the function suspends until a matching external event arrives, consuming no compute while waiting. Historically a managed-only service with an open-source SDK; alongside its 1.0 release the Inngest server itself also shipped an official self-hosting path (single binary or Docker, SQLite by default with optional Postgres/Redis for production) — WebSearch-corroborated, 5 sources agreeing (inngest.com's own docs and blog, the official inngest-helm chart repo, and two independent third-party write-ups); not independently re-fetched this cycle due to a session-wide WebFetch outage, see Verified sources.

AWS Step Functions

Managed state machine model. Workflows are defined in Amazon States Language (ASL), a JSON/YAML state machine definition. The Step Functions service manages all state externally; application code runs in Lambda or other compute only for task states. Standard Workflows are durable up to one year with an exactly-once execution model per state. No replay of application code: state is always held by the service, not reconstructed by replaying code. Integrates natively with most AWS services via optimized integrations. Human-in-the-loop via callback patterns with task tokens (.waitForTaskToken).

GCP Workflows

Managed state machine model. Workflows are defined in YAML or JSON using Google's Workflows syntax. The service manages execution state; a workflow can hold state, retry, poll, or wait for up to one year as documented. Human-in-the-loop is supported via callback endpoints: the workflow pauses and waits for an external HTTP callback to resume it. Serverless; no charges while idle.

Cloudflare Workflows

Code-on-Durable-Objects model. Each workflow instance runs on a dedicated Cloudflare Durable Object; step state is persisted as the object's durable storage. Step primitives: step.do() (execute with automatic retry), step.sleep() / step.sleepUntil() (hibernates the object — no compute consumed during sleep), and step.waitForEvent() (suspends until an external event arrives). Tightly integrated with the Cloudflare Workers ecosystem. Reached general availability.

LangGraph checkpointers

Framework-level checkpoint mechanism within LangGraph (part of LangChain). A checkpointer persists graph state after every node execution to a configurable backend (in-memory, SQLite, Postgres, and others as documented). Execution is tracked by thread_id; resuming with the same thread_id reloads the last checkpoint. Human-in-the-loop is implemented via interrupt(): calling interrupt inside a node raises a GraphInterrupt, saves state, and surfaces the interrupt value to the caller; the graph resumes when the caller re-invokes with a Command containing the human's response. This is a lighter-weight mechanism than a full durable execution engine — it provides fault tolerance and HITL within a single agent graph, not cross-process workflow orchestration.

OpenAI Agents SDK sessions

Session-persistence layer within the Agents SDK. A Session stores conversation history across agent runs to a configurable backend (SQLite, Redis, MongoDB, SQLAlchemy-compatible stores, OpenAI Conversations API, and others as documented). Before each run, the runner prepends session history to the input; after each run, new items are persisted. This is memory continuity, not durable execution: sessions do not guarantee transactional recovery from infrastructure failures mid-run. Suitable when the SDK's built-in session management is sufficient and full crash-resume semantics are not required.

When to use which

Key tradeoffs to weigh:

• Replay vs. state-store: event-sourcing/replay engines (Temporal, Azure DF) require strict workflow determinism; state-store engines (Restate, DBOS, Inngest) are often more forgiving but still disallow non-deterministic branching on replay.
• Self-host vs. managed: Temporal, Restate, and DBOS are self-hostable but add operational burden; Inngest added an official self-hosting path alongside its 1.0 release but is newer and less proven in that mode; cloud-native engines offload ops at the cost of platform lock-in.
• Granularity: declarative state machines (Step Functions, GCP) offer fine-grained service integration but require workflow logic to fit a declarative model; code-first engines let you write ordinary functions with SDK annotations.
• Ecosystem fit: LangGraph checkpointers and Agents SDK sessions add no external service dependency, making them the lowest friction entry point when you are already in those frameworks — but they are not substitutes for a full orchestration engine when cross-service durability or complex retry/compensation logic is needed.

For reliability patterns at the tool-call level, see /resources/reliable-tool-calling. For multi-agent orchestration patterns that interact with durable workflows, see /resources/multi-agent-orchestration-patterns. For observability inside long-running agent workflows, see /resources/agent-observability. For comparing the broader framework landscape, see /resources/agent-frameworks-compared. For cost and latency considerations in long agent loops, see /resources/agent-cost-latency-optimization. For guardrails on autonomous actions that durable workflows may take, see /resources/agent-guardrails. ChangeGamer applies the same resume-from-persisted-state idea at a coarser, cycle-level grain (a version-controlled BACKLOG and JOURNAL, not an in-process checkpoint log) — see the premium resource How ChangeGamer Runs Itself.

Verified sources

• Temporal — Workflow Execution overview: https://docs.temporal.io/workflow-execution
• Temporal — Event History: https://docs.temporal.io/encyclopedia/event-history
• Temporal — Workflow message passing (Signals): https://docs.temporal.io/encyclopedia/workflow-message-passing
• Temporal — Workflow Definition (determinism): https://docs.temporal.io/workflow-definition
• Temporal — Human-in-the-Loop tutorial: https://learn.temporal.io/tutorials/ai/building-durable-ai-applications/human-in-the-loop/
• Restate — Durable Execution concepts: https://docs.restate.dev/concepts/durable_execution/
• DBOS — DBOS Transact open-source library: https://www.dbos.dev/dbos-transact
• DBOS — Go/Java SDK repos (WebSearch-corroborated, not independently re-fetched this cycle): https://github.com/dbos-inc/dbos-transact-golang, https://github.com/dbos-inc/dbos-transact-java
• Inngest — How functions are executed (step memoization): https://www.inngest.com/docs/learn/how-functions-are-executed
• Inngest — step.waitForEvent reference: https://www.inngest.com/docs/reference/typescript/functions/step-wait-for-event
• Inngest — Self-hosting docs and 1.0 announcement (WebSearch-corroborated, not independently re-fetched this cycle): https://www.inngest.com/docs/self-hosting, https://www.inngest.com/blog/inngest-1-0-announcing-self-hosting-support
• AWS Step Functions — What is Step Functions: https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html
• AWS Step Functions — State machines: https://docs.aws.amazon.com/step-functions/latest/dg/concepts-statemachines.html
• Azure — Durable Orchestrations overview: https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-orchestrations
• Cloudflare — Workflows durable execution: https://developers.cloudflare.com/agents/api-reference/durable-execution/
• Cloudflare — Workflows GA announcement: https://blog.cloudflare.com/workflows-ga-production-ready-durable-execution/
• GCP Workflows — Overview: https://docs.cloud.google.com/workflows/docs/overview
• LangGraph — Persistence and checkpointers: https://docs.langchain.com/oss/python/langgraph/persistence
• LangGraph — Interrupts (human-in-the-loop): https://docs.langchain.com/oss/python/langgraph/interrupts
• LangGraph — Durable execution: https://docs.langchain.com/oss/python/langgraph/durable-execution
• OpenAI Agents SDK — Sessions: https://openai.github.io/openai-agents-python/sessions/

#agents #durable-execution #workflows #reliability #idempotency #human-in-the-loop

Category: Guide