Human in the loop, where it counts
Human in the loop, where it counts, is a control pattern for agent systems that pauses automation only before actions with high cost, risk, or poor reversibility. The agent may investigate and prepare work freely, but execution of dangerous tool calls requires explicit human approval.
The problem is not that models make every action unsafe. It is that some actions have a much larger blast radius than others. Reading context, searching docs, or drafting a response can usually be retried or ignored. Deleting records, changing permissions, sending customer email, moving money, or running shell commands can create damage that is slow, costly, or impossible to undo. Treating all actions the same either creates needless friction or gives the agent too much authority.
The mechanism is an approval gate at the tool or permission boundary. The agent proposes a concrete operation with arguments, such as the resource, command, recipient, amount, or configuration change. The runtime intercepts that tool call, stores the paused state, and presents a review payload to a person. If approved, the exact action continues. If rejected, the agent receives that outcome and must choose another path or stop.
The trade-off is latency and operational overhead. A gate creates queues, reviewer load, product decisions about who can approve, and failure modes when nobody is available. Put gates everywhere and the agent becomes a slow form-filler. Put them nowhere and you have delegated accountability to a probabilistic planner. The honest rule is contextual: gate actions according to reversibility, impact, audit requirements, and the confidence you have in the surrounding sandbox.
Engineers meet this pattern when wiring agent tools, middleware, workflow engines, or permission systems. In practice, it looks like allowlisting safe tools, wrapping risky tools with an interrupt, and designing the approval screen so the reviewer can understand exactly what will happen. The gate should not be hidden in a prompt. Prompts can request caution, but enforcement belongs in code that controls whether the side effect occurs.
Common questions
- Is human in the loop the same as manually reviewing every response?
- No. That is the common misunderstanding. The point is selective interruption, not continuous supervision. Let the agent perform low-risk, reversible work automatically, then pause only when it is about to cross a boundary with real consequence: external users, production systems, credentials, money, destructive data changes, or legal commitments.
- Where should the approval check live?
- Put it around the tool call or permission boundary, not only in the model instructions. The model can be asked to be careful, but it should not be trusted to enforce its own limits. The runtime should inspect the requested action, decide whether approval is required, pause execution, and continue only after an authorised decision.
- What should an approval request show?
- Show the proposed action, the exact arguments, the target resource, the reason the agent wants to do it, and the expected effect of approving or rejecting. A vague prompt such as “approve this task” is not enough. The reviewer needs enough information to judge blast radius without reverse-engineering the agent’s whole conversation.
- How do I decide which actions need approval?
- Classify actions by reversibility and impact. If a mistake is cheap to retry, easy to inspect, and contained, automation is usually fine. If a mistake affects production infrastructure, customer-visible communication, permissions, sensitive data, money, or anything hard to roll back, add a gate. The right boundary depends on your domain and tolerance for risk.