The whole point of an AI agent is that it acts on your behalf — it reads, writes, calls tools, gets things done without you clicking every button. But “acts on your behalf” is exactly the problem when the action is deleting a production table, wiring money, or emailing a customer. The pattern that has settled across production AI deployments in 2026 is simple to state: autonomous execution for routine work, a human in the loop for high-stakes actions.

Getting that split right is what separates an agent you can actually trust with real tools from a demo. Here’s what “human in the loop” (HITL) means for tool calls, which calls deserve an approval, the patterns that work, and the ways HITL quietly fails.

What human-in-the-loop means for a tool call

HITL for tool calls means the agent can propose an action but can’texecute it until a person approves. The agent pauses at the tool boundary, surfaces what it wants to do (the tool, the arguments), and waits for a yes or no. This is now first-class in the ecosystem: MCP added elicitation, which lets a server pause and request structured input or approval mid-execution, and the OpenAI Agents SDK and Cloudflare Agents both ship a pause-approve-resume flow where a tool call can wait for a decision and continue from the same state later.

Which tool calls actually deserve an approval

The mistake most teams make first is asking for approval on everything — which trains everyone to rubber-stamp (more on that below). The goal is to gate the calls where the cost of being wrong is high and hard to undo. A practical list:

  • Irreversible or destructive — deleting records, dropping tables, force-pushing, closing accounts.
  • Money — refunds, payouts, purchases, anything that moves funds.
  • Outbound communication — sending an email, posting to Slack, replying to a customer in your name.
  • Production & infrastructure — deploys, config changes, secrets rotation.
  • Data leaving your walls — exporting datasets, sharing files externally.

Everything else — reading a file, querying read-only, searching docs — should just run. If an agent needs a human for routine reads, you’ve built a slower human, not an agent.

The patterns that work

1. Tiered policy per tool: allow, ask, block

The cleanest model isn’t a binary “approve everything or nothing.” It’s three tiers set per tool: allow it to run freely, ask for approval each time, or block it outright. Read tools get allow, destructive tools get ask or block. This maps cleanly onto how you’d think about access control for a team too.

2. Approve out-of-band — don’t freeze the agent forever

A blocking approval that waits indefinitely is a great way to hang an automation. Good HITL sends the approval request somewhere a human actually is — a dashboard, an email, a Slack message — with a clear approve / deny, and a timeout that failsclosed (deny) if no one responds. The agent proposes, the human decides asynchronously, the action runs or doesn’t.

3. Pause-and-resume, not restart

When approval comes through, the agent should resume from exactly where it paused — not replay the whole task. That’s the design behind MCP elicitation and the agent-SDK approval flows: the tool call is suspended with its state intact and continues on the decision. Restarting from scratch wastes tokens and risks doing the earlier steps twice.

4. Default to “ask” when you’re unsure — and log every decision

For a tool you haven’t classified yet, the safe default is ask, notallow. And every approval decision — who approved, when, with what arguments — should land in an audit log. When something goes wrong, “who approved this and what did it do” is the first question you’ll need to answer.

Where a gateway makes this practical: approvals are painful to bolt onto every agent and every server one at a time. An MCP gatewayis the natural place to enforce them once, for everything. That’s how gate works: every tool has an allow / ask / block policy, and anything set to ask is held for your approval — you approve or deny from the dashboard or straight from an email — while every call, and every decision, is logged in plain English.

How human-in-the-loop quietly fails

  • Approval fatigue. Ask on everything and people stop reading — they just click approve. Gate only the high-stakes calls so each prompt still means something.
  • No timeout. An approval that waits forever becomes a silent outage. Always fail closed after a deadline.
  • No record. If approvals aren’t logged, you can’t reconstruct an incident or prove control to an auditor.
  • Approving blind. If the request doesn’t show the actual arguments, the human is rubber-stamping a black box. Surface what the tool will do, not just its name.

The bottom line

Human-in-the-loop isn’t about slowing your agents down — it’s about making it safe to let them move fast on everything except the handful of actions you’d never want to discover after the fact. Set routine tools to run, gate the destructive and the irreversible behind an approval that reaches a real person, fail closed on silence, and log every decision. Do that and you can hand an agent real tools without holding your breath.