In This Series
Deciding whether you need it at all
- What Durable Execution Guarantees and When a Retry Wrapper Is Enough — what the runtime actually commits to, where the boundary falls, and the test that separates a retry wrapper from an engine.
Understanding the mechanism and who holds the record
- Checkpoints Versus Event History and Why Interrupted Steps Re-run — snapshot or log, how much work re-executes after a crash, and why state is not memory.
- Who Owns Agent State and What It Costs to Leave — three custody models, the export questions nobody answers in public, and what exit actually costs.
Living with it after month one
- Event History, Determinism and What a Deploy Does to Running Agents — determinism, deploy-time run loss, and the authority that comes with holding the record.
What does durable execution actually guarantee for an agent run — and what does it leave to you?
Temporal closed a $550M Series E at a $12.55B valuation in September 2026 and took the GeekWire 200 top slot. Restate raised $20M in Berlin the same month. On 6 October, Temporal hired Oso’s team to build authorisation into the execution layer; two days later, Oso Cloud’s assets sold to Tiny for $1.9M. Those figures are reported, not confirmed.
The order is the point: whoever holds the replayable record acquires the authority to approve what it replays.
Durability is a family of incompatible promises sold under one word, and the one with commercial weight is custody. The engineering under that pricing is thinner than it implies. Four questions decide it: what the guarantee covers, which mechanism re-runs your work, who holds the record, who approves a replay. Evaluate the guarantee, locate the record, price the exit.
Durable execution promises resumption from the last boundary you declared, plus durable timers and durable pauses. It does not promise an external effect happens once: the effect’s identity must be claimed before the runtime has anything to record. Boundary placement, business identity, payload size and custody of the record stay yours. Whether you need it at all is a sizing decision, not a maturity signal.
Durable execution is an umbrella over four mechanisms with different units of saved work: checkpointing, journal-and-replay, step memoisation and platform hibernation. The step boundary is the unit of cost, because work is saved only between the boundaries you draw and the crash bill runs from the last commit.
Exactly-once is a contract with the outside world, not something an engine grants: Stripe’s idempotency key is the shape to copy, a business identity claimed before execution, reused on every retry. A step that is seconds long, single-process and idempotent survives a retry wrapper; one that waits on a person, runs for days or moves money does not.
Worked through in what the guarantee covers and what it leaves to you.
Checkpoints, event histories and re-run steps — which one re-runs your work?
A checkpoint is a snapshot of state at a boundary. An event history is a log of commands and results. The difference shows up after a crash: a snapshot reloads and replays the whole interrupted node from its first line. A journal serves completed units from the record and re-runs only the unfinished one. One agent turn making twelve tool calls can therefore re-execute twelve or one.
Two families sit under the one label. Checkpoint-and-re-execute (LangGraph, Mastra) against journal-and-replay (Temporal, Restate, DBOS, Inngest). Successful parallel siblings are kept when a super-step resumes, an interrupt is not a finer unit, and a call inside one is not tracked separately.
LangGraph ships async as its durability default, so the newest checkpoint can be lost. Agent state and agent memory are sold as one idea: state lets a run resume, memory should influence the next run, and a checkpointer is no knowledge store. Diagrid, a competing vendor, argues the same case. Checkpoints, event histories and re-run steps traces how.
Who owns agent state, and what does leaving cost?
Three custodians, ordered by how far the record sits from you: your own database, a cluster you run, somebody else’s platform. What separates them is who can read, price, migrate or refuse access to the record without you. Nothing published says whether an event history, a checkpoint table or a journal can be exported and replayed elsewhere, which makes it a contract question, not a technical one.
DBOS, Restate and checkpointer tables keep state inside your own backup and restore story, as does Postgres. Self-hosting Temporal is an on-call commitment; Temporal Cloud removes that surface and reinstates a renewal date. Portability lives in the record’s format, not the exit clause. The rows travel; the replay logic gets rebuilt, as one team found moving off Temporal Cloud at 500 starts per second.
Continue-As-New and payload ceilings are the two ways an audit record stops being complete. Residency is the same conversation: Sydney, Melbourne and Brisbane buyers against vendor jurisdiction, where an Australian region keeps bytes onshore and leaves the legal question alone. Microsoft’s Agent Framework and Foundry split state across two stores; the documentation does not say how the halves reconcile.
The comparison on who owns the state and what exit costs settles the contract language.
Determinism, deploys and who is allowed to approve a replay
Event history forces deterministic code because replay re-issues commands and matches them against what was recorded. A changed branch only surfaces when an old run resumes, so the non-determinism error ships silently and appears in month two. Deploys usually kill in-flight runs, and recovery windows are guesses. Authority is the forward edge: whoever holds the record is positioned to approve its replay.
You pay for replay in determinism, and the bill lands at deploy: a deterministic sandbox hides the constraint in TypeScript, other SDKs leave it to discipline. Worker versioning and patching are the published remedy. Deploy-time run loss is the other cost: Rivet gives running work a default fifteen minutes of grace, Mastra re-drives orphaned runs on boot, and a bad deploy bills twice.
Authorisation appears to be moving into the execution layer, and the Oso hire points that way; relationship-based access control fits the lineage without being announced. LittleHorse’s 21 September agent controls are reported shipped and undocumented here. A stored approval records what was allowed then; the check that matters happens where the effect lands, and that boundary is yours while the record sits elsewhere.
That split is where determinism, deploys and the authority to approve leads.
Where to start, by decision type
Start with the decision you hold.
Deciding whether you need it at all
- What Durable Execution Guarantees and When a Retry Wrapper Is Enough. The boundary, the crash bill, the retry-wrapper test.
Understanding the mechanism and who holds the record
- Checkpoints Versus Event History and Why Interrupted Steps Re-run. Which mechanism your stack uses, what re-executes.
- Who Owns Agent State and What It Costs to Leave. Three custody models, the export questions, the silence.
Living with it after month one
- Event History, Determinism and What a Deploy Does to Running Agents. Non-determinism errors, deploy-time loss, authority over replay.
Signing a multi-year agreement? Start with the third group. Holding a crash this afternoon? The first.
The question worth carrying into the room
Nothing in the guarantee tells you what happens to runs still open the day you decide to leave, or who pays for rebuilding orchestration logic that was never a document you held.
The record is becoming the authority, so the decision is who can read, price, migrate or refuse access to it, and what happens to runs in flight the day the answer is no. Take the question you hold to the article that answers it: build versus wrapper is the guarantee piece, contract term the ownership piece.
Frequently asked questions
Is a checkpointer the same thing as durable execution?
No. A checkpointer writes a snapshot of graph state at a boundary. It schedules nothing, retries no failed vendor call and prevents no duplicate effect. The distinction and what it costs after a crash are set out in the mechanism comparison.
Why does a resumed agent run repeat a step the documentation says it skips?
Resumption restarts at the node, so work inside it repeats. The runtime restores the input state and re-enters the function from its first line, and successful parallel siblings are the exception. Why interrupted steps re-run traces it.
Can a durable runtime make an external side effect exactly-once on its own?
No. The identity of the effect has to be claimed before execution, outside the runtime’s jurisdiction, which is why the property on offer is at-most-once plus an idempotency key. Compensation is the fallback where no key can exist. See what the guarantee covers.
Do you need a full engine if you already run Postgres?
Often not. A table, a queue and row-level locking approximate resumption. What that lacks is replay of orchestration code and durable timers, and storage was never the hard part. The sizing test lives in the guarantee article.
Can an event history or checkpoint table be exported and replayed elsewhere?
The public record does not say. No public documentation covers an export format or a replay path for any of these engines, so portability ends up in the contract. That gap is the centre of the ownership comparison.
What happens to in-flight agent runs when you deploy?
They usually die with the worker fleet. Recovery grace windows exist, and their durations are defaults a vendor can change, so the number belongs in your sizing. See what a deploy does to running agents.
Why is durable execution worth $12.55B now, a decade after the same idea shipped at AWS?
The reported valuation is a claim about where value is moving, towards custody of the replayable record. It does not show that the mechanism is new. The figures stay snippet-level throughout the series, reported and unconfirmed.
Should the replay log stay onshore for Australian regulated workloads?
It is an ownership question, because event histories carry customer payloads. The public record does not say whether these engines offer an Australian region, so treat Sydney, Melbourne and Brisbane placement as an open procurement item next to the export question in the state-ownership comparison.
