Human-in-the-loop for AI agents: a practical guide for 2026

What human-in-the-loop means for AI agents, which actions need approval, the four patterns, how to design timeouts and escalation, and which tools to use.

Written by
Published
Reading time
5 min

Every team that gives an AI agent real permissions ends up asking the same question: which actions can it take alone, and which should wait for a person? This guide answers that question in practical terms, with patterns you can apply today.

What human-in-the-loop means for agents

Human-in-the-loop (HITL) is a design where an agent pauses at specific points and waits for a person. The person can approve or deny, choose between options, provide missing information, or review the agent’s output before it is used.

It is different from human-on-the-loop, where the agent acts and a person watches and steps in afterwards. Monitoring catches problems after they happen. Approval prevents a specific class of problem from happening at all. Production systems need both, for different actions.

Why it matters more for agents than for chatbots

A chatbot that is wrong produces a bad answer, which a person reads before acting on it. An agent that is wrong acts on its own mistake. The person who would have caught it is not in the loop unless you put them there.

Three things make this urgent in 2026:

  • Agents have real tools. MCP made it easy to give an agent database, payment, email and cloud access in minutes.
  • Agents run unattended. Background agents process queues overnight, with nobody watching a chat window.
  • Failures are asymmetric. One wrong bulk delete or wire transfer can cost more than everything the agent saved that month.

What to gate: a risk checklist

Not every step needs a person. Approving everything trains people to click “yes” without reading. Gate an action if any of these are true:

QuestionExamples
Is it hard or impossible to undo?Deletes, sent emails, executed payments
Does it cost real money?Wires, refunds, purchases, cloud scaling
Does it reach many people?Bulk email, social posts, customer notifications
Does it change who can do what?Access grants, API keys, role changes
Does it touch production?Deploys, migrations, config changes
Is it legally or reputationally sensitive?Contracts, public statements, data exports

Everything else (reading, drafting, searching, summarising) can usually run without a gate.

The four patterns

Most human-in-the-loop moments fall into four shapes. Naming them helps you pick the right tool call and the right interface.

  1. Approve or deny. A binary decision before an action. “Refund $1,240 to order 88213?” This is the most common pattern.
  2. Choose. The agent has several valid paths and cannot decide. “Use the staging or production SendGrid account?”
  3. Supply input. The agent is missing information only a person has, such as a credential, a value or a confirmation number.
  4. Review output. The agent produced something (an email, a report, a SQL migration) and a person checks it before it is used.

A fifth case, handoff, is when the agent should stop entirely and give the task to a person, such as an angry customer or a negotiation.

Designing the request

The quality of the decision depends on the quality of the question. A good request:

  • Says exactly what will happen. Not “proceed with cleanup?” but “Delete 3,200 users inactive since 2023 from the production database.”
  • Gives the numbers. How many records, how much money, how many recipients.
  • Says why. The trigger or reasoning, in one sentence.
  • Says what happens on no. “If denied, I will skip this step and continue with the report.”
  • Is answerable from a phone. If the approver needs a laptop to decide, the agent has not given enough context.

Timeouts and fail-closed defaults

Every request needs a timeout, and every timeout needs a default. The default must be deny. An agent that proceeds because nobody answered has no approval step at all.

Set timeouts by urgency. A production deploy at 2am might wait 30 minutes. A content review can wait a day. Long waits are fine as long as the agent can pause without holding resources, which is why durable state (checkpoints, run state) matters.

Delivery and escalation

The weakest link in most HITL setups is not the pause. It is reaching the person. A request sitting in a dashboard tab nobody has open is the same as no request.

Good delivery means:

  • Meet people where they are. Slack or Teams during work hours. SMS, WhatsApp or a phone call when it is urgent or after hours.
  • Escalate on silence. Try Slack, then SMS after five minutes, then call. Then try the backup person.
  • Route by role, not by name. Send to whoever is on call this week, so approvals follow your rota.
  • One answer closes it everywhere. Once someone approves in Slack, the SMS and call should not fire.

Audit trail

Record who decided, when, through which channel, and what they saw. You will need it for debugging (“why did the agent do this?”), for compliance (who authorised a payment), and to tune your gates (which requests are always approved and can be automated).

Tools: pause vs delivery

There are two layers, and many teams only build the first.

  • The pause stops the agent and saves its state. LangGraph’s interrupt(), the OpenAI Agents SDK’s needs_approval, the Vercel AI SDK’s needsApproval, Temporal signals and n8n’s human review steps all do this well.
  • The delivery gets the question to a person, escalates, collects the answer and returns it. This is what redphonr provides over MCP, alongside tools like gotoHuman, Pushary and Zapier’s Human in the Loop.

Our ranked list of the 10 best human-in-the-loop tools for AI agents compares them in detail.

A minimal implementation

With an MCP-capable agent, the whole design above is one tool call:

result = await session.call_tool("request_approval", {
    "message": "Refund $1,240 to order 88213 (customer reports double charge, Stripe shows 2 captures).",
    "timeout_seconds": 1800,
    "default": "deny",
})
if result["decision"] != "approved":
    return "Refund not issued: waiting for a person to approve."

The 5-minute tutorial walks through setting this up with Claude.

Checklist

  • List the actions your agent can take and mark the ones that pass the risk checklist.
  • Gate only those, with specific instructions in the system prompt.
  • Require exact, numeric, phone-readable messages.
  • Set a timeout and deny default on every request.
  • Deliver to real channels, with escalation and an on-call backup.
  • Log every decision and review the log monthly.

Frequently asked questions

What is human-in-the-loop (HITL) for AI agents?

Human-in-the-loop means an AI agent pauses at defined points and waits for a person to approve, choose, supply data or review its work before it continues. It keeps a person accountable for actions that are costly, irreversible or sensitive, while the agent does the rest on its own.

Which agent actions should require human approval?

Actions that are hard to undo or have real-world cost: deleting or bulk-updating data, moving money, deploying to production, changing access or permissions, sending messages to many people or from a company domain, and anything with legal or compliance impact.

What is the difference between human-in-the-loop and human-on-the-loop?

In human-in-the-loop the agent waits for a person before acting. In human-on-the-loop the agent acts on its own and a person monitors and can intervene afterwards. Most production systems use both: approvals for a few high-risk actions and monitoring for everything else.

What should happen if the human does not respond?

The agent should fail closed: treat the request as denied and stop, after escalating to other channels or people first. An agent should never proceed silently because a request timed out.

Do I need a separate tool for human-in-the-loop?

Frameworks like LangGraph, the OpenAI Agents SDK and the Vercel AI SDK can pause an agent. They do not deliver the question to a person who is away from the screen, escalate, or keep an audit trail. A delivery layer such as redphonr, or your own notification system, fills that gap.