What Is Durable Execution?

Durable execution is a way to run code so its progress is saved as it goes. If the process crashes, the machine restarts, or a dependency goes down for an hour, the work resumes from where it stopped instead of starting over.

Temporal, a company that sells a durable execution platform, calls it “crash-proof execution”. Its May 2025 guide lists four traits: it virtualizes execution, it is not limited by time, it preserves application state automatically, and it does not depend on specific hardware.

Why agents need it

A simple chatbot answers in a few seconds. A business agent often does not.

Say an agent processes a loan application. It pulls documents, calls three APIs, waits for a human to approve an exception, then writes to a core system. That can take hours or days. During that time, servers get redeployed, a vendor API returns errors, and someone’s laptop closes.

Without durability, you write custom code to handle all of that. With a plain script, a failure at step six means rerunning steps one to five. That can double-charge a card, resend an email, or burn model tokens again.

Agents have two extra problems:

Model calls are slow and cost money. You do not want to repeat them after a crash.
Agents take real actions. A retry that repeats a side effect is a bug with consequences.

How it works

The Temporal documentation describes the core idea. A workflow runs, and every step and its result is recorded in an Event History. If a failure occurs, the Workflow Execution picks up where the last recorded event occurred. A new worker process fetches the history and replays the workflow code against it. Steps that already finished are not run again; their saved results are reused. The workflow then continues with the first step that did not finish.

That replay approach has a constraint. Because the code is rerun to rebuild state, the workflow logic must be deterministic. The docs say the worker process checks that the commands the code generates match the current Event History. In practice, that means anything non-deterministic, like calling a model, reading the clock, or calling an API, must happen in a separate unit of work whose result is recorded, not in the workflow logic itself.

Other platforms use the same idea in different forms. Azure’s Durable Functions is an extension of Azure Functions for stateful workflows, where the runtime manages state, checkpoints, retries, and recovery. LangGraph uses checkpointers to save graph state so a paused run can resume later. These work at different levels, and I would not treat them as interchangeable. They share one goal: progress survives failure.

What you get

Automatic retries with backoff. Transient errors do not need hand-written loops.
Long waits. An agent can wait days for a human approval without holding a server.
Resumability. A deploy mid-run does not lose work.
Visibility. The history shows exactly what happened and in what order.
Safer side effects. With unique request IDs on each action, a retry does not duplicate it.

What you must still do

Durable execution does not make an action safe to repeat. You still need:

Idempotent actions. Sending the same “create payment” request twice should not pay twice. Use idempotency keys.
Timeouts. Decide how long each step may take before it fails or escalates.
A failure path. What happens after the last retry? A person should get a task, not silence.
Versioning. Changing workflow code while runs are in flight can break replay. Plan upgrades.
Guardrails on actions. A resumed agent still needs permission checks. See human in the loop.

A short example

Say an agent onboards a vendor. Step one extracts data from a W-9. Step two checks a sanctions list. Step three waits for procurement approval. Step four creates the vendor in the ERP. The server restarts during the approval wait, two days in. With durable execution, the run resumes after the restart, the extraction and sanctions results are already stored, and no model call is repeated. Step four uses a vendor-creation key, so even a retry cannot create two records.

Common mistakes

Putting model calls inside deterministic workflow logic.
Assuming retries are safe without idempotency.
Building a home-grown queue and state table, then rediscovering every edge case.
Using durable execution for a five-second task that does not need it.
No alert when a workflow is stuck.

Agent orchestration is the broader job of coordinating steps and agents. Agentic workflows are the multi-step processes that benefit most. Agent memory systems cover what an agent remembers between runs, which is different from saving execution progress. For multi-agent designs, see multi-agent systems for the enterprise.