Human-in-the-Loop Control: Where People Should Review AI Actions
Two failure modes show up constantly in agentic systems, and they’re opposites. The first: no human checkpoint anywhere, and an agent takes an irreversible action nobody meant to authorize. The second: a human checkpoint on everything, and reviewers rubber-stamp approvals so fast that the checkpoint stops meaning anything. Good human-in-the-loop design isn’t “more review” or “less review” — it’s putting review exactly where it catches real risk and nowhere else.
The Trust-Level Model
The practical starting point is classifying agent actions by reversibility and blast radius, not by how “important” they feel:
| Trust level | Example actions | Human involvement |
|---|---|---|
| Auto-approve | Read code, run tests, open a draft PR | None — fully autonomous |
| Notify-only | Comment on an issue, update a changelog | Logged, visible, no gate |
| Review-before-merge | Merge a code change into main | Async review, doesn’t block the agent from continuing other work |
| Approve-before-execute | Deploy to production, run a migration | Synchronous approval required before the action happens |
| Escalate-immediately | Delete data, modify permissions, touch secrets | Requires named approver, never auto-approved regardless of confidence |
This mirrors the governance table in Governance as Code — the trust level is the policy, and human-in-the-loop is the enforcement mechanism for the levels that need a person.
What a Good Review Checkpoint Actually Shows
A checkpoint that just asks “approve? yes/no” without context produces rubber-stamping. A checkpoint that produces genuine oversight shows the reviewer what they actually need to judge:
- The diff or action itself, not a summary of it — summaries hide the details reviewers are there to catch.
- The agent’s stated reasoning for why it chose this approach, so the reviewer is evaluating a decision, not just an output.
- What was verified automatically (tests passed, lint clean, security scan clean) so the reviewer knows what they don’t need to re-check.
- Confidence level, tying back to probabilistic interfaces — a low-confidence action deserves more scrutiny than a high-confidence one, and the reviewer should know which they’re looking at.
Sync vs. Async Approval
Not every approval needs to block the agent. Approving a PR merge can happen async — the agent moves on to other work while it waits in a queue. Approving a production deploy usually needs to be synchronous — the agent (and the deployment) is genuinely blocked until a person acts. Conflating these two is a common design mistake: making every approval synchronous turns human review into the platform’s bottleneck, which creates pressure to approve faster and more carelessly, which defeats the point.
The Override Path Matters as Much as the Approval Path
A human-in-the-loop system needs a clean way for a person to say “stop, this is wrong” mid-task, not just approve or reject at the end. If the only human touchpoint is a final yes/no on completed work, problems that should have been caught at step 2 don’t surface until step 8, after more time and cost has already been spent.
Calibrating Over Time
Review fatigue is a real, measurable failure — track approval latency and approval rate over time. If a checkpoint has a 98% approval rate and reviewers are approving within seconds, that’s usually a signal the checkpoint is miscalibrated (too much low-risk work is routed through it), not that the agent has gotten reliable enough to trust blindly. Recalibrate what’s auto-approved based on that data, and reserve human attention for the actions and confidence bands where it actually changes the outcome.