How do you avoid approval fatigue with a human-in-the-loop AI agent?

Don't gate everything. Gate only what can hurt — destructive, irreversible, or high-blast-radius actions — and pass read-only and easily-reversible calls straight through. Show a human-readable impact diff so the person is approving a specific consequence, not a vague yes/no. An approve-everything wall trains people to rubber-stamp, which is worse than no gate.

Where should the human-approval checkpoint live in an MCP setup?

At the protocol boundary — a proxy between the MCP client and the MCP server that sees every tools/call. It can classify each call using the server's annotations and mcp-compensate metadata, hold the dangerous ones for a human, and record the decision. Because it sits outside the model and is deterministic, the agent cannot reason its way past it.

// field note · patterns

Human-in-the-loop for MCP tool calls

Q: How do you add a human in the loop to an AI agent?

Put a checkpoint at the tool boundary — the point where the agent's decision becomes a real action — not in the prompt. Intercept the tool call, classify its risk, and require human approval only for the mutating and irreversible subset, letting read-only calls pass through. The checkpoint must be deterministic and outside the model, or the agent can talk its way around it.

"Put a human in the loop" is easy to say and easy to do badly. Gate every call and you build an approve-everything wall that trains people to click "yes" without reading — worse than no gate. The skill is gating the small dangerous subset and letting everything else flow. Here's how to decide, and where the checkpoint has to live.

ChronoMCP field notes · Aug 2026 · ~6 min read

THE SHORT VERSION

Don't gate everything. Read-only and easily-reversible calls should pass through. Gate the destructive, irreversible, and high-blast-radius ones.
Three questions decide it: is it a mutation? is it reversible? how big is the blast radius?
The checkpoint lives at the tool boundary — a deterministic layer outside the model — not in the prompt, which the agent can argue its way around.
Show an impact diff. A person approving "send $4,000 to acct ***12" makes a real decision; a person clicking a bare "Approve?" learns to rubber-stamp.

What "human-in-the-loop" should mean

The failure mode isn't too little oversight — it's oversight applied indiscriminately. If your agent asks a human to approve every list_files and search_records, two things happen: the workflow slows to a crawl, and the human, buried in trivial prompts, stops reading them. When the one dangerous call finally appears — the drop-database, the send, the refund — it looks exactly like the hundred harmless ones before it, and it gets the same reflexive "yes."

An approval wall that gets rubber-stamped is a false sense of safety, not safety.

Real human-in-the-loop is selective: the system does the triage, and the human only sees the calls where their judgment actually changes the outcome. That means the hard part isn't the approval UI — it's the classification.

The three questions that decide whether to gate a call

Is it a mutation?
A read has no side effect — nothing to approve, nothing to undo. Reads pass through. Only calls that change the world are candidates for a gate. (Most tool calls, in practice, are reads.)
Is it reversible?
A create you can delete is compensable — gate it if you like, but the stakes are low. A DROP TABLE, a sent email, a settled payment has no inverse. Irreversible calls are the ones a human should see before they run — because after is too late.
How big is the blast radius?
A delete-one is not a filter-wide delete-many; a comment is not a merge to main; a test-page click is not a checkout. The same tool can be trivial or catastrophic depending on its arguments and target — so classification often has to read the parameters, not just the tool name.

Run any tool call through those three and you get a risk tier — which maps cleanly onto three modes.

Risk-tiered gating: log, gate, block

Mode	For	Behavior
log	Reads; reversible low-stakes writes	Pass through, record it. Zero friction. Start here to see what your agent actually does.
gate	Mutating & irreversible calls; high blast radius	Pause for a human. Show the impact. Wait for yes/no. This is the checkpoint.
block	Destructive actions in unattended/locked-down runs	Refuse outright — no human needed. For environments where the answer is always "no."

The point is that a single agent doesn't get one blanket policy — each class of action gets the mode that fits it. Reads flow, the refund waits for a person, and in a nightly unattended job the destructive tools are simply blocked.

Where the checkpoint has to live

Here's the part that's easy to get wrong: the checkpoint cannot be an instruction in the prompt. "Ask me before doing anything destructive" is a request the model may forget, misjudge, or be argued out of by a cleverly-worded input — the same reason a code-freeze instruction didn't stop an agent from deleting a production database. Enforcement has to be deterministic and outside the model.

For MCP agents, that place already exists: the tools/call boundary. A proxy sitting between the MCP client and the MCP server sees every call on the wire and can:

Classify it using the server's own readOnlyHint/destructiveHint annotations and its mcp-compensate reversibility metadata — falling back to conservative rules when metadata is absent (unknown reversibility is treated as dangerous, never safe).
Hold the dangerous ones for a human, with an impact diff, while letting reads through.
Record the decision in a tamper-evident log, so "the agent asked, a human approved, here's the outcome" is a fact you can verify.

Because it's deterministic and off to the side, the agent can't reason its way past it — it isn't asking the model for permission, it's asking a person.

The approval UX that doesn't train rubber-stamping

Two rules keep the human's judgment sharp:

Gate rarely. If approvals are frequent, they're being over-applied — tighten the classification so only genuinely consequential calls surface. A person who's asked once an hour reads carefully; a person asked every ten seconds does not.

Show the consequence, not a question. "Approve?" is uninformative. "This will delete the customers table (irreversible — no backup captured)" or "This will refund $2,300 to card ***12 — a new transaction, fees not returned" gives the human the one thing they need: what actually happens if they say yes. A good impact diff also flags the irreversible steps before approval, so the honest limit is visible up front — compensation is not undo.

The whole idea in one line: a good human-in-the-loop system does the triage so the human doesn't have to — surfacing the few calls where a person's "no" prevents something that can't be taken back, and getting out of the way for everything else.

This is exactly what the field guide grades

Every profile in our MCP field guide is really an answer to "which calls on this server deserve a gate?" — the read-only servers where a checkpoint is ceremony, the write-capable databases where a DROP needs a human, the payment surfaces where money can't be un-moved, the browser tools where the same click is harmless or catastrophic depending on the page. Same three questions, one server at a time.

FAQ

How do you add a human in the loop to an AI agent?

Put a deterministic checkpoint at the tool boundary — where the agent's decision becomes a real action — not in the prompt. Intercept the call, classify its risk, and require approval only for mutating and irreversible calls while letting reads pass. The checkpoint must live outside the model, or the agent can talk its way around it.

How do you avoid approval fatigue?

Gate only what can hurt — destructive, irreversible, or high-blast-radius actions — and pass read-only and easily-reversible calls straight through. Show an impact diff so the person approves a specific consequence, not a vague yes/no. Frequent approvals are a sign the classification is too broad.

Why not just tell the model to ask before dangerous actions?

Because an instruction in a prompt is a request a probabilistic model can forget, misjudge, or be argued out of — the same failure that let an agent delete a production database during a code freeze. Enforcement has to be deterministic and outside the model, at the tool boundary.

Gate the dangerous subset, ship the rest

ChronoMCP is a proxy that does exactly this at the MCP boundary — classify, gate, and record, with reads flowing through. Free CLI, MIT.

Read the quickstart → See the field guide