Almost every AI governance conversation ends at the same place: “there’ll be a human in the loop.” Everyone nods, and the meeting closes. What nobody designs is the loop itself, which is where the whole idea either works or degrades into a button people press.
A human-in-the-loop step is a real control only when rejection is a live possibility. That sounds obvious and it is routinely violated, because the reviewer is handed an item that gives them nothing to reject on.
What a reviewer needs in order to say no
An approval item must contain the exact action, every parameter it will execute with, the record it targets, and the agent’s own reasoning trace. Anything less and the reviewer is approving a category of action rather than an action.
The reasoning trace is the part most often reduced to a summary, and the reduction is the problem. A summary is a text the agent generated about its own behaviour, which means the reviewer is asking the model to audit itself. A trace is different in kind: each step records what the agent was reasoning, which tool it selected, the parameters it proposed, and what that tool actually returned. Reading a trace is reading what happened. Reading a summary is trusting a précis.
| What the queue shows | What a reviewer can catch | What slips through |
|---|---|---|
| Action name only (“Send email”) | Nothing beyond wrong action type | Wrong recipient, wrong amount, wrong tone, wrong record |
| Action plus a model-written summary | Obvious category errors | Anything the summary smoothed over, including the reason the agent was wrong |
| Action plus full payload | Wrong recipient, wrong figures, wrong record | A payload that is correct but based on a misread observation |
| Action, payload and full reasoning trace | All of the above, plus the bad inference | Genuine judgement disagreements, which is the correct residual |
The bottom row is the target. The residual failure in a well-built queue should be honest disagreement about judgement, not surprise about facts.
The failure case: forty approvals in three minutes
Here is what rubber-stamping actually looks like in practice, because it does not announce itself.
A finance team turns on an agent to chase overdue invoices, set to approve. The queue fills overnight with forty items, each reading “Send payment reminder to” and a customer name. The reviewer opens the queue at 9 a.m. with a full day ahead, sees forty near-identical rows, and approves all of them in about three minutes. Thirty-eight are correct. Two are customers who paid by bank transfer the previous afternoon against an invoice that has not yet been matched, and both get a reminder for money they have already sent.
Nothing in that story is an AI failure. The agent reasoned correctly from the data it could see. The failure is queue design: the item did not surface the one field that would have caught it, which is the payment status of the invoice at the moment of proposal, and the batch was large enough and uniform enough to be processed as a single decision rather than forty.
Two design fixes follow directly. Put the decisive field in the item, not one click away. And treat a large uniform batch as a signal that the agent should be evaluated at the batch level rather than reviewed at the item level, because a human presented with forty identical-looking rows will behave as though there is one.
Rejection rate is the health metric
The number that tells you whether human-in-the-loop is working is the rejection rate per agent, tracked over time. It has three readings and only one of them is fine.
- Falling toward zero and staying there, with spot-checks confirming the approvals were right. The agent has earned promotion for that action class. Leaving it at approve is now costing you review time for no risk reduction.
- Zero from the start, with spot-checks finding errors. The queue is theatre. Fix the item before you fix the agent.
- Persistently high. The agent is misconfigured, under-scoped or pointed at work it cannot do. More review will not fix it.
Notice that two of the three readings end with the approval step being removed or replaced. An approval queue is a measuring instrument as much as a control, and its output should eventually change the configuration. A queue that never changes anything is overhead. The promotion logic sits in the three autonomy levels.
Latency, and where approval is simply the wrong tool
An approval step costs one review interval of latency. Not the agent’s runtime: the gap between times a human opens the queue. A queue worked twice a day has a worst case around twelve hours.
That number decides the design. Twelve hours is nothing for a collections chase, a purchase-order draft or a reconciliation match. It is fatal for anything a customer is waiting on. This is why approval belongs per action class rather than per platform, and why a live conversation needs a different mechanism entirely, usually a narrower tool grant and a drafted reply a human sends rather than a queued action a human authorises. Running a two-channel support operation covers where that line falls in practice.
Approval is also the wrong tool when the reviewer has no independent basis for judgement. If the only information available to the reviewer is the information the agent already used, and the reviewer has no domain knowledge the agent lacks, the approval adds latency and a signature without adding accuracy. In that situation you want a second check of a different kind: a validation rule, a threshold, or simply a decision that this work is not ready to automate. When not to automate is a real answer, not an admission of defeat.
The mechanics that decide whether approval means anything
Three implementation details separate a real approval from a rendered one.
The approval must be a durable record, not a paused process. A process holding its breath in memory dies on the next deploy and takes the pending decision with it. A queued row survives restarts, and it can be read, counted and audited.
Approving must be what executes. If the agent acts and then asks, the queue is a notification feed. The dispatch should happen inside the same transaction that records the approval, so a failed dispatch rolls the decision back rather than leaving an action marked approved that never occurred.
Expiry must fail closed. An item nobody touches must expire without executing. The alternative, where a timeout releases the action, converts inattention into consent, which is the single worst default in this entire design space.
How Oneop builds the queue
In Oneop, an agent set to approve turns its proposed action into a durable queue row with the full payload attached, and that row expires after forty-eight hours if nobody touches it. Approving is what executes the action, inside the same transaction that records the approval. The reviewer sees the run’s complete reasoning trace, because every step stores the agent’s reasoning, the tool it chose, the parameters it proposed and what came back.
Rejecting a queued agent action records the decision, who made it, when, and their notes against that action. One boundary worth knowing before you design around it: rejecting an approval raised by the automation engine does not currently leave an execution record. Same word, two different trails, which is why the AI governance page shows the boundaries instead of one summary sentence.
Underneath all of it sits a check an approval cannot satisfy. Money and stock actions are refused at the single dispatch point while that class is switched off, and the refusal holds even after a person has approved the item, because the lock sits below the approval rather than beside it. Full detail on the queue and the trace is on the AI agents page.
Build the queue so that saying no is easy, then watch how often anyone does. That number is your governance programme.