Durable Work, Human Judgment 

Approvals that survive a restart, a weekend and a handover — and one rulebook for automation your business builds and automation your developers write 

There is a particular kind of demo that always lands well and almost never survives production. An agent proposes an action. A neat approval card appears. Someone clicks approve. The agent continues. Everyone in the room understands immediately that this is the right shape — the AI proposes, a human disposes — and the meeting ends on a high note. 

Then it goes to production, and a node is recycled during a deployment while four approvals are pending. All four runs vanish. Not failed — vanished, because the thing that was waiting was a process holding state in memory, and the process is gone. Nobody gets an error, because there’s nothing left to raise one. Someone finds out on Thursday when a customer asks why nothing happened. 

The gap between the demo and the deployment isn’t the user interface. It’s what “waiting” means — and it’s why human in the loop AI approval can’t be optional for consequential work, but a naive implementation breaks the first time infrastructure moves underneath it. 

THE 90-SECOND VERSION 

• The propose-approve-proceed pattern isn’t optional for consequential actions — but a naive implementation breaks the first time infrastructure moves underneath it. 
• A durable approval treats the pause as recorded state, not a running process. The run can wait days, survive restarts and deployments, and resume exactly where it stopped. 
• Reviewers must see the substance — what the agent actually proposes and what led to it. A content-free approval card produces rubber-stamping, which manufactures evidence of oversight that never happened. 
• Each approval names its specific gate, so approving one step can never resolve a different one. 
• Two populations author automation — business users and developers — and both must pass through the same approval and audit spine, or the governed path becomes the slow path. 

What “waiting” has to mean 

The naive implementation keeps a process alive — something running, holding the request, blocked on a response. It works beautifully until the machine it lives on is patched, scaled down, or restarted, all normal events your platform team does on purpose, often weekly. 

The durable version inverts it. The run’s position is written down. Nothing is holding a connection open. The run is a record that says: this work reached step seven, step seven is a gate, and it’s waiting for a decision that hasn’t arrived — the same principle durable execution platforms like Temporal are built around: a workflow resumes from its last recorded step regardless of what happened to the machine underneath it. 

Restart every machine involved. The record is unaffected. When the decision arrives, the run is picked up from its recorded position by whatever capacity is available and continues. 

This sounds like an implementation detail, and it isn’t. It’s the difference between an approval gate you can put in front of a payment and one you can only put in front of a demo. Real approvals take real time — a reviewer is in meetings, then travelling, then it’s the weekend. Any mechanism that assumes minutes will fail on the case that matters most: the decision someone wants to think carefully about. 

If your approval gate cannot survive a deployment, it is not a control. It is a delay with a user interface. 

Approvals that are worth having 

Durability makes the gate reliable. It doesn’t make it meaningful. That takes two more properties, both frequently skipped. 

• The reviewer must see the substance- An approval that says Invoice agent requests permission to proceed. [Approve] [Reject] is theatre. The reviewer has no basis for a decision, so they develop a habit — usually approving, since rejecting means a conversation. Within a month you have a gate with a near-100% approval rate, which isn’t oversight. It’s a log of clicks. A useful gate carries the reviewable output of the steps that led here: the adjustment proposed, the invoices it reconciles, the discrepancy that triggered it. The reviewer is judging a decision, not authorizing an abstraction — and is now capable of rejecting one, the only thing that makes approval mean anything. 
• Each approval must name its gate- In a run with several gates, an approval has to resolve exactly the one it was issued for. If signals are loosely matched, a decision meant for the second gate can satisfy the third — and the difference between “a person approved the deployment” and “a person approved the code review and the deployment inherited it” is the entire content of your control. 

Then there’s segregation of duties, where this stops being a workflow feature and becomes a governance one. A gate can require that the approver isn’t the requester, or that two gates are cleared by two different people — standard practice for human processes, formalized in NIST’s separation-of-duties control and ISACA’s guidance on implementing SoD. It matters more with agents, not less, because an agent will happily produce a request that looks entirely reasonable, at three in the morning, at volume. 

Which actions deserve a gate 

The most common failure of approval design isn’t technical. It’s gating too much. 

It happens for understandable reasons: the security review asks for oversight, gates get added generously, and generosity feels like prudence. Six weeks later, reviewers are clearing forty requests a day and have developed the only rational coping strategy available — approving quickly without reading. The gate on the one action that mattered is now cleared by the same reflex as the thirty-nine that didn’t. 

A gate costs the reviewer’s attention, a fixed budget. Gating everything is functionally identical to gating nothing, with added latency. Three questions identify what’s actually worth gating. 

Is it irreversible? Money moving, an email sent, a record deleted. Reversible actions can often be allowed and corrected; irreversible ones can’t — this asymmetry is the strongest single signal, and it’s the same logic behind decades of financial-controls practice, including the internal-control requirements public companies already operate under. 

Is it externally visible? Anything a customer, regulator, or counterparty will see carries reputational consequence internal actions don’t. 

Does it cross a segregation-of-duties boundary? If a human doing this work would require a second pair of eyes, an agent doing it requires the same — not a judgment call, since the answer is already written into your existing control framework. 

If none of the three applies, let it run and rely on the audit trail. Not everything needs prior approval, but everything needs to be reconstructable afterward. A useful sanity check on a gate live a month: look at its rejection rate. A gate that’s never rejected anything is either protecting something that didn’t need protecting, or giving reviewers too little to reject on. 

Two authors, and the temptation to build two systems 

Automation in an enterprise gets written by two different populations. 

Business users know the process — that a discrepancy over a threshold goes to the regional controller, that a particular supplier needs a manual check. They can’t write code and shouldn’t need to; they need to compose steps in a console. 

Developers need arbitrary code. Some processes are genuinely complex and can’t be expressed by assembling blocks. Constrain these people and they’ll build outside your platform — the outcome that ends every governance story badly. 

The tempting move is two systems: a friendly builder for the business, a deployment pipeline for engineering. Each is easier to build alone. It’s also how you end up with two audit trails, two approval models, and one uncomfortable meeting when someone asks which one governs the thing that just went wrong. 

The alternative keeps the authoring experiences distinct and forces both into the same governance path — the kind of unified control environment standards like ISO/IEC 42001 now formalize for AI management systems. 

A business user’s plan ships as data- They assemble it in the console, producing a structured description — steps, branches, waits, approval gates, loops — that a single interpreter executes. Nothing is generated or deployed, so a new process is a record rather than a release, reviewable as data by people who couldn’t review code. 

A developer’s code passes through a governed lifecycle before it can run- Submitted, reviewed, approved — and only then built. Approval gates the build rather than following it: unreviewed code never becomes a runnable artifact. Code is marked runnable only when a worker actually reports it can run that type of work. 

Both paths converge before anything executes: same approval model, same audit events, same permission checks. A compliance question about “our automation” has one answer instead of two. 

What this costs 

Durability is only as good as its foundation- A recorded pause depends on the store holding it — treating it as ordinary application state, rather than the system of record for what your automation is doing, is a mistake. The pattern is well-established in production-grade durable orchestration tooling for exactly this reason. 

Changed code is a new version, never an edit in place- Modifying a run already in flight produces behavior nobody can reason about. Versioning avoids this at the cost of some ceremony — the right trade, even when it annoys a developer who wanted to fix a typo. 

Compensation is a design problem, not a platform one- If step six succeeded and step seven failed, what undoes step six? Genuine rollback of a business action has to be modelled by whoever designs the process, because only they know what “undo” means for that step. A platform claiming to solve this generically is overselling. 

WHAT TO TAKE AWAY 

• A pause must be recorded state, not a running process, or your approval gate cannot survive an ordinary deployment. 
• Show reviewers the substance of what they’re approving — a content-free gate manufactures false evidence of oversight. 
• Address each approval to its specific gate so one decision can never satisfy another. 
• Support two authoring populations with two experiences and one governance spine. 
• Gate the build on approval, and mark work runnable only when something actually reports it can run. 

NEXT IN THE GOVERNED AGENT 

Part 5 — Acting As You, Not For You. An approved action still has to be performed somewhere — and the credential it uses decides whose name is on it. Next: why the shared service account is the quiet disaster in most agent deployments. 

New to the series? Start with Part 1 — The Trust Gap or catch up on Part 2 — Every Agent Needs a Name.