The run is the unit of governance: why durable execution belongs under every agent

Agent platform field notes, five of eight. Notes two and four both leaned on a word I have not yet defined: the run. This note is about why that word carries so much weight, and which engines can carry it.

The question

Most agent frameworks model a conversation. Messages go in, messages come out, tools get called in between. That is fine for a chatbot. It falls apart the moment a municipality asks three questions that every regulated process eventually asks:

• Where exactly is this piece of work right now, and who is waiting on whom?
• When the human approved, what state was the work in, and has it changed since?
• Can we stop it, right now, and know that it stopped?

A conversation cannot answer those. A run can. So the design decision in this note is: every agent action executes as a durable, inspectable run, and the run, not the conversation and not the agent, is the unit the governor admits, approves, evidences and cancels.

A conversation remembers what was said. A run remembers what was done. Courts, auditors and citizens have never once asked for the former.

What a run has to be

Before choosing an engine, I wrote down what the run must do, because that is what I would be buying.

It must survive. A crash, a deploy, a node going away, a model provider timing out: the run resumes from its last completed step, not from the beginning, and never executes a completed step twice. Re-sending an email to a citizen because a pod restarted is not an edge case; it is the first incident you will have.

It must pause for as long as a human needs. Approval in a municipality is not a thirty-second popup. A supervisor may be on leave. The run has to wait durably, for days if required, and resume only the exact plan revision that was approved. If anything changed in between, the approval is stale and the run must ask again.

It must be inspectable without being touched. An auditor, an operator and the affected person each need to see where the run is and what it has done, through a view that cannot alter it.

It must be cancellable, and cancellation must be a fact, not a request. Compensation for actions already taken is part of the run’s own lifecycle, not an afterthought.

And every step must leave a record whose order and content are fixed: which policy was evaluated, what the model proposed, which tool executed, who approved, what came back.

That list is a durable-execution engine’s specification, with governance words in it.

The three engines

I evaluated three families in depth and placed the rest of the field around them.

Temporal is the event-sourced incumbent. Every decision a workflow makes is appended to a history, and a worker replays that history to reconstruct state after any failure. The server is Go and runs on Postgres, MySQL or Cassandra; the SDKs cover Go, Java, TypeScript, Python and .NET. For the run as defined above, the event history is the evidence of what happened, in order, with no extra work. Worker versioning, new in 2026, pins running workflows to the worker version that started them, which solves the “we deployed mid-run” problem that otherwise breaks approvals. The cost is operational: it is a cluster to run, and its history is powerful but not something a caseworker reads.

DBOS takes the opposite stance: durability as rows in Postgres, nothing else to operate. Annotate a function as a workflow and its steps, and the library stores progress in the database you already have. Exactly-once step execution, queues, scheduling and workflow versioning come along. For a municipality that already runs Postgres and does not want another control plane, this is attractive, and the durability record sits in the same database as everything else the auditor will look at. The trade is that the engine is the library inside your process; the discipline is yours.

Restate is a Rust runtime with durable execution, durable promises and timers, and consistent per-entity state in one engine. It is the most natural fit for the “pause for a human for a week” requirement, because a durable promise is exactly that: a value the run awaits that survives everything. It is also the youngest of the three in production use.

The decision I made is less interesting than the criterion. Any of the three can carry the run. What none of them can do is decide what the run is allowed to do. The engine guarantees that step four follows step three and that step three never happens twice. It has no opinion on whether step four should have been admitted. That remains the governor’s job, and I kept it there: the engine executes an admitted run, the governor admits it, and the engine’s history feeds, but does not replace, the hash-chained evidence record the governor writes.

Two consequences people underestimate

Durable execution makes human oversight real instead of theatrical. Article 14 of the EU AI Act asks for human oversight that is effective, not decorative. The difference, in practice, is whether the human can take as long as they need, see exactly what they are approving, and have the system wait. A conversation model cannot give them that. A durable run can, and the override rate across runs becomes a measurable number, which is the only way I know to prove that oversight is happening.

Durable execution changes what “stop” means. On a conversation model, stopping an agent means hoping the loop checks a flag. On a durable run, cancellation is an event in the history, compensation steps are themselves durable, and “it stopped” is something you can show an auditor.

What I cannot prove yet

Prototype grade. My platform runs on one of the three and the demos exercise pause, resume, cancel and compensation. What has not happened is a week-long approval wait across a worker version upgrade in production, or a cancellation during a partially completed compensation with a real downstream system on the other end. Those are the cases that will teach me whether the run model holds.

What to do with this

If your agent platform has no durable run, ask what the human is approving. If the honest answer is “a message in a conversation”, you do not have human oversight; you have a chat with a pause button. Put an engine under it before you put a citizen in front of it.

Next note: evaluation and guardrail tooling, and the difference between what you can prove and what you can only hope.

Time in a conversation is wibbly-wobbly, timey-wimey. Time in a run is a sequence number. Auditors, unlike the Doctor, prefer the sequence number.

References

The allusions and quotations in this piece, with their origin:

• Doctor Who, “Blink” (BBC, 2007): “wibbly-wobbly, timey-wimey”.