A team put human approval in front of every agent action. It looked safe in the workflow diagram. Within days, reviewers were clicking approve without reading because most requests were routine and the queue never stopped. The control existed, but the decision had disappeared.
Human in the loop is not a checkbox. It is the deliberate placement of judgement where evidence is ambiguous, consequences are material or recovery is difficult. Everywhere else, compulsory approval trains people to ignore the interface.
Review consequences, not model activity
The model can classify, extract, retrieve and draft without creating an external effect. Those operations need evaluation and monitoring, but not necessarily synchronous approval. The review point belongs before a consequential transition: sending a message, moving money, changing access, committing inventory, deleting data or making a decision that affects a person's rights.
Separate proposal from execution. The agent prepares a structured action containing the target, payload, supporting evidence and predicted consequence. Policy decides whether it can run automatically, needs approval or must be blocked. The person reviews that exact action. Regenerating it after approval breaks the meaning of consent.
Use risk rules that can be explained
Escalation should not depend on a vague confidence score alone. Combine observable conditions: action type, reversibility, value, recipient, novelty, permission boundary and evidence quality. A familiar low-impact update can proceed. An unusual destination, conflicting sources or missing identifier can require review even when the model sounds confident.
The NIST AI Risk Management Framework treats roles and responsibility as part of governing AI risk. That is the practical point: the reviewer must know what decision they own, what policy applies and what happens after rejection.
Do not label an entire workflow high risk and route everything to one queue. Mark the specific transitions that create risk.
Give the reviewer enough context
An approval screen should answer what will happen, why, with which evidence and how it can be reversed. Show changed fields, not a full record dump. Link to the source passages the agent relied on. Surface policy exceptions and previous related actions.
The available choices must be meaningful: approve this payload, edit it, reject it with a reason or send it to a named specialist. A generic looks good button creates no useful audit trail. Neither does approval in chat that cannot be tied to the executed operation.
Measure review quality as well as speed. Repeated overrides, rubber-stamp patterns and long queues are design signals, not merely staffing problems.
Supervision without authority is theatre
Sometimes a person is shown an action but cannot stop it. Sometimes the action executes before review and the interface calls the later inspection oversight. Sometimes reviewers lack domain knowledge or are punished for slowing throughput. These are observation systems, not approval systems.
Another form of theatre is asking a human to detect errors the interface hides. If evidence, permissions or side effects are invisible, the person is only judging prose. Good writing will pass even when the underlying action is wrong.
Redesign one approval queue this week
Choose the busiest human-review step. Sample approved, edited and rejected cases. Identify which conditions actually changed the decision. Use them to split the queue into automatic, review and blocked paths. Keep deterministic policy outside the model.
For the review path, present the exact payload, evidence and consequence together. Record reviewer identity, decision, reason and executed result. Add expiry so an old approval cannot authorise a changed state.
Then remove approval from the low-impact path and monitor it with evals and rollback instead. The goal is not fewer humans. It is to spend human attention only where judgement changes the outcome, so that an approval still means someone made a decision.