The strongest infrastructure story in agents right now is durable execution: an agent can run for hours or days, survive a crash mid-flight, and pick up exactly where it left off without losing state. It is hard engineering, the teams who do it well are very good at it, and nothing here argues against it. If your problem is "don't lose progress across a long, flaky, multi-step process," that is the right tool.
The durability pitch keeps the state intact across the pause. Whether the rules still hold when the pause ends is left to someone else. And the most common reason a serious agent pauses is the one where that gap matters most: it is waiting for a human to approve something.
The pause that isn't a state problem
A consequential agent turn hits a step that requires human approval: release the payment, approve the exception, sign off on the change. So it stops. Maybe for thirty seconds, maybe until Monday.
Durable execution answers one question about that pause perfectly: will we still have the exact state when it resumes? Yes. The questions that decide whether the resume is safe are different ones:
- When it resumes on Monday, is the action still authorized, or did the approver's role change, the entitlement get revoked, the world move under it?
- Whose authority does it resume under? The original actor's, re-validated, or some system identity that quietly escalates privilege just to finish the job?
- If a slow-but-alive worker and a retry both think they own the resume, does the action fire twice?
- Did the human's approval itself get recorded as a control event you can later prove?
Durable-execution engines answer the third in their own terms: Temporal, for example, guarantees an activity "will be observed as completed exactly once" but notes it "may be executed multiple times," and recommends making activities idempotent. The other three are governance questions, and durable execution as a primitive leaves them to the code you write on top.
Resume is a governed operation
In a governed runtime, human-in-the-loop is a persisted state of the flow's machine: a blocking approval gated by role, written to the database, surviving restarts, hand-offs and retries. For the whole pause the turn sits paused as durable state, and nothing holds a process or a connection while it waits.
The resume the approval triggers runs as a governed operation:
- It resumes as the original actor, carried through the pause, never swapped for a privileged system account. Before any step runs, it re-reads that actor's role assignments from the database and checks them against the flow's declared
resumepolicy. A flow that declares no such policy resumes for any role. - It fails closed. If the policy no longer admits the actor, the run ends
failedwithresume_deniedbefore a single step executes, aFlowFailedevent lands in the hash chain, and the user gets a turn saying the resume is no longer permitted. - It is template-only and model-free. It completes the rest of the flow without calling the reasoner again; if any remaining step calls the model, it runs none of them and waits for the user's next message, so the pause opens no new entry point for an injection on the way out.
- It is race-safe by a verifiable claim. Each resume attempt takes a claim with its own identity and a lease it renews with a heartbeat. An attempt that is slow but alive keeps renewing and is not taken over; a dead one's lease expires (after 60 seconds by default) and exactly one attempt takes it over. One attempt at a time owns a resume, and the approved step does not run again: its decision is injected as the step's outcome.
- The decision and who made it land in the hash chain with the step the approval resolved, and so does the run's completion or failure; when it happened is bounded by the signed checkpoint that seals it.
Because the turn never held a connection open, the result is announced out of band when it resolves: a built-in event (a webhook, or a live stream) tells the caller the new turn is there to read, instead of a request blocked until Monday.
Two meanings of "resume"
Two systems can both "resume an agent after a long pause" and mean different things. One guarantees the bytes survived. The other also checks the authority and the actor, keeps a single owner for the resume, and writes the record. For a long-running internal automation, the first is enough. For an action that touches money or a regulated decision and waited on a human to approve it, the compliance questions sit in the gap between the two.
The honest limits
This is no claim to out-durable a durable-execution engine. For general-purpose, multi-week, many-step orchestration with the strongest possible recovery guarantees, a dedicated durable-execution platform is more mature, and for that work it is the right tool. Our durability is scoped to governed agent turns and contract-declared flows: Postgres rows and a job queue, not a general workflow engine.
The resume gate is only as strict as the flow's policy, and only on the approval's path. A flow that declares no resume policy resumes for anyone. When a paused run is picked up from the user's next chat message instead, the runtime reads the session's snapshot of roles instead of re-reading the assignments; on a denial it detaches the run from the conversation and leaves it paused, without failing it.
The model-free resume is a deliberate narrowing. If the rest of the flow declares a model step, the resume the approval triggers does not run it: it tells the user the step was resolved and waits for their next message, and that ordinary, gated turn runs the rest.
The claim lease solves a specific race. It guarantees one worker at a time owns a resume, by telling a live worker from a dead one. It does not make a crash free: a worker that dies partway has not yet written the steps it finished to the run's row, and the one that takes over runs them again. A worker evicted while still alive stops between steps, so the step in flight at that moment can still complete.
The stakes
An auditor looking at a long-running agent goes well past "did you lose state?" to "this action waited four days for an approval: prove the approval was real, the person was still authorized, it ran as the right actor, and it executed once." A durable-execution log can show the workflow resumed. A governed runtime answers the rest from its own records and from the checks it ran, within the limits above: the chain records the decision and who made it; the approver's authority is what the role gate checked when they decided, against a versioned contract; and the resume checked the original actor again before any step ran. The approver's role is not recorded as a separate fact.
Here is what the revocation case does. On a flow whose resume policy names the roles allowed to resume, block a turn on a human approval, revoke the actor's role during the pause, then approve: the resume re-reads the roles, ends the run failed with resume_denied before any step runs, and records the failure in the chain. The public demo is not up yet and has no approval flow; write to us if you want to see this case run. How it works shows how an action is gated before it runs.
This is the long-running case of a broader line: communication and proposal may be probabilistic, but authority, consequence, and the record of both must be deterministic and declared, even across a pause. The general argument is in You can't fight probabilism with probabilism; the enforcement case is in The agent proposes; the runtime presses the button; the proof layer is in Audit you don't have to trust.
Nicolás Moreno builds Zarel: governed AI operations, where the AI proposes and the contract decides.