← All guides · Agent reliability in production

When Do AI Agents Need Durable Execution?

Part 4 of Agent reliability in production · 2,099 words · ~10 min read · published 2026-08-27 · updated 2026-08-27 · Markdown variant

A deep-dive on durable execution for AI agents: the persisted event log, the replay-determinism constraint, the four architectural shapes mapped across ten engines and frameworks, and a decision framework for when a durable execution engine is worth adding at all.

Part of the Agent Guardrails and the AI Agent Reliability Playbook guide.

The agent reliability in production pillar covers durable execution in roughly two paragraphs. This article goes deeper into the resource behind that section — durable execution for long-running agents — with the full ten-engine survey, the four architectural shapes they fall into, and a decision framework for when adding one is actually worth it.

What is durable execution for an AI agent?

Durable execution is a programming model that writes a durable record of every meaningful workflow step as it happens, so a crash or restart can rebuild state from that record instead of repeating the step out in the world a second time. The engine records each step — an LLM call, a tool invocation, a timer, a received signal — and on resume looks up its stored outcome and hands that back to the workflow rather than running it again.

This differs from a plain retry loop in one respect that matters: a retry loop protects a single attempt inside one running process, while a durable execution engine protects an entire multi-step workflow across an arbitrary number of process lifetimes, including ones that end in an unplanned crash. As of August 2026, ten engines and frameworks implement some version of this pattern, surveyed below.

Why must workflow orchestration code be deterministic?

A durable execution engine can only rebuild a workflow's state safely if the orchestration code driving it is deterministic — feed it the same recorded inputs twice and it has to schedule the identical sequence of commands both times, or the engine loses any reliable way to know where execution actually left off. This single constraint rules out four kinds of operation from living directly inside orchestration logic:

• Reading the wall clock
• Generating random numbers
• Calling an external API directly
• Calling an LLM directly

Each of these produces a different result on every invocation, which breaks the same-inputs-same-commands guarantee replay depends on. Every engine surveyed here solves it the same way despite different vocabulary: push the non-deterministic call into a separately recorded unit — an activity in Temporal, a step in Inngest and DBOS, a handler in Restate — that runs off to one side of the deterministic path, gets its outcome recorded once, and hands that same outcome back on any later resume rather than being invoked again.

A related but narrower constraint is idempotency: a crash can interrupt a step partway through its work, and resuming the workflow can then cause that same step to be attempted a second time. Building a safe key for that situation is covered in full in how to make AI agent retries idempotent; durable execution is simply the scenario that makes that key necessary in the first place.

The four architectural shapes durable execution engines take

Durable execution engines split into four distinct models as of August 2026, and the model an engine uses determines what its workflow code can and cannot do:

LangGraph's checkpointer and the OpenAI Agents SDK's session store do not fit any of these four cleanly — both operate one level down, persisting state within a single graph or session rather than orchestrating state across a distributed, cross-service workflow. Both are covered separately below.

Full-replay engines: Temporal and Azure Durable Functions

Temporal's server keeps a durable event history for each workflow execution; on resume, the SDK reruns the workflow function from the beginning, checks each generated command against that history, and injects the recorded result for anything already run instead of calling out again. Non-deterministic work must be wrapped as Activities, executed outside this replay path. Signals implement pause-and-resume: a workflow blocks on a signal condition and holds no compute until it arrives. Temporal's server is open source, self-hosted or managed via Temporal Cloud.

Azure Durable Functions (the Durable Task Framework) is closely related: an orchestrator function checkpoints at every await or yield, writing history to a durable storage backend (Azure Storage by default, with MSSQL and other providers also supported as of this writing). Resuming replays the orchestrator from the start and injects results already recorded for completed Activity functions, so side effects must live in those Activity functions, not the orchestrator itself. The waitForExternalEvent API mirrors Temporal's Signals. It ships as a first-party Azure Functions extension.

Journal-based engines: Restate, DBOS, and Inngest

Restate tracks execution in a per-invocation journal on its own server; if a handler crashes, Restate replays the journal, returns the stored result for every step already completed, and resumes only from the actual failure point. Idempotency-key headers are built into the platform, with duplicate requests deduplicated automatically. Human-in-the-loop uses durable promises: a handler suspends and resumes once an external call supplies the awaited result. Restate is open source, self-hosted or managed via Restate Cloud.

DBOS is journal-based but backed by Postgres rather than a dedicated server. DBOS Transact is a library — as of August 2026 spanning Python, TypeScript, Go, Java, and Kotlin (WebSearch-corroborated via DBOS's own docs and GitHub org, not independently re-fetched this cycle) — that annotates ordinary functions as workflows and steps, storing execution state in the application's own Postgres database. An interrupted workflow resumes automatically from its last completed step on restart. It is designed to be added to an existing application without a separate orchestration server, and is available as an open-source library or a managed cloud service.

Inngest breaks functions into step.run() units and persists each step's result once it completes; a retried function re-executes from the top, but any step already recorded returns its memoized result immediately instead of running again. step.waitForEvent() suspends the function until a matching external event arrives, consuming no compute while it waits. Inngest was historically managed-only with an open-source SDK; alongside its 1.0 release it also shipped an official self-hosting path — single binary or Docker, SQLite by default with optional Postgres or Redis for production (WebSearch-corroborated across Inngest's own docs, blog, and its Helm chart repo; not independently re-fetched this cycle) — though that self-hosting story is newer and less proven than its managed offering.

Managed state machines: AWS Step Functions and GCP Workflows

AWS Step Functions defines a workflow in Amazon States Language, a JSON or YAML state machine the service manages and advances externally; application code only runs inside individual task states, typically as Lambda functions. Standard Workflows stay durable for up to one year with an exactly-once execution model per state, and because the service — not replayed application code — always holds current state, there is no orchestration function that needs to stay deterministic. Human-in-the-loop uses callback patterns built on task tokens (.waitForTaskToken).

GCP Workflows takes the same managed-state-machine shape: a workflow defined in YAML or JSON, with the service managing execution state and able to hold, retry, poll, or wait for up to one year as documented. Human-in-the-loop is a callback endpoint — the workflow pauses and waits for an external HTTP call to resume it. It is serverless, with no charge while idle.

Cloudflare Workflows, and two lighter alternatives

Cloudflare Workflows runs each workflow instance on a dedicated Durable Object, with step state persisted as that object's own durable storage. step.do() executes a unit of work with automatic retry, step.sleep()/step.sleepUntil() hibernate the object so no compute is consumed while sleeping, and step.waitForEvent() suspends until an external event arrives — tightly integrated with the Workers ecosystem. As of August 2026 Cloudflare's own documentation states Workflows has reached general availability, though the source text carries no specific GA date; treat that as "GA at some point before this writing," not as recent news, and check current docs if the exact date matters to a rollout decision.

Two frameworks offer a lighter alternative rather than a full engine. LangGraph's checkpointer persists graph state after every node execution to a configurable backend (in-memory, SQLite, Postgres, and others), keyed by a thread_id; calling interrupt() inside a node saves state and surfaces a value to the caller, and the graph resumes when re-invoked with the human's response. This gives fault tolerance and human-in-the-loop within a single agent graph, not cross-service orchestration. The OpenAI Agents SDK's Session similarly persists conversation history across agent runs to a configurable backend (SQLite, Redis, MongoDB, and others), prepending history before each run and persisting new items after — memory continuity, not durable execution, since a Session does not guarantee transactional recovery from an infrastructure failure mid-run.

When does an agent actually need a durable execution engine?

An agent needs a durable execution engine once its task can cross a process lifetime boundary — parked on a human approval or an external signal for an arbitrarily long stretch, spread across minutes or hours of tool calls, or expected to pick back up cleanly after an unplanned process exit. None of those conditions can be satisfied by code that only runs inside one request handler, because the process that started the work is not guaranteed to be the process that finishes it.

A simpler approach is sufficient when a task is short and single-turn: a tool call that finishes inside one process's lifetime, in seconds, is covered by ordinary retry and timeout logic and has no crash-and-resume gap for a durable engine to bridge in the first place. Adding a durable execution engine to that kind of workload adds an operational dependency — a server to run, a journal to store, a determinism constraint to design around — without buying anything a plain retry loop does not already provide.

The dividing line is not task complexity or number of tool calls; it is whether the task can outlive the process that started it. A ten-step agent loop that finishes in eight seconds inside one handler is still a single-process-lifetime task even though it calls several tools. A two-step workflow that pauses for a day waiting on a human's sign-off is a durable-execution task even though it is short in step count, because that pause spans a lifetime no single process is expected to survive.

How do you choose among the durable execution options?

Choosing among durable execution options mostly comes down to three questions, not a feature-by-feature comparison of every engine. First, is there already a platform commitment? A team already running on AWS, Azure, GCP, or Cloudflare gets a native engine — Step Functions, Durable Functions, GCP Workflows, or Cloudflare Workflows — with no extra service to operate, and that usually outweighs any feature gap against a portable alternative.

Second, without that platform lock-in, the question becomes self-host versus managed among the code-first options: Temporal, Restate, and DBOS are all self-hostable but add operational burden, while Inngest's managed offering removes that burden at the cost of depending on its infrastructure — with an official, newer self-hosting path now also available. Third, for teams already inside LangGraph or the OpenAI Agents SDK, the question is whether a lighter checkpointer or session store is enough, or whether the workflow's needs — cross-service durability, complex retry and compensation logic, a pause-and-resume that spans more than one graph run — cross the line into needing a dedicated engine layered on top.

A declarative state machine such as Step Functions or GCP Workflows trades plain annotated functions for tighter native service hooks; whether that trade is worth it depends on how much of the workflow's logic naturally fits a state-machine shape. None of these choices is permanent — the underlying constraint of deterministic orchestration with non-deterministic work pushed into recorded units holds regardless of which engine enforces it, so switching engines later re-implements that same contract rather than redesigning the workflow's logic.

For the eleven other reliability disciplines this cluster works through — tool-calling contracts, structured outputs, retries, guardrails, evaluation, observability, rollout, and the rest — start at agent reliability in production; for the idempotency-key mechanics durable execution's replay guarantee depends on, see how to make AI agent retries idempotent.

#agents #reliability #durable-execution #workflows #production