Key takeaways
- An approval workflow is a durable state transition, not a message with buttons. The run must stop in a named state that survives restarts and can resume exactly once.
- Show the proposed action, supporting evidence, policy or threshold, consequences and alternatives in the approval payload. A bare approve button invites guesswork.
- Define approve, edit, reject, expire and escalate before launch. Rejection is a normal branch with an owner, not an error that strands the run.
- Bind the decision to the exact proposal with an immutable identifier or hash. If the payload changes, the prior approval no longer applies.
- Measure override rate, expiry rate and decision time per gate. Volume alone cannot tell you whether the gate catches anything or merely adds latency.
Write the state-transition contract before choosing a pattern
The parent human-in-the-loop guide decides which actions need a person and whether that gate is temporary or permanent. This page starts one level lower: the action already deserves review, and the runtime has to stop without losing its place.
Google Cloud's architecture guidance describes the core pattern as a predefined checkpoint where an agent pauses and an external system waits for human review. The word “waits” carries most of the engineering work. The pending state must survive a restart, late decision and duplicate notification.
| Field | Decision to write down |
|---|---|
| Pending state | The durable state name and exact point before execution |
| Proposal | Action, target, normalized payload, evidence and immutable proposal ID |
| Authority | Eligible roles, delegation rules and separation constraints |
| Outcomes | Approve, edit, reject, expire, cancel and escalate destinations |
| Time | Decision deadline, reminder cadence and expiry owner |
| Resume | Single-use token or idempotency key and the next step for each outcome |
| Record | Request, presentation, decision, actor, time, changes and execution receipt |
Five runtime patterns and the process shape each one fits
| Pattern | Pause point | Best fit | Characteristic risk |
|---|---|---|---|
| Preflight plan approval | Before any state-changing step | A short, bounded plan whose steps are visible together | Approval becomes stale when the plan changes |
| Step-up action approval | Immediately before one tool call | Most work is safe; one send, update or release is consequential | Too many step gates fragment the reviewer's context |
| Exception approval | When deterministic rules cannot route the case | Stable normal path with named unknown or conflict states | Loose exception rules either hide cases or flood the queue |
| Two-person approval | Before an action requiring separate duties | Payments, credential changes or other internally controlled actions | Two clicks from the same chain of influence are not independent |
| Time-boxed review with rollback | Immediately after execution, before rollback expires | Reversible internal changes where speed matters | The supposed rollback may not reverse external effects |
Preflight and step-up approval solve different context problems
Preflight approval lets the reviewer see the whole intended path: “read these cases, update these three fields, then draft a reply.” Bind the decision to a plan version. If later evidence changes a destination, amount or action, the runtime returns to pending rather than treating the old approval as a blank cheque.
Step-up approval leaves harmless work running and pauses only at a consequential action. The review screen needs enough prior context to decide without replaying the full run: source facts, policy result, proposed payload, effect, alternatives and the reason this gate fired. Keep the pending proposal immutable; an edited proposal creates a new version before execution.
Exception and two-person patterns need explicit ownership
An exception gate is cheaper than reviewing every normal case, but only if “exception” is a written state. Missing required data, conflicting sources, unknown category, policy denial and exhausted retries are examples. Give each state a queue, owner and deadline. An unrecognized case must fail toward the queue, never around it.
Two-person approval adds a constraint: the second decision must come from a distinct authorized identity, and often from a different role. Record both decisions against the same proposal. If the first approver edits it, the second sees the revised version; if the second changes it, the first decision is stale and the sequence restarts.
- 01Create one immutable proposalCodeNormalize the action and calculate the proposal hash before notifying anyone.
- 02Resolve eligible reviewersCodeExclude the initiator and enforce required role or department separation.
- 03Collect decisions in orderHuman approvalShow the same current proposal and invalidate prior decisions after any material edit.
- 04Execute onceCodeConsume a single-use authorization and retain the destination receipt.
Design rejection, expiry and retry as normal branches
Approval is not the only successful outcome. A rejection may close the case, request corrected inputs, return work to the proposing step or hand the job to a person. The reviewer should choose from clear outcomes and may add context; they should not have to open a separate system to keep the process moving.
Expiry must not silently become approval. Mark the proposal expired, revoke its resume token and route to a named owner. Escalation may notify a delegate, but it must not widen the set of actions or preserve an approval beyond a changed payload.
Retries happen after ambiguous network failures. Before sending again, read the destination using the same idempotency key or external reference. A durable approval state prevents the model from rebuilding a slightly different proposal after restart and losing the original decision.
Measure whether each gate earns the attention it consumes
NIST's current monitoring work notes that human review does not scale automatically with deployment volume. Measure the gate as its own process. The useful signals are decision time, edit or rejection rate, expiry rate, escalation rate, repeat submissions, post-approval failures and incidents that the gate should have caught.
| Signal | Question to investigate |
|---|---|
| Near-zero edit and rejection rate | Is the gate unnecessary, or are reviewers rubber-stamping? |
| Rising expiry rate | Is ownership wrong, payload context weak or volume too high? |
| Repeated edited proposals | Can a deterministic rule capture the correction earlier? |
| Long decision time on one tier | Does that tier need a different reviewer pool or earlier evidence? |
| Post-approval execution failures | Is idempotency, authorization or destination validation broken? |
Limitations and when not to use this
- A human gate cannot make an unsafe action safe when the reviewer lacks authority, context, time or a real ability to reject it.
- Post-action review belongs only where rollback is complete and tested. Messages seen by people, disclosed data and many financial or physical effects are not truly reversible.
- These patterns define workflow behavior, not sector-specific approval obligations. Finance, employment, healthcare and regulated uses need the relevant practitioner and legal review.
Sources
- Choose a design pattern for your agentic AI system — Google Cloud Architecture Center Accessed 29 July 2026
- Challenges to the monitoring of deployed AI systems — NIST Accessed 29 July 2026
- AI Risk Management Framework Core — NIST Accessed 29 July 2026
Write the state transition contract
For one consequential action, name the pending state, payload, decision roles, expiry, rejection destination and idempotency key before drawing the happy path.
Write the state transition contractUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.