# What is Durable Execution?

Also called durable workflows.

Durable execution is a model in which a long running process survives crashes, deploys, and restarts without losing its place. The engine records the outcome of each completed step, then reconstructs the process state by replaying that history and skipping work already done. It lets code that waits minutes, days, or longer be written as ordinary sequential logic.

The mechanism is an append only history of events. Each time the process performs an external action, the engine records the action and its result. If the process crashes, a new instance replays the recorded history: previously completed steps return their stored results immediately rather than executing again, and execution continues from the first step with no recorded outcome.

Replay imposes a constraint on the code. Anything that must produce the same value on replay cannot be computed nondeterministically inside the process body. Current time, random numbers, unique identifiers, and network calls must be delegated to the engine so their results are recorded, otherwise a replayed run can diverge from its history. This is the most common source of confusion for newcomers.

The advantage over hand rolled state machines is expressiveness. A process that waits three days for approval, then calls two services, then branches on the result can be written as sequential code with an await, rather than as a set of database rows, cron jobs, and reconciliation scripts. The durability guarantee comes from the engine rather than from application discipline.

For agent workloads the fit is direct. An agent run can span many model calls and tool invocations over many minutes, and a platform that deploys frequently will otherwise interrupt runs in progress. Durable execution lets a deploy restart the process while the run resumes from its last recorded step, and it produces a step by step history that doubles as an audit trail of what the agent actually did.

## Key points

- Processes survive crashes, restarts, and deploys.
- State is rebuilt by replaying a recorded history of step outcomes.
- Nondeterministic operations must be delegated to the engine.
- Long waits become ordinary sequential code.
- The recorded history serves as an execution audit trail.

## In practice

An agent task calls a model, then a search tool, then writes a document, taking four minutes overall. A deploy restarts the process after the search step completes. The replacement instance replays the history, immediately receiving the stored model and search results without re issuing either paid call, and continues at the document write. The task finishes normally and the user never learns a restart occurred.

## Related terms

- [Workflow](/en/glossary/workflow)
- [Orchestration Engine](/en/glossary/orchestration-engine)
- [Idempotency](/en/glossary/idempotency)
- [Retry policy](/en/glossary/retry-policy)
- [Agent trajectory logging](/en/glossary/agent-trajectory-logging)

[Back to the AI Glossary](/en/glossary)