A journal can replay. The world cannot.

A refund above one thousand dollars parks the ticket until a manager approves it. The wait runs for hours, sometimes for days. That workflow is the demo in DBOS’s write-up on durable execution. Suppose the service restarts somewhere inside the wait. When it comes back, the agent does not ask again whether this refund should be issued. It reads back the recorded approval and executes.

Nothing errors. No refund goes out twice. The ticket state stays consistent. That is precisely what durable execution promises, and it is where the promise gets misread: the journal carried a decision made two days earlier into today, and over those two days the price, the stock, the policy version and the customer’s account may all have moved.

This piece is about one thing. Replay makes the same decision happen twice; it does not make that decision true today. Both properties live inside the same mechanism. One is the design goal. The other is the half that nobody has built yet.

How the machinery avoids duplicates

Temporal’s article on agents opens with the skeleton of the mechanism: the workflow has to be deterministic, the activities may be as unpredictable as they like. Model calls, tool calls and HTTP requests all sit in activities, because their outputs get recorded and come back as data during recovery instead of happening a second time.

It runs in three moves. Code goes from the first line of the function to the last. Every place that reaches outside the process writes its input and output into an event history. After a crash, the code runs from the first line again, checks the history step by step, and takes the recorded output for any step already done instead of executing it.

The arrangement requires the control flow itself to be deterministic. The same code against the same history has to walk the same order, which pushes every source of unpredictability out of the control flow and into recorded steps. In Temporal’s words, the determinism requirement does not constrain what an agent does; it is what makes an agent reliable in production.

Their documentation adds the line that matters more. After recovery the workflow does not ask the agent for a new plan for decisions it has already made. It reads the event history as a record of past decisions, and only from the recovery point onward does the agent plan freely again. That sentence explains the mechanism and exposes the gap at once: what gets read as a record of decisions is a record of decisions, not a record of the conditions those decisions rested on.

The failure case is theirs too. A vacation agent books flights to Whistler, Canada, then crashes at the find hotels step. Without a journal the restarted process plans again, and this time it books flights to Japan. The Whistler flight still needs cancelling. Same request, two runs, two answers, and nobody changed their mind in between.

Replay hands back the same decision, not the same fact

Diagrid states it carefully when describing its own product: “Durable execution doesn’t make any single step smarter or accurate; a replayed step repeats the same decision”. That is the mechanism describing itself, not an outsider’s criticism. Durable execution does not improve the accuracy of any step. It makes a repeated step return the same result.

So what does exactly once promise? It promises that the action happened once measured against the state when it was recorded, and a crash cannot turn that into zero or two. It does not promise that the recorded state still holds today. Those two sentences differ by half a clause, and on refunds, orders, disbursements and notifications the difference is money.

The refund ticket is the example. The manager’s approval is recorded, and replay reads it back as fact. The record holds the outcome, not the conditions: which policy version it rested on, what the balance was, whether the order was still pending. At recovery the runtime can check that the step exists. It cannot check that the step is still valid.

We wrote earlier that a checkpoint restores where a flow had got to, not whether an external write happened exactly once. This piece covers the other half of the same machinery. The side effect half has owners now. The replayed judgment does not.

The unit of design moved from the agent to the step

Once a journal is in place, attention moves by itself. The old question was how smart the agent is and how well the prompt is written. The first question now is whether this step’s output can be used as fact. Those are two different jobs, not two phrasings of one.

Every step has three questions attached. Which external state does this conclusion depend on? If that state moved, does the conclusion still hold? When it does not hold, do we recompute, ask a human again, or compensate? Most teams answer the first one, and they answer it in a design document rather than in the record structure.

Why this matters: replay happens inside the runtime with nobody in the room. At the moment of recovery no one questions an approval from two days ago, because the code is simply walking down the history. If you want a recheck at recovery, the requirement has to live in the record, or the runtime has nothing to act on.

Three things a step record needs

A step record that can serve as evidence carries three fields. The output itself. The specific preconditions it rested on, such as a policy version, a quoted price, a stock level, an authorization scope, the approver. A validity window, meaning how long may pass before the precondition has to be checked again.

Drop any of the three and the journal falls back to an archive. It proves the system once thought this way. It does not prove the system may still act this way. An archive supports review after the fact; a proper record supports an automatic check at recovery.

A simple test: hand the log to someone who did not work on the project and ask whether they can tell if this decision should still be executed. If they cannot, the record is incomplete. The person a record most needs to convince is the auditor who is not in the room when the job resumes.

Three kinds of step, three handling policies

Not every step is the same. A rough split into three categories gets you most of the way, and the handling differs sharply.

The first is replay without conditions. Pure computation, idempotent reads, and irreversible facts that already happened, such as a posted ledger entry or a notification already sent. Those records describe something done, so replay is safe.

The second is replay behind a precondition. Price, stock, policy, credit limit and human approvals all sit here. Recheck the precondition before replaying, continue if it holds, recompute or re-approve if it moved. This category is far larger than the first and it is the one getting skipped.

The third is no replay at all, only compensation. Once an outward promise leaves the building, a second execution cannot fix it: contracts, quotes, refund instructions, public notices. Recovery for these has to be a reversing action plus a human confirmation, not a rerun.

All three policies belong in configuration that travels with the step, not with the agent name. Swapping in a different agent that performs the same step should not change the policy.

Not every workflow earns the overhead

Durable execution has a real cost: an extra journal write per run, an extra runtime, an extra record structure to keep in step with releases. Where it does not pay: single step tasks that finish in seconds, where a crash costs one cheap rerun. There the journal is pure overhead.

The test can be stated concretely. Find the longest stretch where the flow does nothing but wait. A few seconds means a narrow replay window and little chance of expiry, which does not justify building a journal. Hours means somebody has to hold the state. Days means whatever holds it needs an expiry, or it is holding a stale decision.

One category gets overlooked: read heavy analytical work. Each run stands alone, the output does not change the outside world, and a crash is fixed by running it again. Durable execution saves little there and adds a log that now needs auditing.

The saving and the skipped recompute come from one switch

Durable execution saves money because completed steps are not executed again. No second execution means no second model call, so the tokens and the latency are gone. The catch is that the steps most likely to have expired are exactly the ones that never got recomputed.

On this line, cost and correctness are not two targets you can optimise separately. They are two ends of one switch. Skipping the recompute saves money and preserves a decision that may be out of date. Recomputing spends money and pulls the decision back into the present. The design job is to pick a side step by step, not to give the whole flow one answer.

A useful starting point for picking: ask who absorbs the cost when this step is wrong. A wrong internal report is fixed by rerunning it. A refund sent to a customer needs somebody to explain it. Keep the first on the saving end. The second belongs on the recompute end.

Four questions for procurement and audit

When a vendor sells durability, put the questions on the record structure instead of stopping at whether crashes are supported.

One: what fields does the journal hold? Inputs and outputs only, or preconditions and validity windows as well. This decides whether recovery can check anything on its own, or whether review depends on somebody remembering.

Two: can recovery be configured per step? Whether replay, recompute and compensate can be set per category, or whether there is one global behaviour. A single global behaviour forces a single compromise across the whole flow.

Three: can the journal prove it was not edited? How long is it retained, who can read it, where the permission boundary sits. Diagrid puts cryptographic signing and per step traceability into its product description. That is a vendor claim pointing at verifiable execution, and whether it covers the steps you audit is something to see demonstrated on a real interrupted run.

Four: can the log alone explain a recovery? Hand over an interrupted run and ask whether an auditor can tell which preconditions held at each step. This one is an acceptance criterion. Teams that can answer it audit by reading a file. Teams that cannot audit by rerunning the flow and asking people to explain from memory.

Keep the sourcing straight while you ask. Temporal names OpenAI’s Codex and Replit’s Agent 3 as running on it. DBOS’s example is its own demo application. Diagrid’s capabilities come from its release notes. All three are vendor statements. They are credible as direction and need checking as coverage.

Our judgment

First, the layer changed position in the second half of 2026. Durable execution used to be a workflow engine feature for background jobs. It now sits underneath agent frameworks: Diagrid wraps LangGraph, Microsoft Agent Framework, Google ADK, AWS Strands, OpenAI Agents SDK and CrewAI with one package; DBOS ships it as a library used alongside LangGraph’s checkpointer; Dapr’s durable execution reached Goose and n8n in October. With the substrate moving, the selection question stops being which framework and becomes what this runtime records.

Second, reliability moved off the agent and onto the step boundary. An agentic flow that survives three years does so because the preconditions of each step are written down and rechecked at recovery, not because the model got smarter. A new model raises quality inside a step. It does nothing for the accounting between steps.

Third, durability is being sold as risk control while delivering half of it. It keeps one action from happening twice. It does not keep a judgment current. Before durability goes into a contract clause, require preconditions and expiry in the journal. Without them you are buying a reliable capability to execute an expired decision.

Three moves for this quarter

One: list the longest wait in each existing flow and sort by it. For anything above an hour, establish where the state lives right now: process memory, a checkpoint table, or the journal. If it lives in process memory, the next crash is a start from zero.

Two: pick one flow with a wait measured in days and add two fields to every recorded step, the precondition and the validity window. No runtime swap needed, only a change to the record structure. After that you can at least tell whether the record deserves trust.

Three: add one line to acceptance criteria. Hand over an interrupted run and ask whether an auditor can tell, from the journal alone, which conditions held at each step. If the answer is no, keep recoverable out of the service level agreement.

References

Temporal, Of course you can build dynamic AI agents with Temporal, 12 November 2025: temporal.io/blog/of-course-you-can-build-dynamic-ai-agents-with-temporal. Source for the workflow and activity split, the rule against replanning past decisions, the Whistler flight example, and the Codex and Replit usage claims.

Diagrid, Durable Execution, Now Built for Agents, 27 July 2026: diagrid.io/blog/what-is-agentic-durable-execution. Source for the statement that replay repeats the same decision, the four quadrant model, the signing and verifiability description, and the supported framework list.

DBOS, Durable Execution for Building Crashproof AI Agents, 24 February 2025: dbos.dev/blog/durable-execution-crashproof-ai-agents. Source for the one thousand dollar approval threshold and the asynchronous refund workflow.

Dapr durable execution for Goose and n8n: Diagrid blog posts dated 28 October 2026 and 21 October 2026. Every vendor capability above is labelled as a vendor statement and was not independently verified.