Continuity Is Not Permission: The Engineering of Durable Agent Execution

A procurement workflow pauses on Tuesday afternoon, waiting for a director to approve a £38,000 supplier commitment. The director is travelling. On Friday morning she opens the queue, reads a summary written on Tuesday, and clicks approve. The runtime does exactly what it was built to do: it reconstructs the workflow state, resumes at the node after the approval, and commits.

Between Tuesday and Friday, three things changed. The agent’s spending ceiling was cut to £25,000 in a control review nobody told the workflow about. The supplier’s quote expired. And the figures in the summary the director read are no longer the figures in the payload that committed.

None of that is a bug in the durable execution layer. The durable execution layer worked perfectly. That is the problem.

A checkpoint answers "from where can computation continue?" It does not answer "is this still allowed?" — and most runtimes cannot tell the difference.

What durable execution actually has to hold

A conventional model call is ephemeral: request in, response out, and the surrounding application decides what happens next. An agentic workflow is not that. It carries a longer-lived execution state — the objective, intermediate results, tool outputs, pending decisions, approvals, errors and remaining work — and that state has to survive interruption if the workflow is going to be operable at all.

The mistake is to persist the conversation and call it state. A transcript can tell you what an agent said. It cannot establish what the system did. Those come apart precisely when it matters: the moment an agent decided to call an API is worthless without the immutable record of whether that call landed.

What has to be persisted is closer to this:

That last row does more work than it looks like. Come back to it.

The resume gate

Put those two observations together and the architecture changes shape. Resumption stops being a play button and becomes a boundary crossing — the same commit boundary the rest of this architecture uses for new requests, applied to time instead.

Before consequential work resumes, the system establishes that the objective is still live; that the principal and agent identities revalidate; that delegated authority still covers the action; that the evidence is still fresh; that policy and risk classification have not moved; what external effects already committed; that irreversible operations will not duplicate; and that any human approval still stands.

Eight checks, one crossing. And every one of them can fail for a workflow that the runtime would happily continue.

Four objections worth taking seriously

I have been arguing this for a while, and the sharpest response I have had to it was not that it is wrong but that it is expensive. Four objections, all fair. I would rather answer them than restate the architecture.

“Version pinning creates a migration nightmare”

Pin the model, prompt, policy and tool versions for every checkpoint and you have solved reproducibility and created a fleet-management problem. Update a system prompt and thousands of in-flight workflows are now running under rules you have replaced. Do they finish under the old ones or migrate to the new?

Both answers are bad, which is the signal that the question is wrong. The real control is the last row of that table: bound how long a workflow may live.

If no execution may remain resumable for more than a stated window — hours for most classes, minutes for high-risk ones — then the migration problem collapses into a revalidation problem, which you have already solved at the gate. Version drift only hurts over long horizons. Refuse the long horizons.

Within the window, three classes are enough:

• Nothing committed yet — abandon and restart under current rules. Almost always cheapest, and the only option that is unambiguously correct.
• Mid-effect — complete under the pinned versions, then stop. Compensating a half-finished sequence under new rules is worse than finishing it under old ones.
• Long wait by design, such as human review — revalidate at the gate, every time, because the world moved while you waited.

Nobody migrates in-flight state. They finish it, abandon it, or re-decide it.

“Bounded mandates are too expensive to enforce”

The objection: passing policy-bound mandates between agents across asynchronous frameworks costs latency and tokens, so engineers under delivery pressure route around them — and then a compromised agent moves laterally, because the receiving agent trusted the message.

The cost is real, and it comes from conflating two things. Deciding an authority question is expensive: policy evaluation, directory lookups, risk classification. Verifying one is cheap: checking a signature is microseconds.

So decide once, at delegation, and mint a short-lived signed capability carrying the bounded scope — the task, the permitted tools, the reachable data, the ceiling, the evidence required, the expiry. Receiving agents verify. They never re-evaluate. This is not novel; it is how capability tokens have worked for years, and the macaroon literature covers attenuation specifically.

Two engineering details carry most of the benefit:

The mandate travels in the message envelope, never in the prompt. It is transport metadata, not context. That removes the token cost entirely, and it removes something worse — a mandate inside the context window is a mandate the model can be argued out of.

Bypassing must be impossible rather than discouraged. If the commit boundary refuses any action whose capability does not verify, the shortcut does not exist. An engineer under pressure cannot skip a check that is enforced somewhere they are not writing code. If your answer to “developers will bypass it” is training, you have built the wrong thing.

“Replay drift makes reproducibility a fiction”

This one is the most important, and the original framing understates it. Resume a workflow three nodes back with a different model version, or merely a non-zero temperature, and the agent may choose a different tool with different parameters. What you called a replay has quietly become a different execution.

The resolution is to stop using one word for three operations that have nothing in common:

• Evidence replay reads the recorded inputs, outputs and decisions to explain what happened. It re-executes nothing. It is always safe, and it is what audit, incident review and regulators actually need. Most demands for “replay” are this, and are satisfied by the decision record.
• Resumption continues forward from a checkpoint. Safe for steps that have not committed, and made deterministic where it matters by caching prior outputs keyed on prompt hash, model version and seed.
• Re-execution runs the probabilistic step again. This produces a new execution, with a new identifier and its own evidence. It is not a replay and must never be described as one.

Once they are named separately, drift stops being frightening. You never re-execute to reconstruct the past — you re-execute to produce a new proposal, and a new proposal crosses the boundary like any other. A drifted plan is simply a plan that has to pass the same gate. Drift is only dangerous in an architecture where something can reach the world without being checked on the way.

“Human approval goes stale and nobody can fix it”

An approver takes three days. The market moved, the record changed, the quote expired. “Reassess evidence freshness” is easy to write and hard to mean.

Treat an approval as what it actually is: a claim about a specific payload, made at a specific time, on specific evidence — not a standing permission.

• Payload-bound. The approval carries a hash of the exact action and its inputs. Change a figure and the approval is void by construction, not by judgement.
• Evidence-bound. It records which evidence it rested on. If any of that expires, so does the approval.
• Time-boxed. Shorter windows for higher-risk classes. An approval that cannot be exercised within its window is not a stale approval; it is an expired one, which is a far easier thing to reason about.
• Diffed on re-approval. When something moves, the approver is not asked again from scratch. They are shown exactly what changed since they last looked, which is the only version of this that people will actually use.

And the honest residue: you cannot fully solve this. The world can drift in ways no named invariant captures. All the architecture can do is bound the window, bind the approval to the payload and the evidence, and show the difference. What it must never do is let a three-day-old click authorise a fresh commitment silently. That is the failure mode worth engineering against, and it is reachable.

How it holds together

Strip it back and there is one idea: the resume gate is the commit boundary, applied to time.

The same four things the architecture checks for a new request — context, authority, evidence, outcome — are the four things that can have decayed while a workflow was paused. Which means durable execution does not need its own governance model. It needs the existing one, invoked at one more place.

That is also why the framework question is the wrong question. LangGraph, AutoGen, CrewAI and the rest genuinely solve persistence, message routing and resumption, and they solve them well. None of them can tell you whether the next proposed action is still authorised, because that depends on your identity system, your policy, your evidence and your risk classification. It is not a gap in those tools. It is not their job.

Before the framework question, the allocation question

Everything above treats the workflow as given and asks whether it may continue. There is an earlier question, and getting it wrong is what makes the later ones hard.

A consequential workflow is not one kind of thing. Parts of it are knowable in advance and should be identical every time — those are rules, and they are the cheapest, most testable thing you can build. Parts of it are patterns learnable from history that should return a score rather than an action — those are predictive models, where calibration matters more than accuracy. Parts of it genuinely cannot be planned ahead and need judgement over unstructured material — those are agents, and they are the most expensive and least reproducible components you will run. Parts of it must hold whatever any of those concluded — those are deterministic controls, which are a boundary and not a fallback. And parts of it carry accountability that cannot be delegated to software at all.

The test for each step is two questions: what does being wrong cost, and can it be undone? Move a step leftward along that row and it gets cheaper, more testable and more reproducible — which is usually the improvement nobody proposed, because the conversation started at “which agent framework” instead.

Durable state, replay and asynchronous delegation make a platform operationally capable across all five. They do not decide which component a step belongs to, and they do not decide whether its proposal is authorised. The first is an architecture decision, made before anything is built. The second happens at the commit boundary, every time, including on the way back from a checkpoint.

What I would build first

Not the checkpointer — you probably have one.

An effect journal, written before the effect and confirmed after it, keyed by an idempotency key. Without it, every other question about resumption is unanswerable, because you cannot tell what already happened.

An expiry on every execution. One line of metadata that turns version migration from an architectural problem into an operational one.

One gate function that every resume path calls, returning resume, revalidate, or abandon — and that cannot be bypassed, because the commit boundary refuses anything that has not been through it.

Three components. None of them requires changing the agent framework, and together they turn a durable workflow from something that survives interruption into something that is still allowed to finish.

Where has a resumed workflow in your estate committed something that would not have been approved on the day it landed — and would you know?

References

1. Karimi, H. (forthcoming) The Contextual Agentic Enterprise, Chapter 3 (§3.6) and Chapter 11.
2. Garcia-Molina, H. and Salem, K. (1987) "Sagas", ACM SIGMOD Record 16(3). https://doi.org/10.1145/38714.38742
3. Birgisson, A. et al. (2014) "Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud", NDSS 2014. https://research.google/pubs/pub41892/
4. NIST (2020) SP 800-207, Zero Trust Architecture. https://csrc.nist.gov/pubs/sp/800/207/final

Share on LinkedIn (opens in a new tab)