“Human in the loop” sounds reassuring. In practice, it can mean a stream of identical approval cards that trained reviewers clear as quickly as possible.
A person clicked a button, but did they understand the decision? Could they see what changed? Were they the right person to approve it? Would a rejection have stopped the action?
Oversight is not a checkbox. It is a product and operating-system design problem.
Review only where judgment changes the outcome
Requiring approval for every tool call creates noise. Approving nothing creates exposure. The useful middle is risk-based routing.
Escalate when the action crosses a meaningful boundary, such as:
- —sending information outside the organization;
- —accessing or changing sensitive records;
- —exceeding a financial or volume threshold;
- —entering a production environment;
- —taking an irreversible action;
- —operating with low confidence or conflicting evidence;
- —invoking an exception to policy.
Low-risk, reversible, well-tested actions can remain observable without requiring synchronous approval. High-consequence actions should pause before the effect occurs.
Design the decision, not the dashboard
An approval surface should answer five questions quickly:
- —What is the agent proposing to do?
- —Why is review required now?
- —What evidence supports the proposal?
- —What will change if I approve?
- —What happens if I reject or do nothing?
Lead with the decision and consequence. Put raw traces and payloads behind progressive disclosure. Reviewers should not need to interpret a wall of JSON to understand the request, but they must be able to inspect the source evidence when needed.
Show differences, not just final values. For a record update, present before and after. For an external message, show the recipient, classification, attachments, and final text. For a policy exception, show the rule, rationale, scope, and expiry.
Preserve reviewer independence
The agent owner should not automatically approve the highest-risk actions of their own agent. Separation of duties matters when the review is supposed to challenge the system.
Route by action and expertise. Security can review an unusual data transfer; finance can review a payment threshold; a domain specialist can review a regulated recommendation. Make delegation explicit and record who made the final decision.
Make every outcome useful
Approval, rejection, request-for-change, timeout, and escalation should all be first-class outcomes.
Capture the reviewer, timestamp, evidence viewed, decision, rationale, and any edits. Bind the approval to the exact proposed action so the agent cannot materially change the payload after approval. If the proposal changes, review it again.
Rejections are valuable operational data. They reveal unclear policy, poor context, weak agent behavior, or an incorrect review threshold. Feed those patterns into evaluation and control design.
Measure review quality
Queue size alone says little. Track the time to decision, rejection and edit rates, repeated escalations, expired requests, reviewer concentration, and incidents that occurred despite approval.
Also look for rubber-stamping: near-instant approvals, one reviewer clearing unrelated domains, or high-risk actions approved without opening evidence. These signals do not prove poor review, but they identify where to investigate.
Human oversight works when the reviewer has authority, context, and time to change the outcome. Anything less is approval theater with an audit timestamp.