Use human-in-the-loop AI when a person must approve an action before it happens. Use human-on-the-loop AI when a bounded system can act while a person monitors results and can intervene. The choice should follow the consequence, reversibility, and detection time of the action—not a target automation percentage.
The terms are not used consistently across every organization or product. Define them in your own operating policy before design or procurement. This article uses human-in-the-loop (HITL) for approval before execution and human-on-the-loop (HOTL) for monitored execution inside pre-approved limits. Neither mode gives an AI system authority by itself.
Hapy’s AI automation guide explains the wider workflow architecture. This guide answers the narrower control question: where should a person sit in relation to one proposed action?
Choose the mode at the action boundary
Do not assign one review mode to an entire agent. Assign it to each action the system can propose. A support agent may route a ticket without waiting, pause before sending a reply, and be prohibited from changing account access. The same agent can therefore contain monitored, reviewed, and denied actions.
Use this decision matrix as a starting point:
| Action condition | Default mode | Why |
|---|---|---|
| High consequence or hard to reverse | Human in the loop | A person checks the exact action before the system commits it. |
| Reversible, low-impact, and quickly detectable | Human on the loop | The system can act within limits while an operator monitors exceptions and outcomes. |
| Unclear policy, missing evidence, or unknown target | Stop and escalate | A review screen cannot repair missing authority or context. |
| Prohibited by policy or outside the workflow’s purpose | Deny | Human approval must not become a way around a hard rule. |
The NIST AI Risk Management Framework Core calls for policies that define roles and responsibilities for human-AI configurations and oversight. It also assigns responsibility for disengaging or deactivating systems that operate outside their intended use. That makes the review mode an ownership decision, not only a user-interface feature.
Use human in the loop for consequential commitments
HITL fits an action that should remain pending until a named reviewer accepts, edits, or rejects it. Typical examples include sending an external message, initiating a refund, changing account access, approving a contract exception, publishing content, or writing to a system of record when an incorrect change would be costly.
The useful unit of approval is the exact proposed action. A reviewer should see:
- the target person, account, record, or system;
- the proposed content or normalized parameters;
- the source material and policy that support the proposal;
- what will change if the reviewer approves;
- whether the action is reversible and how;
- the approval expiry time and the fallback on timeout.
OWASP’s AI Agent Security Cheat Sheet recommends explicit approval and an action preview for high-impact operations. For destructive, financial, administrative, or externally visible actions, it also recommends binding approval to the actor, tool, target, normalized parameters, timestamp, and expiry. If the amount, recipient, message, or account changes after approval, the old approval must not authorize the new action.
An approval queue also needs a negative path. Denial should leave the action unexecuted. An expired request should fail closed or move to a defined escalation queue. It must not become an automatic approval because nobody answered.
Use human on the loop only inside a bounded operating area
HOTL is not “the agent runs and somebody watches a dashboard.” The system needs a narrow action set, measurable limits, timely signals, and an intervention that can stop or reverse the work before harm spreads.
It can fit tasks such as routing ordinary requests, adding low-risk internal labels, scheduling a reminder, or drafting a non-binding internal summary. The system may perform these actions without individual approval when all of these conditions are true:
- The action is allowed by a written policy and scoped permissions.
- An error is reversible or has a small, contained effect.
- Monitoring can detect failure soon enough to matter.
- A named operator has time, access, and authority to intervene.
- Rate, volume, value, and target limits prevent one error from becoming a batch incident.
Monitoring should combine event-level alerts with sampled review. Alerts catch known failure conditions, such as an unusual refund amount or a sudden rise in denied tool calls. Sampling can expose quality drift that no rule anticipated. Neither is useful if the operator cannot trace an alert to the input, proposed decision, executed action, and applicable policy.
Work through one support workflow
Consider a hypothetical customer-support workflow. The AI reads an incoming message, selects an approved help article, proposes a reply, and may update the case. This is an example design, not a reported Hapy result or a universal risk classification.
| Workflow action | Review mode | Timeout or intervention rule |
|---|---|---|
| Classify the request and add an internal queue label | Human on the loop | Allow only known labels. Alert on an unusual error rate or volume spike. Let an operator correct the label. |
| Draft a reply with visible source links | Human in the loop | Do not send until the reviewer accepts or edits the exact recipient and message. Expire the request at the end of the shift. |
| Add an internal note from validated fields | Human on the loop for a narrow pilot | Sample notes and allow correction. Stop automatic notes if required fields or source references are missing. |
| Issue a refund | Human in the loop | Show the account, order, amount, reason, and policy. Changes require a new approval. Timeout leaves the refund pending. |
| Change account access or export customer records | Deny in this workflow | Route to a separate authorized process. A support reviewer cannot expand the agent’s permissions. |
This table is more useful than a rule such as “review low-confidence outputs.” Model confidence does not measure business consequence, and an attacker may try to influence a score or threshold. Policy should classify the action before model output reaches the execution layer.
The related AI agent governance guide shows how to record allowed, reviewed, and denied actions in an agent charter. This comparison determines which of those reviewed or monitored paths fits each action.
Design the pause, resume, and replay behavior
A human approval step changes the workflow’s technical state. The system must persist the pending action, associate it with one workflow instance, and resume the correct version after a response.
LangGraph’s interrupt documentation provides one implementation example: an interrupt pauses execution, saves graph state through a checkpointer, and resumes later with external input. Its guidance also warns that code before an interrupt can execute again when a node resumes. Whatever platform you use, test duplicate prevention and make pre-approval side effects idempotent where possible.
Define these states explicitly:
| State | Required behavior |
|---|---|
| Pending | Store the exact proposal, policy version, reviewer scope, and expiry. Do not perform the gated action. |
| Approved | Validate that the target and parameters still match, then execute once and log the result. |
| Edited | Treat the edited proposal as a new action. Re-run validation and require approval again when the change is material. |
| Rejected | Record the reason and leave the action unexecuted. Route for correction only when policy permits it. |
| Expired | Fail closed or move to a named escalation queue. Do not silently continue. |
| Cancelled or stopped | Prevent later replay and show the operator which earlier actions completed. |
Test the unhappy paths: the reviewer closes the browser, two reviewers respond, the request expires, the target record changes, execution succeeds but the acknowledgement fails, or the workflow restarts after approval. A polished approval card does not make these cases safe.
Measure whether the review design works
HITL can create a queue that is too slow to operate. HOTL can create an illusion of oversight when the operator sees problems after the damage is complete. Measure both control quality and operating cost.
Useful measures include:
- pending volume, age, timeout rate, and escalation rate;
- approval, edit, and rejection rates by action class;
- execution failures and duplicate-action attempts after approval;
- sampled error rate for monitored actions;
- time from anomaly to detection, intervention, and recovery;
- reviewer workload and the share of cases without enough evidence to decide.
Do not use a falling rejection rate alone as proof that the system is safer. Reviewers may be fatigued, the queue may hide useful context, or risky cases may have shifted into the monitored path. Compare decisions with sampled outcomes and incident evidence.
Make one action-level control map
Start with one real workflow. List every action the AI can propose, not only its tools. For each action, record the consequence of error, reversibility, detection time, allowed targets, volume limit, reviewer, timeout, escalation, rollback, and evidence retained.
Keep approval before execution for high-consequence commitments. Use monitored execution only where limits and recovery are real. Deny actions that the workflow does not need. If your team is still deciding which layer should interpret, control, execute, or review the work, use the AI automation versus RPA guide first.
Hapy’s Business Systems & Automation service can help map the workflow and build the approval, monitoring, and recovery paths. Hapy offers that service, so treat it as an implementation option rather than independent evidence that your workflow needs custom AI.
