Human-in-the-Loop AI Agents

Design your AI agent workflow so humans approve before irreversible writes and after the agent shows its reasoning, not on every harmless lookup step.

Approval is a placement problem

Build human-in-the-loop AI agents by letting read-only research run within scope, then pause for a human after the agent presents evidence and immediately before an irreversible write. Use approval gates for judgment-heavy recommendations and state-changing actions, while harmless lookups continue without interruption. This keeps human attention on mistakes that could affect customers, money, or shared systems.

Plenty of workflow software offers approvals and human oversight, and the details differ. Zapier has a Human in the Loop step that pauses a Zap for a reviewer. n8n can require approval before an AI agent runs a chosen tool. Make lists a Human in the Loop app for its Enterprise plan. AI Agent builds approvals into chat, tickets, the inbox and workflows. The comparison below shows where each one pauses.

Human-in-the-loop sounds responsible until it turns into a queue of identical green buttons. You wanted a safety net and got a habit of clicking approve while half-reading a summary on your phone.

Oversight everywhere won't fix that. Better placement inside the AI agent workflow will. Put a person where judgment still beats pattern matching, and leave everything else alone. Agents are good at gathering context, chaining tools and drafting next moves, and they're still wrong in ways that look plausible. Your job is to decide which mistakes are cheap and which ones leave a mark in Stripe, Gmail, or the customer record.

Think of approval as a gate on the road, placed where the road forks toward something hard to undo.

Human-in-the-loop means a person can review, change, or stop what an agent does before it takes effect. The EU's High-Level Expert Group on AI names three oversight approaches in its Ethics Guidelines for Trustworthy AI:

  • Human-in-the-loop: a person can intervene in every decision cycle of the system. The guidelines add that in many cases this is neither possible nor desirable.
  • Human-on-the-loop: a person can intervene during the design cycle and monitors the system while it runs.
  • Human-in-command: a person oversees the system's overall activity and decides when and how to use it, including whether to use it at all.

When no person checks the agent at all, it runs out of the loop. That only suits reversible, low-stakes work.

You can mix the approaches. Reads run unattended within scope, writes wait for a person, and a person stays in command of what the agent may touch. For owners, logs and review cadence, see AI agent governance and AI agent security. For the basics, start with what AI agents are and what agentic AI is.

Where humans still earn their keep

An agent's work splits into three phases: research, recommendation and commit. Each one deserves its own rules.

Research steps pull context: tickets, metrics, docs, messages. The agent might misread tone or miss a footnote, but the damage is usually a bad paragraph, not a bad quarter. Recommendation steps propose an action, like refunding this customer, escalating that ticket, rewriting a subject line or opening an issue. A mistake here is a wrong decision shipped with confidence. Commit steps write, send, charge, or merge, and a mistake there is visible to someone who was never in the loop.

Human review pays off when the agent crosses from "here is what I found" to "here is what I did" or "here is what I want to do next." It also pays off when the input is ambiguous and the tool choice matters. Should this message go to a public channel or a DM? Should this update touch production data or a sandbox? You can't fix those by picking a smarter model. They're about where the stop sits.

Approve every tool call and you're back to doing the job yourself, with extra latency. Approve nothing and you're betting the agent will never mix up similar names, dates, or account IDs. Most teams want a narrow band in the middle.

How rubber stamps happen

Rubber stamping usually starts with fatigue. Nobody sets out to be lazy about it.

Say the agent sends forty review packets a week. Each one looks the same at a glance: tidy summary, links you half recognize, a confident tone even when it shouldn't be. You approved the last thirty-eight without a problem, so number thirty-nine definately gets the same click. That's the one where the wrong customer gets the right email template, or the right customer gets the wrong discount code.

Empty packets lead to rubber stamps too. A "Please review" with no diff, no cited sources, and no stated risk isn't a decision request. It's paperwork, and reviewers learn to treat it like terms of service. The same drift shows up when stakes don't match the process. Someone signs off on internal digests nobody reads externally, while the autopilot posts to Slack because "it is just notifications." The team picks up the lesson that approvals are ceremonial for low-impact work and optional for high-impact work. Neither lesson helps.

Anthropic describes the same pattern in Claude Code. It reports that, in practice, users accept more than nine in ten manual permission prompts, and it names the result approval fatigue. Its answer was auto mode, which hands approval decisions to model-based classifiers so people see fewer prompts. Anthropic also says auto mode is not a drop-in replacement for careful human review on high-stakes infrastructure. A classifier can thin out the queue, but it can't stand in for a person on the actions that matter most.

Good placement means fewer prompts that say more. One thoughtful stop beats five polite ones.

Put the hard stop before writes

The strongest default in any AI agent workflow is short: reads may run freely within scope, and writes wait for a human.

That matches how damage actually happens. Fetching the wrong row is embarrassing. Updating the wrong row is an incident. Sending the wrong email starts a conversation you didn't want today, and creating the wrong invoice gets finance calling you back.

Put the approval step immediately before persistence. At the start of the run you don't know yet what the agent will propose, and after a batch of ten actions it's too late. The right spot is just before the tool that changes state.

For multi-step workflows, treat each write class seperately. Posting to Slack is a write. Creating a Linear issue is a write. Drafting a report in a doc only you can see might not be. Name those categories in plain language in your boundary, so builders don't have to guess.

When several writes belong together, bundle them into one approval with a clear "if approved, all of these happen" list. Partial bundles teach reviewers to trust the header and skip the line items.

Put the soft stop after the agent shows its work

Before the hard stop, give humans a briefing worth reading. The best approval packets answer four questions: what triggered the run, what the agent looked at, what it recommends, and what changes if you say no.

That soft stop can live inside the same workflow step as the hard stop, but it comes first logically. The agent finishes its read-only analysis, assembles the evidence, then pauses. The human scans for category errors like the wrong account, the wrong time window or the wrong repo. If the foundation is wrong, you reject early and cheaply.

Structured knowledge helps here. When agents read from connected tables instead of vibes, the packet can point to rows and fields, and you approve the chain from source to suggestion rather than the prose alone.

Skip the soft stop when the action is truly reversible and low impact, and when the log alone is enough for a later audit. Keep it when the agent synthesized across many sources and a single wrong link poisons the conclusion.

Match the pattern to how the agent runs

Scheduled workflows and always-on autopilots fail in different places, so approval should sit in different places too.

A scheduled workflow, like a weekly report or a recurring research pass, can often run its read-only steps unattended, then queue one approval before distribution. The human checks the final artifact and the recipient list, and Monday morning doesn't turn into thirty micro-decisions.

An autopilot watching a stream of events needs tiered responses. Obvious triage can auto-route. Edge cases escalate with context. Only the actions that change customer state or spend money need a hard stop every time. If everything escalates, on-call starts ignoring the pager.

Hybrid setups are normal. A workflow routes work, an agent handles the messy subtasks, and a person shows up at the commit boundary.

Design packets reviewers will actually use

Lead with the delta. What's new compared to last run? What's the recommendation in one sentence? Put raw tool logs behind a fold or a link instead of on the first screen, and the review volume falls.

If the agent chose between two accounts with similar names, say so. Reviewers forgive hesitation. They don't forgive false certainty.

State the blast radius. One recipient or a whole segment? Draft or sent? Test environment or production connector? People pay the right amount of attention when they know the scope.

Track outcomes. When approvals always pass, ask whether the step should move earlier (better agent inputs) or disappear (true low risk). When approvals always fail for the same reason, fix the prompt, the data, or the tool scope instead of adding another approver.

Review cadence still matters. Placement catches individual mistakes, and cadence catches drift when prompts, integrations or source fields change, which they tend to do without fanfare.

How AI Agent helps

AI Agent is a no-code platform to build, deploy, and run agents that automate research, workflows, and reports. A workflow runs a multi-step job on a schedule or a trigger. An Autopilot gives one agent a written task and a trigger. Approvals are built into both, so you don't bolt them on afterwards.

Connect the tools your team already uses, such as Stripe, PostHog, GitHub, Notion, Linear, Slack, and Gmail. Then place approval where commits happen and make the briefing rich enough to trust. If your work is fixed if-then rules with an approver, a classic automation tool may be simpler. If an agent decides what to do next, built-in approvals save you from wiring up a separate review tool.

Which actions need approval

Sort every tool an agent can call into three levels, and let the level decide whether a person has to say yes. AI Agent uses this exact split in its connection tool access settings.

  • Reads retrieve information without changing the connected service. They run without approval.
  • Actions create, send, or update information. Each one waits for approval.
  • Destructive tools remove or irreversibly change data. They are off by default, need explicit access, and still wait for approval after you switch them on.

If a tool can't be sorted with confidence, treat it as an Action. AI Agent does the same: a tool it can't classify counts as an Action, so it needs approval and doesn't slip through as a read. Don't widen access just to make a failing task pass.

A few examples. Looking up a customer record is a read. Sending a reply, creating an issue, or updating a CRM field is an action. Deleting records is destructive. If you're unsure where an action falls, ask who sees the mistake and whether you can take it back.

Which workflow software offers approvals and human oversight

Several automation platforms let you pause a run for a person. They differ on where the pause sits, who can decide, and what the reviewer sees. The table compares the four tools using their own documentation. For a wider look at the category, see AI agent platforms compared and AI agents vs traditional automation tools.

Question Zapier n8n Make AI Agent
Where the pause sits A Request Approval action step in a Zap A tool call from the AI Agent node, for the tools you choose Human in the Loop modules in a scenario, such as Create a review request Each Action or Destructive tool call an agent proposes, plus an Approval block in a workflow
What the reviewer sees and decides A message and the content you submit; approve, decline, and optionally edit it The tool the agent wants to use and its parameters; approve or deny Not described on the app page. Its modules create, list, cancel, and watch review requests The provider, the account and every argument; approve or reject, with an optional reason on tickets
Availability Zapier's help page calls it a premium app that needs a paid account Set in the Tools panel of the AI Agent node, with approval channels such as n8n Chat, Slack, and Teams The Enterprise plan, in closed beta for invited customers Built into chat, tickets, the inbox and workflows

Zapier

Zapier's Human in the Loop app has a Request Approval action. It pauses the Zap and asks one or more reviewers to approve, decline, or change the data you submit. You choose whether a decline stops the run or lets it continue, and whether the reviewer can edit the content. Notifications go to email, Slack, or another Zap, and you can set a timeout and a reminder. Reviewers need Zapier accounts, and a Pro account can only send requests to yourself. See Zapier vs AI Agent for the wider comparison.

n8n

n8n lets you require human approval before an AI agent runs a specific tool. The workflow pauses and sends the request through a channel you pick, including its chat interface, Slack, Teams, Telegram, or email. The reviewer sees which tool the agent wants to use and with which parameters, then approves or denies. If the reviewer denies, the action is canceled and the agent is told. You can apply review to all tools on the agent or only a few. See n8n vs AI Agent.

Make

Make's Human in the Loop app adds human approval steps to scenarios. Its modules create a review request, cancel one, list reviews, and watch for completed reviews. The page says the app is available on the Make Enterprise plan and is in closed beta for invited customers, so check its current status before you plan around it. See Make vs AI Agent.

How approvals work in AI Agent

The approvals docs lay out two rules.

  1. An agent proposes, you approve. When an agent acts in Chat, on a ticket, in a workflow Agent step, or in an Autopilot, each Action and each Destructive tool call becomes a card. Nothing runs until you approve it.
  2. A workflow author allows chosen writes once. A Tool step that writes to a connected app, a Send step that emails people outside your organization, and an HTTP step that uses a method other than GET can run without a person after a one-time permission.

Cards appear in Chat, on a ticket under Needs you, and in the Inbox for email reply drafts. A workflow can also pause at an Approval block, which waits in the run and in Approvals waiting on the Workflows page. Approval applies to the displayed proposal. Approving continues that exact action, and rejecting stops it before it runs.

A Needs approval card on a ticket with Show all, Approve and Reject numbered.

The card shows the provider and the exact connected account, and Show all lists every argument in full. That's the soft stop from earlier, built into the interface: you review the real change instead of a summary of it. Email reply drafts offer Send, Save edits and Reject, and an edited draft goes out with your edited text.

A workflow Approval block lists its message with Approve and Reject buttons, and the run resumes from that point with your decision.

The Approvals waiting card on the Workflows page with one waiting step and its Reject and Approve buttons.

Workflow consent covers only the writes that the Allow these writes? dialog lists. Destructive tools are different. They're off by default, and a workflow Tool step can never run one unattended. If a workflow contains one, the dialog reads This workflow can't go live until you move the action into an Agent step, where it waits for approval. An Autopilot has no Approval block. It runs one agent, and each action that agent proposes on a connected app waits for you.

A worked example

Say you run a weekly workflow that reads your support tickets, summarizes the themes, and emails the result to a customer list. A sensible build has an Agent step that does the read-only research, an Approval block with a message such as "Send this summary to customers?", and a Send step after it.

When you set the trigger live, AI Agent opens the Allow these writes? dialog. It lists the Send step as Email people outside your organization, because that step writes outside your organization. After you choose Allow and set live, the run no longer needs a card for that send. The Approval block still holds the run until you decide, so a person still checks the final artifact and the recipient list. Reads ran freely, one stop sits before the commit, and nothing else interrupts you.

The Allow these writes? dialog, which lists every write a workflow makes on its own (this one shows two), with Cancel and Allow and set live.

You can review or revoke a granted permission from the workflow. If you revoke one that a live workflow still needs, the workflow pauses until you grant it again. A step whose permission was never granted doesn't run.

For setup details, read connection tool access and review and execute an action. You can also start from a prebuilt template, or check pricing.

What to measure

Three numbers tell you whether approvals are working. You run these yourself, whatever tool you use.

  • Approval rate by action type. A type that gets approved nearly every time may not need a stop. A type that gets rejected often needs better inputs.
  • Reject reasons. A short note on each rejection shows whether the agent, the data, or the tool scope is at fault. On ticket cards, AI Agent's Reject button accepts an optional reason, so reviewers can record why they rejected.
  • Time to decision. Requests that sit for days mean the wrong person is reviewing, or too many requests are arriving.

Governance and regulation

Two primary sources deserve a read. OWASP's LLM06:2025 Excessive Agency names excessive autonomy as one root cause, next to excessive functionality and excessive permissions. Among its mitigations it advises: "Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken." Approval covers the autonomy cause. Least privilege covers the other two, so tool access limits belong right next to approvals.

Article 14 of the EU AI Act covers human oversight of high-risk AI systems. It asks that the people assigned oversight can remain aware of automation bias, decide not to use the system or override its output, and interrupt it through a stop button or similar procedure. Whether your agent counts as high-risk is a question for your own counsel. This post is general information, not legal advice.

Who does what

Stage What the agent does What stays with a person What breaks without review
Research Gathers tickets, metrics, docs, and messages within scope Checks whether the sources and context fit the question A wrong account, time window, or source link poisons the conclusion
Recommendation Proposes an action and explains the evidence behind it Judges ambiguity, risk, and whether the proposed move is appropriate A wrong decision ships with confidence
Commit Writes, sends, charges, or merges after approval Approves the exact change and its blast radius The wrong customer record, message, or shared system changes

Frequently asked questions

What is human-in-the-loop for AI agents?

Human-in-the-loop means a person can review, change, or stop what an agent does before it takes effect. In practice you let the agent read and research freely, then pause for a person before an action that writes, sends, or spends. The goal is to keep human attention on the mistakes that are hard to undo.

Which workflow automation software offers approvals and human oversight?

Several do. Zapier has a Human in the Loop app with a Request Approval step. n8n can require approval before an AI agent runs a chosen tool. Make lists a Human in the Loop app for its Enterprise plan. AI Agent builds approvals into chat, tickets, the inbox, and workflow Approval blocks. Compare where the pause sits and what the reviewer sees before you choose.

Which AI agent actions should require human approval?

Anything that changes state outside the agent: sending a message, updating a record, creating an issue, charging, or deleting. Reads can run without approval. Destructive actions should need explicit access and approval. If you can't classify a tool with confidence, treat it as an action that needs approval.

What is approval fatigue and how do you avoid it?

Approval fatigue is what happens when people see so many requests that they stop reading them. Anthropic reports that users accept more than nine in ten manual permission prompts in Claude Code. Avoid it by asking less often and asking better. Let reads run, put one stop before the write, show the real arguments, and track approval rate and reject reasons.

Can an agent run without approval?

In AI Agent, yes for chosen workflow writes, after a one-time Allow these writes? consent when you set the trigger live. Agent actions in chat, on tickets, in Agent steps, and in Autopilots still wait for approval. Destructive tools stay behind explicit access and approval, and a workflow Tool step can't run them unattended.

human-in-the-loopworkflowsapproval