Human-in-the-loop.
The dangerous question is never "is the agent smart enough to act alone?" — it is "what happens the one time it is wrong, and can anyone catch it before the damage is done?" This entry defines human-in-the-loop as an engineering choice about where you place a human checkpoint, shows how to decide which actions get one, and names the way the checkpoint quietly stops working.
A spectrum, not a switch.
"Human-in-the-loop" (HITL) is often said as if it were the opposite of automation. It is not. It is a design decision about how much a human is involved at which moments, and it sits on a spectrum:
- Human-in-the-loop. The agent pauses and waits for a person to approve (or edit, or reject) a proposed action before it executes. The human is on the critical path.
- Human-on-the-loop. The agent acts by default, but a person monitors and can intervene, pause, or override. The human is a supervisor, not a gate.
- Human-out-of-the-loop. Full autonomy — the agent acts with no per-action human involvement, and oversight (if any) is after the fact.
The mistake is treating this as one global setting for the whole agent. A well-designed agent is in the loop for the few actions that can cause real harm and out of it for the many that cannot — in the same run. Which is why HITL is really a question about individual actions, closely related to the autonomy levels ladder: the right rung is chosen per action, not per agent.
Gate on consequence, not on every step.
The single most useful heuristic: put a checkpoint where an action is high-impact or hard to reverse, and nowhere else. Two properties decide it — how bad the worst case is, and whether you can undo it.
- Require approval for consequential, irreversible write actions: sending a message or email, making a payment, deleting data, deploying code, merging a change, posting publicly, anything that touches money, external parties, or production.
- Let it run for cheap, reversible actions: reading, searching, summarizing, drafting a proposal the human will see anyway. Gating these adds friction and buys almost no safety.
A clean default for anything that writes to the world is propose, don't execute: the agent produces the exact action it wants to take — the drafted email, the diff, the transaction — and a human turns it into a real effect. That single boundary converts an autonomous actor into a fast assistant whose mistakes stay drafts. Deciding whether the task even needs an agent comes first; deciding which of its actions need a human comes next.
The patterns that implement it.
A handful of concrete shapes cover almost every case:
- Approval gate. The agent pauses, surfaces the proposed action with the context and the reason, and waits. The human approves, edits, or rejects, then the loop resumes. The quality of the gate is the quality of what it shows.
- Confirmation UX. Make the decision informed and fast: show exactly what will happen (the concrete diff, the recipient, the amount), not a vague "the agent wants to proceed." A person who cannot see the consequence cannot meaningfully approve it.
- Escalation / handoff. The agent detects that it is out of its depth — low confidence, an out-of-policy request, repeated failure — and hands control to a human instead of pushing on. Knowing when to stop is a capability, not a failure.
- Reversibility over approval. When you can make an action cheap to undo (soft-delete, a staging step, an "undo" window), you can sometimes let the agent act and skip the gate entirely — the human catches problems after, at no per-action cost.
Approvals and undo are two ways to bound the blast radius; automated guardrails are a third. The strongest designs layer them — cheap automated checks handle the obvious cases so the scarce human attention is spent only on the genuine judgment calls.
How the checkpoint quietly fails.
A human-in-the-loop is not safety by default — it is a mechanism that can rot, and it rots in predictable ways:
- Rubber-stamping / approval fatigue. Ask a person to approve too many low-stakes actions and they stop reading and click "yes" reflexively. The checkpoint is now theater: it adds latency and a false sense of safety while catching nothing.
- Automation bias. People over-trust a confident-looking proposal, especially from a system that is usually right. The rare wrong one sails through precisely because the previous hundred were fine.
- Throughput. A human on the critical path bounds how fast and how much the agent can do. That cost is worth paying for consequential actions and wasteful for trivial ones — which is the whole argument for gating sparingly.
An approval you always click "yes" on is worse than no approval at all: it costs time and manufactures confidence without adding oversight. If a gate is never exercised — nobody ever rejects — that is a signal to remove it or make it rarer and higher-signal, not to congratulate the agent.
The takeaway mirrors the rest of agent design: match the level of human involvement to the stakes of each action, keep the few gates you have worth a human's full attention, and treat oversight as something you engineer — with the failure modes in mind — not something you assume. The wiki's approval & confirmation UX and progressive-autonomy playbooks take these patterns into production detail, and the decision-receipts & audit deep-dive covers proving, after the fact, what was approved and why.