Human-in-the-loop (HITL) is an architectural pattern in which an AI system pauses for human review or approval before taking specified actions, or escalates to a reviewer when confidence falls below a threshold. It pairs with runtime intervention controls that can allow, stop, or adjust an agent's action.
- An AI system pauses for human approval before specified actions
- Full autonomy is fast and accepts the failure modes; full review does not scale
- The mature pattern is selective, gated on action class or blast radius
- Regulatory frameworks expect human oversight for high-risk decisions
Why is human-in-the-loop important?
Human-in-the-loop matters because it is the operational answer to the question of what stops an autonomous agent taking a catastrophic action. Every organization deploying agents arrives at that question, usually shortly before the deployment is due to expand.
The two simple answers both fail. Pure autonomy is faster and accepts the failure modes, which is defensible for low-consequence work and indefensible for anything irreversible. Pure manual review is safe and does not scale – a team that approves every agent action has built a slower version of the process the agent replaced.
The mature pattern is selective. Human approval is gated on action class, blast radius, or model confidence, so judgment is spent where judgment is needed and the remainder runs automatically. That selectivity is what makes the pattern viable at scale rather than a bottleneck with a governance label on it.
Regulation reinforces it. Article 14 of the EU AI Act sets human oversight expectations for high-risk systems, and demonstrating those expectations were met requires a record of what was escalated and what a reviewer decided.
What is human-in-the-loop?
Human-in-the-loop is a design pattern placing a person in an AI system's decision path at defined points. The system proceeds autonomously until it reaches one of those points, then waits.
Two triggers are common. Action-based triggers fire on what the system is about to do – a category of operation designated as requiring approval regardless of context. Confidence-based triggers fire on how certain the system is, escalating when a score falls below a threshold. Action-based triggers are more predictable and easier to audit; confidence-based triggers catch cases nobody anticipated.
The pattern is often confused with two adjacent ones. Human-on-the-loop describes a person monitoring an autonomous system with the ability to intervene, without being in the path by default. Human-in-command describes ultimate authority resting with a person, without implying per-action review. Only human-in-the-loop actually blocks progress pending a decision, which is why it is the one with a latency cost.
What makes it work is threshold design. Set the gate too broadly and reviewers rubber-stamp; too narrowly and consequential actions pass unseen.
Types of human-in-the-loop patterns
Patterns divide by what triggers the pause and by what the reviewer is asked to do.
By trigger, action-class gating designates operation types requiring approval – writing to production, sending external communication, moving funds, changing permissions. Blast-radius gating escalates based on scope of effect, so the same operation is approved at one scale and gated at another. Confidence gating escalates when the system's own certainty is low. Policy-exception gating escalates only when an action falls outside defined policy, which keeps volume lowest.
By reviewer task, approval asks a binary question. Modification lets the reviewer adjust the action before it proceeds, which produces better outcomes and demands more context. Verification asks the reviewer to confirm the system's reasoning rather than the action itself, which suits decisions where the output is hard to evaluate directly.
Most mature deployments combine policy-exception gating for volume with action-class gating for the irreversible set.
Human-in-the-loop & Onyx
Onyx supports human-in-the-loop intervention through Ask actions on destructive and high-risk operations. Ask is one of the five runtime enforcement actions alongside alert, block, mask, and steer, which means escalation to a person is a policy outcome rather than a separate workflow.
Current availability is specific and worth stating rather than generalizing: Ask actions are available for Claude Code Hooks, across destructive action, data exfiltration, and tool restriction categories. That scope reflects where the integration exists today rather than the limit of the pattern.
Because escalation is a policy decision, the record of what was escalated and what the reviewer decided lives alongside every other enforcement decision – which is the artifact Article 14 oversight obligations actually require. AI Governance is where those thresholds are authored.
