Human-in-the-Loop AI: Where the Approval Gate Belongs

Human-in-the-loop AI and agentic autonomy are not two different types of systems. They are two operating modes within the same system, selected based on the action being performed. The key design question in agentic AI is which actions require human approval before execution.

This question can be evaluated using measurable criteria. A 2023 Frontiers in Psychology study of 93 people making AI-assisted hiring decisions found that informing reviewers that the system could make errors was associated with more detailed review of its output. Informing reviewers that they were responsible for the outcome did not produce the same change.

By the end of this article, you will have a rule for placing approval gates, four measures for evaluating whether a gate is working, and a framework for deciding when one can be removed.

Questions this Article Answers

What is the Difference between Human-in-the-Loop, Human-on-the-Loop and Human-out-of-the-Loop?

Human-in-the-loop means a person approves an action before the system executes it. Human-on-the-loop means the system executes the action while a person monitors it and retains the ability to intervene. Human-out-of-the-loop means no person is part of the execution process, and any review occurs afterward or may not occur at all.

A 2026 systematic review of human-in-the-loop AI in Entropy (Lazaros, Vrahatis and Kotsiantis, 26 March 2026) organizes these systems across three dimensions: loop placement, interaction granularity, and timing. Loop placement receives significant attention, while granularity and timing also play an important role in system design.

A fourth term appears in the research literature and can be confused with these approaches. AI-in-the-loop, sometimes written AI2L, describes the inverse arrangement: the person makes the decision and the system provides assistance. Cheng and Cheng distinguish between these arrangements, which is important because systems described as human-in-the-loop may sometimes function more like AI-in-the-loop.

The important distinction is that these are properties of an action, not necessarily of an entire system. A production agent can use different modes at the same time, such as requiring approval for outbound customer messages, monitoring internal classifications, and allowing read-only lookups to operate without approval. Selecting one mode for an entire product can therefore create unnecessary limitations or risks.

Where does the Approval Gate Belong in an Agent Workflow?

The gate should be placed at the step that introduces an irreversible external effect, rather than at the beginning or end of the workflow. Gate the action, not simply the output. A model generating a draft can usually be changed or discarded. A system sending that draft to a customer creates an external effect that may not be reversible.

• The EU AI Act applies this principle of proportionality by requiring oversight measures to reflect the risks, level of autonomy, and context of use. Article 14(3)
• The NIST AI Risk Management Framework (2023) treats human oversight as an operational requirement: MAP 3.5 calls for human oversight processes to be defined, assessed, and documented.

Gate the action, not simply the output.

A common design issue is placing the gate at the wrong layer. Teams may add a review step to the model output because that is where the AI is most visible, while the agent may have already written to a system of record, triggered a webhook, or sent a notification earlier in the workflow. Trace the workflow to identify the first point of external effect. That is where the gate should be considered.

Which Agent Actions should Never Run Unattended?

Actions that are irreversible, externally visible, or have significant legal or business consequences generally require human approval before execution. Examples can include sending communications to customers, moving money, writing to a system of record, deleting data, publishing content, or making commitments on behalf of the company.

Regulatory guidance also emphasizes the ability to intervene or interrupt AI systems when necessary. EU AI Act Article 14(4)(e) addresses the ability to intervene or interrupt through appropriate mechanisms. Article 14(5) includes additional requirements for certain biometric identification systems. NIST MANAGE 2.4 calls for assigned mechanisms to supersede, disengage, or deactivate a system when its behavior is inconsistent with its intended use.

This is the practical foundation of AI agent guardrails: constraints should be enforced before an action is executed rather than described only in a policy document.

One clarification is important: irreversible means irreversible to the business, not necessarily to the database. A database record may be technically reversible, but the action may not be reversible if it has already triggered an email to a customer. The relevant test is whether the action has created an external effect that cannot reasonably be undone.

How do you Decide when an Agent is Confident Enough to Act Alone?

An LLM’s reported confidence should not automatically be treated as the probability that its response is correct. Using such confidence as the only basis for an approval threshold can result in incorrect actions being treated as reliable. A better approach is to calibrate decisions against actual outcomes: establish thresholds for different action classes based on how often people approve, edit, or reject the system’s proposals.

The Entropy review identifies trust calibration as one of the key challenges in deploying human-in-the-loop AI, alongside scalability and cognitive load. Calibration concerns the difference between how reliable a system is and how reliable the person supervising it believes it to be. Managing that difference is important for effective oversight.

The practical approach is gradual. Start with approval for each class of action. Record how often reviewers approve, edit, or reject the proposed action. Consider removing the gate only for action classes where the edit rate remains consistently low and the potential impact of an incorrect action is limited. The ability to act independently should be earned through evidence for each action class and should remain reversible.

What does an Approval Queue Actually Look like in Production?

An approval queue is a structured workflow, not simply a notification or popup. Each item should show what the system proposes to do, why it proposed the action, what will change if it is approved, and provide options to approve, edit, reject, or escalate. Editing is particularly valuable because it captures the reviewer’s correction rather than discarding the work.

The Approval QueueAn approval queue is a structured workflow,not simply a notification or popup.Approve·Edit·Reject·Escalate

Cheng and Cheng (arXiv, 24 April 2026) propose treating human oversight as an independent system component within the agent operating environment rather than embedding approval logic separately into every workflow.

Their framework separates four concerns:

• WHEN intervention is triggered
• WHO is the appropriate reviewer
• WHAT responses are available
• WHERE the request is routed

That paper is conceptual and does not report empirical results, but this separation provides a useful way to structure oversight.

The systems we run use this approach for human-in-the-loop automation, with the AI approval workflow positioned between the agent and the customer. Stella drafts customer outreach and routes it for approval. Pursuit selects the channel and message for each lead and then places it in a review queue, which is the pattern described in AI agents for sales. AISEO Manager identifies a weak page, drafts a potential improvement, and holds it behind an approval gate.

What does an Approval Gate Cost in Speed, and when is that Worth Paying?

An approval gate does not add compute cost in the traditional sense. Its primary cost is queue latency: the time an action waits for a person to review it. This cost can be measured and managed. The potential cost of an incorrect action can be less predictable.

The best way to evaluate this cost is to measure it rather than estimate it. Track the time between the agent creating a proposal and the reviewer making a decision. Examine the distribution rather than only the average, because the average may hide longer delays. A gate whose decisions are generally completed within the required operating period can be incorporated into the workflow. A gate without measured performance is difficult to evaluate objectively.

The trade-off is generally worthwhile when the potential impact of an incorrect action is greater than the cost of review. For outbound customer communication, even a single incorrect message can create an external impact that cannot be fully recalled. For internal classifications that have no direct external effect, the same level of review may not be necessary.

How do You Stop a Human Gate Becoming Rubber-Stamping?

Rubber-stamping can become a significant risk when reviewers repeatedly see accurate system outputs and begin approving them without sufficient review. In that situation, the system may continue to record human approvals even though meaningful oversight has declined. Designing the review process carefully is therefore essential.

Research on human oversight has identified limitations in how people perform review tasks, particularly when they rely too heavily on automated recommendations. The EU AI Act also addresses automation bias by requiring appropriate awareness of the tendency to over-rely on system output in relevant oversight contexts.

The Frontiers in Psychology study cited at the beginning of this article found that informing reviewers that an AI system could make errors was associated with more detailed inspection of its output. The study focused on AI-assisted hiring decisions rather than agent outputs, so the findings should not be treated as directly applicable to every AI workflow. However, they illustrate the importance of designing review processes that encourage meaningful evaluation rather than relying only on accountability requirements.

The design implication is straightforward: give reviewers useful information about where the system may be wrong and provide enough context to evaluate the proposed action. Accountability alone does not guarantee effective oversight.

What Breaks when You Add a Human to a Multi-Agent System?

State management is one of the first challenges. An agent that pauses for approval must suspend execution, preserve its context, and resume without repeating decisions it has already made. In a multi-agent system, downstream agents may also be waiting, and their inputs may become outdated while approval is pending. Where those boundaries sit is decided earlier, in the agentic AI architecture itself.

The Entropy review identifies scalability and cognitive load as important challenges in human-in-the-loop AI, and these challenges can increase as more agents and approval points are introduced. Each additional agent can create more events that require review, while reviewer capacity remains limited. Cheng and Cheng’s approach of separating oversight from individual workflow logic addresses part of this challenge by reducing the need to rebuild approval logic for each new agent.

Approval provides permission to act; it does not guarantee that the action remains correct.

Another important risk is staleness. An approval given for a proposal generated earlier may rely on information that has since changed. A lead may have replied, a price may have changed, or another user may have updated a record. For this reason, important conditions should be re-validated at execution time rather than relying only on the state captured during approval. Approval provides permission to act; it does not guarantee that the action remains correct.

How is Human-in-the-Loop Different for Business Agents than for Coding Agents?

How do you Measure whether the Gate is Working?

Four useful measures are approval rate, edit rate, escalation rate, and post-approval incident rate. Edit rate is particularly useful because a consistently low edit rate may indicate that the gate is no longer necessary or that reviewers are not meaningfully reviewing the proposals. The incident rate can help distinguish between these situations.

NIST’s framework treats this as a monitoring activity rather than an assumption. MANAGE 4.1 addresses appeal and override mechanisms in post-deployment monitoring plans, while MAP 3.5 calls for oversight processes to be assessed rather than simply defined.

Capturing these four measures is an instrumentation requirement before it becomes a management activity. If the approval queue does not record who made the decision, when it was made, and whether the proposal was changed, these measures cannot be evaluated reliably. This is the same discipline applied to the review process that we set out in AI agent observability.

When should You Remove a Human Gate?

Consider removing a gate when three conditions are met together: the edit rate for that action class has remained consistently low for a meaningful period, no significant incidents have followed approvals, and the potential impact of an incorrect action is limited. Any one of these conditions alone is not sufficient evidence.

Removing a gate does not mean removing oversight. It can represent a move from human-in-the-loop to human-on-the-loop, provided the ability to monitor and intervene remains in place. NIST MANAGE 2.4 emphasizes the need for mechanisms to supersede, disengage, or deactivate a system when necessary. An agent that can act independently should still have a clear mechanism for intervention.

The reverse process should also remain available. If incidents appear after a gate is removed, the action class can be placed back under approval and reassessed. Treating re-gating as a normal part of system management helps teams respond to evidence rather than allowing an unsuitable level of autonomy to continue.

What does Loop Engineering Mean for Systems that Touch Customers?

Loop engineering, as we use the term at Realisier Labs, is the practice of designing the decision loop as a defined system component: what the system may do independently, where a person makes the decision, what evidence each decision produces, and how autonomy is increased or reduced over time.

The term also has another meaning in current technical discussions. In much of the current writing, loop engineering refers to automating the prompting of a coding agent. That is a valid practice, but it addresses a different problem. It optimizes a loop with an automated verifier. The approach discussed here involves a human verifier, with the design focused on directing human attention to the decisions where it can have the greatest impact.

The Core Principle

Human feedback can provide an important source of verification. The feedback loop can be a core part of the product.

Our delivery process follows a similar structure at a larger scale. The engagement loop moves from discovery through design, build, review, and launch, with human review, production operation, and handoff providing information for the next cycle. The systems in the case studies were developed through this process, with approval gates positioned where actions reach customers.

What this Means in Practice

• Do not ask only whether a system should be autonomous.
• Ask, for each action it can take, whether an incorrect version of that action is recoverable, and place the gate at the first step where the answer is no.
• Recognize that the gate requires ongoing management. It can move toward rubber-stamping unless the review process shows reviewers where the system may be wrong. It can also introduce latency unless removing a gate is treated as a routine, evidence-based decision. In a multi-agent system, oversight is more sustainable when it is designed as a system component rather than added separately to each workflow.
• Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027 (25 June 2025). This highlights the importance of managing autonomy, oversight, and production readiness as part of the overall system design.
• AI agents that remain in production are not necessarily the most autonomous. Moving an AI pilot into production requires deliberate decisions about which actions the system can perform independently and which decisions remain under human ownership.

Frequently Asked Questions

1Is Human-in-the-Loop the Same as Human Oversight under the EU AI Act?

No. EU AI Act Article 14 requires high-risk systems to have appropriate human oversight, including mechanisms to override output and interrupt the system. Human-in-the-loop, meaning approval before execution, is one possible approach. Human-on-the-loop monitoring can also provide oversight, depending on the system’s risk, autonomy, and context of use.

2Does Adding a Human Make an AI System Compliant?

No. Research on human oversight has found that people may not always perform the oversight function as intended, particularly when they rely too heavily on automated recommendations. A gate that is not meaningfully used provides limited control.

3What is the Difference Between Human-in-the-Loop and RLHF?

Reinforcement learning from human feedback uses human preferences to train or improve a model before deployment. Human-in-the-loop, in this article’s context, places a person in the execution path of a live system. One influences how the model behaves. The other determines whether a specific action should occur.

4How Many Approvals Per Hour can One Reviewer Handle?

There is no single published figure that applies across all workflows. The appropriate capacity depends on how much context each approval requires. The more useful metric is often edit rate, together with review quality and incident data. When edit rates consistently reach zero, teams should verify that reviewers are still performing meaningful checks.

5Can an Approval Gate be Added to an Existing Agent?

Yes, but the main challenge is often state management rather than interface development. The agent must suspend execution, preserve context, resume correctly, and re-validate its conditions at execution time rather than relying only on the state captured when the proposal was created.

6Does Loop Engineering Mean the Same thing Everywhere?

No. Much of the current usage describes automating the prompting of a coding agent, where an automated verifier closes the loop. We use the term for designing decision loops in production business systems, where the verifier may be a person and the loop design determines how the system should operate safely and effectively.

Working out Where Your Gates Belong?