Agentic AI · Safe Autonomy

Not less autonomy.
Better handoffs.

Human-in-the-loop is not just an afterthought added to the end of a process; it serves as the critical decision-making layer that determines when an agent should proceed or pause to seek guidance. Despite significant investments in evaluations, tracking, and reminders, many teams overlook intentionally designing this layer, leading to stalled agent projects in the pilot phase.

See the three approval patterns → Jump to escalation tiers
overview SLIDE 01 : HUMAN IN THE LOOP Cover slide: Human in the Loop for AI Agents
Quick answer

Human-in-the-loop (HITL) is a design pattern that involves an AI agent functioning independently for the majority of a task but stopping, escalating, or seeking confirmation at specific decision points, rather than operating entirely unsupervised or needing approval for every action. The pattern consists of three approval stages : pre-action (approve before anything external happens), post-action (review after execution), and confidence-based progressing towards increased automation with a risk classification system that requires human approval for high-risk decisions where the potential cost of error exceeds the potential savings from automation. The goal is not complete unsupervised autonomy, but rather careful escalation only when uncertainty or risk reaches a certain level. selective autonomy : agents that reliably manage repetitive, high-context tasks and effectively identify when human judgment is needed.

definitions SLIDE 02 : IN-THE-LOOP, ON-THE-LOOP, IN-COMMAND Three human oversight models: in-the-loop, on-the-loop, in-command
Three oversight models, often in the same workflow

Oversight is a feature of the decision-making process, not a universal setting.

Imagine an airline rebooking agent who automatically reroutes the majority of disrupted passengers, but encounters a first-class passenger on an international trip with a loyalty-tier override and a fare class that needs manual reissuance. The agent recognizes the policy limitation, stops, and sends an approval request to a senior agent. human-in-the-loop.

Meanwhile, a supervisor monitors the rebooking process for any abnormalities, such as abnormally high expenses or consistently selecting expensive options, without examining each individual case. human-on-the-loopA seasoned operator with the authority to bypass the entire system's protocols is human-in-commandIn one system, all three elements coexist and the level assigned to each decision is fluid, based on its risk, context, and policy, rather than fixed for the entire agent.

the gap SLIDE 03 : THE LAYER MOST TEAMS SKIP Human-in-the-loop as the missing layer in the production agent stack
Not a capability problem

Well-evaluated agents still stall without this

Evaluation, tracing, and prompt engineering are all adequately addressed in a contemporary agent stack. However, the crucial layer that determines when an agent should seek assistance from a human is often overlooked by most teams, and this omission is not insignificant. This is a practical obstacle that often hinders agent projects from progressing beyond the pilot stage, despite functioning well in demonstrations.

Many teams use approval as a superficial safeguard: adding a single manual review step to the end of a workflow, calling it governance, and then are surprised when users stop using the feature. A more effective approach is to review the specific decision requiring judgment, rather than the entire process.

The core mechanics

Three approval patterns cover almost every case

Each answer pertains to a distinct timing query: prior to the action, subsequent to it, or solely upon reaching a certain threshold.

mechanics SLIDE 04 : PRE-ACTION, POST-ACTION, CONFIDENCE-BASED Three approval patterns: pre-action, post-action, and confidence-based
Match the pattern to the cost of being wrong

Approve before, review after, or escalate on trigger

Pre-action It is important to seek approval for the agent's proposed action before any external factors come into play, especially for irreversible or high-impact actions. Post-action When speed is crucial and mistakes can be easily undone, allow the agent to carry out the task and present the outcome for evaluation afterwards. Confidence-based Operates the agent seamlessly until encountering real uncertainty, a policy limit, or incomplete data, at which point it redirects only that instance to a human - the most efficient approach as volume surpasses the capacity of constant pre-approval.

classification SLIDE 05 : CLASSIFY BY RISK, NOT CONFIDENCE ALONE Four-tier risk classification for agent actions
The cost of a mistake, not the model's own certainty

Reserve mandatory approval for where it earns its cost

When determining the necessity of human approval, actions should be classified based on their true risk level rather than the model's confidence level. It is important to reserve human intervention for cases where the potential cost of an error outweighs the benefits of automation. A read-only lookup and an irreversible external transaction should not be subject to the same level of scrutiny.

TIER A
Read-only

No side effects; automate freely with basic logging only.

TIER B
Reversible

Can be undone cheaply; post-action review is usually sufficient.

TIER C
External

Impacts an external system or individual; consider a pre-action review.

TIER D
High-risk / irreversible

Cannot be undone; mandatory human approval before execution, no exceptions.

calibration risk SLIDE 06 : WHY VERBAL CONFIDENCE ISN'T ENOUGH Why an agent's stated confidence is not a reliable escalation signal
The math that justifies mandatory gates

Miscalibration compounds across a chain

When an agent claims to be '90% confident,' it does not mean they are correct 90% of the time. Relying solely on verbal confidence is not a reliable indicator to escalate the situation. This issue becomes even more problematic in multi-step agent chains, where a fifteen percentage point miscalibration in each step can significantly decrease the overall probability of all steps being correct. For instance, a claimed ninety percent confidence per step may actually only result in a forty percent probability of all three steps being accurate.

This is the numerical argument for implementing strict gates on important actions - it is not just a recommended practice, but a result of the compounding of confidence errors in a series of interconnected choices.

Turning a threshold into a workflow

Three escalation tiers, each with its own SLA

Approval queues can become unmanageably long without set response times, causing agents to be stuck waiting for a response from someone who may not even be aware they are being waited on.

SLA design SLIDE 07 : ESCALATION TIERS AND SERVICE LEVELS Three escalation tiers with defined SLAs and reviewer authority
Allocate reviewer capacity proportionally

Not every escalation deserves the same urgency

Tiered SLAs allow the business to allocate its most limited resource, senior reviewer attention, to the most urgent tasks, while ensuring that routine reviews are completed within a set timeframe rather than being left unresolved.

Tier 1 · Standard

4-hour SLA

Confidence level of 0.6-0.8 indicates moderate risk and has been reviewed by a team member. The majority of actions in this tier are approved as is, with emphasis on human verification rather than deep analysis.

Tier 2 · Elevated

1-hour SLA

Confidence under 0.6 or significant blast radius will be reviewed by a team lead for potential adjustments before approval.

Tier 3 · Executive

15-minute SLA

Reviewed by a designated authority, compliance exposure, legal risk, or critical infrastructure is typically assessed through an automatic page or alert.

infrastructure SLIDE 08 : ASYNC-FIRST BY DEFAULT Async-first infrastructure design for human approval gates
Real infrastructure doesn't wait politely

Synchronous approval collides with real systems

Maintaining an active connection during a human decision may seem straightforward, but it runs into issues like gateway timeouts, expired tokens, and outdated cursors as soon as a review exceeds a few seconds - which is often the case for tasks involving critical judgment.

The enduring pattern in authentic infrastructure involves managed pauses by the state: the agent's ongoing state is saved using a unique key, approval requests are lined up, and operations smoothly resume upon human response: whether in five minutes or five hours. Around two-thirds of production agents can handle delays of a minute or more on a specific task, providing the necessary flexibility for async-first design to function effectively.

What kills a HITL program

Three patterns derail oversight more than any technical issue

There are no infrastructure issues here. Instead, all three are design and calibration problems that become apparent only once actual usage begins.

common pitfalls SLIDE 09 : WHY HITL PROGRAMS FAIL Common failure patterns that derail human-in-the-loop programs
Watch the queue, not just the model

The queue tells you what the model can't

  • Notification fatigue : an excess of low-value approvals leads reviewers to simply rubber-stamp, undermining the purpose of the gate
  • Feedback that doesn't feed back approval and rejection signals that remain constant can nullify every effort a human makes
  • Static gates Begin with a cautious approach, regularly assess the queue, and only relax restrictions after consistent successful outcomes have been demonstrated, rather than on a set timetable.
scaling SLIDE 10 : OVERSIGHT THAT SCALES WITH THE FLEET Summary: scaling human oversight to thousands of agents through versioned policy
From 10 agents to 10,000

Version the policy the same way you version the code

As an organization grows to run thousands of agents at once, the challenge of maintaining real oversight becomes more pressing. The solution lies in treating approval rules, escalation semantics, and reviewer assignments as versioned artifacts that are testable in staging, replayable against historical traces, and deployable with rollback, similar to application code.

Human-in-the-loop design allows agents to independently manage the majority of repetitive, high-context tasks, while ensuring humans maintain deliberate control over the critical decisions defining the business. This balance between autonomy and oversight is essential.

Frequently asked

Human-in-the-loop FAQ

Human-in-the-loop involves pausing specific decisions for person approval before proceeding, while human-on-the-loop entails overall system monitoring for anomalies without reviewing each decision. Both models can coexist within one workflow, with the applied level of human involvement dynamically determined by decision risk.

Pre-action involves seeking approval for an agent's proposed action before any external events occur, post-action involves executing the action and reviewing the results afterward, and confidence-based entails the agent operating normally until reaching a predetermined uncertainty or risk threshold, at which point it escalates.

Verbal confidence is frequently inaccurately estimated, leading to compounding errors in multi-step processes. For example, a 90% confidence in each of three dependent steps, with a 15 percentage point miscalibration in each, may result in a true probability of all steps being correct closer to 40%. Therefore, risk-based hard gates are a more dependable control than relying solely on confidence thresholds.

The tiers are organized by urgency and authority level: a standard tier for moderate-risk, moderate-confidence tasks with a response time of several hours, an elevated tier for low-confidence or high-impact tasks with a one-hour response window overseen by a team lead, and an executive tier for compliance, legal, or critical-infrastructure issues with an immediate response time and automatic alert.

Maintaining a live connection during human decision-making can lead to issues like gateway timeouts, token expiration, and stale cursors if the review process takes longer than expected. This is where async-first design comes in, saving the agent's state with an idempotency key and smoothly resuming execution once the human responds, without the need to keep a precarious connection open.

Notification fatigue often occurs due to an overwhelming number of low-value approval requests, leading reviewers to simply rubber-stamp instead of critically evaluating them. Additionally, approval and rejection decisions are often not used to improve agent behavior, and gates tend to remain static instead of loosening only after a genuine track record of successful executions has been established.

Get started

Ready to design your agent's approval gates?

Categorize actions based on risk rather than just confidence, establish escalation SLAs before a backlog occurs, and prioritize asynchronous design from the beginning.

Revisit escalation tiers → Back to common pitfalls