What is durable execution?

Durable execution is the guarantee that lets a long-running workflow, agentic or not, survive crashes, restarts, and deploys without losing the state it has already accumulated: at every completed step the engine writes a checkpoint, and if the process dies partway through, it resumes exactly from there on restart, not from the beginning. The difference from a generic retry is exactly this: a retry relaunches the function from scratch, hoping it is harmless to redo what already succeeded; durable execution records what already happened and skips it, replaying only the interrupted step forward. The engine offering this guarantee exists both as a library running inside the application and as an external service the code delegates orchestration to: the common thread is that the execution state, including the exact point reached in a function that can run for hours or days, does not live in a single process's memory but on persistent storage consulted on every resume.

See also: Agent harness · An agent harness is the software scaffolding around an LLM that makes it an agent: the execution loop, the tools, the context and the limits you give it.

Not a retry, not compensation

It is worth separating durable execution from two neighboring patterns it gets confused with. A plain retry with backoff relaunches a single call when it fails, with no notion of where the overall workflow stood: useful, but too granular to guarantee that a twenty-step process survives a server restart at step eight. The saga pattern, instead, answers a different logical question: what to do when a step fails for good and the effects already produced by earlier steps need to be undone with compensating actions. Durable execution does not decide whether to undo or continue: it only guarantees that, whatever the workflow is doing, the infrastructure underneath does not lose the work already done to a crash, a restart, or a deploy. The two compose well: a durable workflow can include a saga inside it, but they solve different problems.

A concrete enterprise example

An agent processing a batch of ten thousand invoices, each requiring a call to a document recognition service, a check against an external ERP, and a write of the result, can run for hours. Without durable execution, a deploy of the application halfway through the batch, or a container crash from memory exhaustion, forces a full restart from scratch: already-processed invoices get reprocessed, and if the ERP call was not designed to be safely repeatable, that reprocessing risks duplicating a write, the same problem covered in idempotency and backfill. With a durable engine, the restart resumes at invoice 6,412, not at the first one, and every call that already succeeded is not repeated.

Why it matters for decision makers

Because most teams building persistent agents or long pipelines end up reinventing a piece of this guarantee by hand: a "last completed step" column in a database, a job scheduler that restarts from zero, an idempotency flag bolted on after the first production incident. It is fragile, recurring work, the same work a durable execution engine solves once. The cost of not having it is not theoretical: it is the lost work on a long batch, the duplicated side effects of a poorly designed retry, the engineering time spent rebuilding by hand a guarantee that already exists as a component. Anyone evaluating an agent harness or a platform for agent ops should ask explicitly how this guarantee is handled, because the answer is what separates a workflow that tolerates a production restart from one that does not.