The two lazy policies are both wrong. If an agent asks about everything, your team stops reading and approves on reflex. If it asks about nothing, one misread instruction can send the wrong message to every investor you've met.
A good policy spends human attention on the small share of actions that can do real harm. This guide explains the patterns, gives you a table you can copy, shows how to stop approvals becoming a rubber stamp, and sets out a way to promote actions to auto-run over time. It applies to any agent product, or to one you build yourself.
What human in the loop AI agents actually do
"In the loop" covers several different designs, and it helps to name them. Each one catches a different kind of failure, and most companies should use all four for different actions. The names here are ours.
| Pattern | How it works | Good for | Weakness |
|---|---|---|---|
| Approve first | The agent stops and waits for a yes | External, costly or irreversible actions | Slow, and tiring in high volume |
| Review after | The agent acts, and a person checks a log | Reversible internal actions | Harm happens before anyone looks |
| Escalate on doubt | The agent acts unless a rule or low confidence triggers a person | High volume with clear rules | Depends on the agent knowing when it's unsure |
| Sample audit | A person checks a random share each week | Finding quiet drift in long-running work | Rare failures can slip through |
Official guidance is fairly consistent. The Model Context Protocol specification says there should always be a human in the loop able to deny tool invocations. OWASP recommends human approval for high-impact actions. Anthropic's guide to building agents describes agents pausing for feedback at checkpoints, and warns about higher costs and compounding errors as autonomy grows.
The approval policy table
Copy this and adapt it. It's our recommendation, based on the sources on this page. Two questions drive it: how easily can the action be undone, and who outside the company will see the result?
| Action type | Examples | Policy | Why |
|---|---|---|---|
| Read from connected tools | Look up a deal, summarise a thread, check runway | Auto-run | Changes nothing, though you should still limit what it can read |
| Draft for review | Prepare a reply, write a first investor update | Auto-run | Nothing leaves until someone sends it |
| Personal reminders and notes | Add a note for you, set a reminder | Auto-run | Low stakes, easy to delete |
| Small internal changes | Create a task, tag a lead, update a status | Auto-run after a trial period, with a log | Reversible, but noise builds up if wrong |
| Message to your own team | Post in a team channel, assign work to a colleague | Ask at first, then consider auto-run for routine posts | Reversible in theory, but people see it and react |
| Bulk internal changes | Update 200 leads, reassign a whole board | Always a person | Small errors multiply, and undoing them is tedious |
| Email or message outside the company | Customer reply, investor note, invoice reminder | Always a person, at least until you've got a long record for a narrow template | Can't be recalled, and your company answers for what it says |
| Public posts | Social media, website changes, press | Always a person | Visible to everyone and hard to take back |
| Spending and payments | Pay an invoice, buy ads, issue a refund | Always a person | Direct financial loss |
| Commitments | Sign a document, agree a price, change a contract | Always a person, usually the founder | Legally binding, and the agent has no authority or accountability |
| Deleting data | Remove records, drop files, delete a repo branch | Always a person, and prefer no delete rights at all | Possibly permanent |
| Access and permissions | Add a user, change a role, share a data room, create a key | Always a person, usually an admin | Widens the blast radius of every later error |
| People decisions | Reject a candidate, send a warning, change pay | Always a person, and don't let the agent send the result | Legal risk and real effect on someone's life |
| Sensitive data leaving | Send financials, cap table or personal data outside the company | Always a person, with recipients shown | A leak can't be reversed |
One rule beats any table: when in doubt about which row applies, treat the action as the riskier one. And enforce the table in the system, not in the prompt. OWASP advises implementing authorization in downstream systems, without relying on the model to decide whether something is allowed. If an agent shouldn't delete, don't give it credentials that can.
You'll also see this structure in developer tools. Claude Code's permissions don't require approval for read-only tools within the working directory, and do require it for file changes and most shell commands. OpenAI's Agents SDK lets a developer mark a tool as needing approval, either always or by a per-call check, and pauses the run until someone decides.
Why approvals turn into a rubber stamp
Too many low-value prompts train people to say yes. Anthropic reports that users of its coding agent accept 93% of permission prompts, and warns of approval fatigue, where people stop paying close attention. A high approval rate isn't proof of a problem, because many of those actions may well have been fine. It does tell you that the prompt carries little information, and a reviewer can learn to skip it.
The behaviour shifts with experience too. In Anthropic's study of agent autonomy, new users of Claude Code used full auto-approve in about 20% of sessions, rising to over 40% by 750 sessions. They also interrupted the agent more often, moving from about 5% to about 9% of turns. It suggests a change from approving each step to watching and stepping in. The data comes from one company's tools, mostly in software engineering, so be careful when applying it to business actions.
That same study found only 0.8% of the tool calls it sampled appeared irreversible. Anthropic notes limits on this figure, including that the labels were generated by Claude itself, and it's across all sorts of uses. It still supports the broad approach here. If only a tiny share of actions are truly dangerous, then a policy that treats them all the same wastes your attention on the rest.
The EU AI Act names the underlying problem. Article 14 refers to automation bias, the tendency of people to rely too much on a system's output. That article applies to high-risk systems and not to a typical startup's agent, so it's unlikely to be a compliance point for most readers. It's useful as a sign of how seriously regulators take this.
What a good approval request shows
A request deserves a decision only if it gives the reviewer what they need to make one. MCP's specification recommends that clients show tool inputs to the user before calling the server, and log tool usage for audit. Here's a fuller checklist. Use it when you're evaluating a product, and when you build your own.
- Exactly what will happen, in plain words. For example, "Email Priya the attached deck", and never only "Run send_email".
- The full content and the recipients. The whole message, with every address. Don't accept a summary of it.
- Why it's proposing this. The record or event that triggered it, with a link so you can open it.
- What will be affected by a bulk action. The count and a sample, such as "200 leads, here are the first ten".
- Whether it can be undone. A clear flag on actions that are permanent.
- Options beyond yes and no. Edit, ask for a change, or reject with a reason. OpenAI's SDK lets a rejection carry a message back to the model so it can adjust.
- An expiry. Stale approvals are dangerous. If a reminder sits for a week, the facts behind it may have changed.
- A permanent record. Who approved what and when, with what the agent actually did.
How to move an action to auto-run
Earn autonomy one action at a time, and use evidence. Here's a worked example. Suppose an agent proposed 40 invoice reminders over eight weeks, all sent from one template to customers more than 14 days overdue. You approved 38 unchanged, edited one for tone, and rejected one, because the customer was in a dispute your system didn't record. That's 38 of 40, or 95%, approved unchanged.
The 95% looks persuasive. The rejection is what should hold your attention, because it would have annoyed a customer who was already upset. So you don't flip the action to auto-run. First, you add a field for disputed invoices and exclude them. Then you run another 30 with approval. If those all pass unchanged, you could promote this one narrow template, with limits.
- Pick one narrow action. "Send reminder template B to customers more than 14 days overdue" works. "Send emails" doesn't.
- Gather a track record. As a rule of thumb, we'd want at least 30 straight approvals with no edits. That number is our judgment, and for higher-stakes actions it should be higher.
- Look at every edit and rejection. Each one points to context the agent lacked. Fix the data or the rule.
- Add a limit. Cap the volume per day and the value involved, and stop automatically when anything unusual happens.
- Keep the log and sample it. Check a handful every week. Demote the action the first time something goes wrong.
- Leave some rows alone for good. Payments, deletions, commitments, access changes and people decisions stay with a person, however good the record looks.
Who should approve, and what they're responsible for
Assign approvers by action type, and name a backup. A founder who approves everything becomes a new bottleneck, and approvals pile up during a flight. Finance can take payments, the head of sales can take customer messages and an admin can take access changes. OpenAI's SDK guidance on server-side approvals is a useful checklist here if you're building: authenticate reviewers, check they're authorized, and make sure a decision can't be replayed.
Liability doesn't move to the tool. In Moffatt v. Air Canada, a Canadian tribunal rejected the idea that a chatbot was a separate entity from the airline. Your approver should read as if their own name is on the message, because the company's is.
Don't use a second AI as your only approver. In Anthropic's Project Vend, the AI manager brought in to oversee an AI shopkeeper approved lenient requests about eight times as often as it denied them, and the authors found it shared the same blind spots. Software checks are useful as a filter ahead of a person. Rules such as spending limits often do better than a second model's opinion.
This approach reflects how we built the Nautis Chief of Staff, and it's worth saying plainly what it does. Under Settings → Agent Autonomy, each capability is labelled External or Internal and set to Ask every time, the default, or Run without asking, which can be undone within 10 minutes where supported. Deleting always asks. Requests land in the Approval Center, where each card names the agent and the action and lets you inspect the exact change. Owners and admins decide, unattended requests expire, and every action is audit-logged. In connected tools, reads run without a prompt and writes ask for approval by default. The cost is the one this page has described: someone has to review, so it isn't hands-off, and it'll tire your team if nobody tunes it. For limits beyond approvals, read what an AI chief of staff cannot do. If you're weighing your own setup, build vs buy covers what you'd need to supply.
FAQ
What does human in the loop mean for AI agents?
It means a person can approve, change or reject what an agent does, usually before it happens. Some designs review afterwards or step in only when a rule is triggered. The MCP specification says there should always be a human able to deny tool invocations.
Which AI agent actions should always need human approval?
Anything that leaves the company, spends money, makes a commitment, deletes data, changes permissions or affects a person's job. These are hard or impossible to undo. Reads, drafts and small internal changes are the safer candidates for auto-run.
How do you avoid approval fatigue with AI agents?
Ask less often and make each request worth reading. Let low-risk reversible actions run with a log, and show the full content and reason on the rest. Anthropic reports users accept 93% of its coding agent's prompts, which shows how quickly reviews can become reflex.
Can an AI agent approve another AI agent's actions?
It can filter them, but it shouldn't be the only check on anything risky. In Anthropic's Project Vend, an AI manager shared the blind spots of the agent it oversaw. Fixed rules such as spending caps, plus a person for high-stakes actions, are more dependable.
Do human in the loop rules make AI agents useless?
Not if you set them well. Drafting, research and monitoring still save time when nothing goes out unreviewed. You lose some speed on external actions, and most small companies should accept that trade while trust in the agent builds.
Sources
- Model Context Protocol specification: tools (checked Oct 31, 2026)
- OWASP: LLM06 excessive agency (checked Oct 31, 2026)
- Anthropic: building effective agents (checked Oct 31, 2026)
- Claude Code docs: configure permissions (checked Oct 31, 2026)
- OpenAI Agents SDK: human in the loop (checked Oct 31, 2026)
- Anthropic: Claude Code auto mode (checked Oct 31, 2026)
- Anthropic: measuring agent autonomy (checked Oct 31, 2026)
- EU AI Act, Article 14: human oversight (checked Oct 31, 2026)
- McCarthy Tétrault: Moffatt v. Air Canada, misrepresentation by an AI chatbot (checked Oct 31, 2026)
- Anthropic: Project Vend, phase two (checked Oct 31, 2026)