Approval Fatigue: When AI Agents Ask Too Much

TL;DR: The agentic-AI world has settled on an answer to “how do we make agents safe?”: keep a human in the loop. Make the agent ask before it acts. It’s the right instinct, and it’s incomplete. An agent that asks about everything produces approval fatigue: you stop reading the confirmations and start rubber-stamping them, and you’ve built the feeling of safety without the substance. The real problem was never whether to confirm. It’s knowing what deserves a confirmation, and that turns out to be the hard part.

Approval fatigue and human-in-the-loop AI: mrmr's write gate confirms consequential actions like send, delete, and run, while skipping low-risk ones such as reading a channel, pasting, and marking a task done.

Every serious AI agent now promises the same thing: it won’t do anything without checking with you first. Human in the loop. Confirm before acting. Nothing happens behind your back. It’s reassuring, and it’s the right starting point. An agent that can send messages, move meetings, and delete things on your behalf should not be trusted to run unsupervised.

But watch what actually happens when an agent takes that promise literally and asks you about everything.

The first confirmation, you read. The tenth, you skim. By the fiftieth, you’re tapping approve before your eyes have finished the sentence, because forty-nine of them were fine and you have work to do. The confirmation step is still there. It just stopped meaning anything. You are no longer a human in the loop. You are a human rubber-stamping a loop.

That is approval fatigue, and it is the failure mode nobody selling “human in the loop” likes to talk about.

What approval fatigue is

The pattern is not new; AI agents just rediscovered it. Security teams have known it for years as alert fatigue: flood an analyst with warnings and they stop reacting to any of them, including the real one. The web version is consent fatigue, the cookie banner reflex where everyone clicks “accept all” without reading because the hundredth banner is indistinguishable from the first.

Approval fatigue is the same mechanism pointed at AI agents. When an agent asks for permission on every action, no matter how trivial, the asks blur together. Your brain, sensibly, optimizes: it learns that “approve” is almost always the right answer and starts skipping the part where you actually check. The safeguard trains you to defeat it.

”Confirm everything” is a fake kind of safety

Here is the uncomfortable part: a confirmation you don’t read is not a safeguard. It’s theater.

The whole point of a confirmation is that a human looks at what’s about to happen and catches the thing the agent got wrong: the message going to the wrong channel, the event being deleted instead of moved, the wrong customer on the wrong email. That only works if you’re actually reading. And you only keep reading if the asks are rare enough to be worth your attention.

So “confirm everything” is self-defeating. The more an agent asks, the less each ask is worth, until the confirmation is a reflex instead of a review. You end up with a system that looks maximally cautious and is, in practice, less safe than one that asks less but means it. Naive human-in-the-loop doesn’t keep you in the loop. It trains you out of it.

The real question: what deserves a confirmation

The instinct to fix this is to make the agent ask less. But “ask less” is the wrong frame, because it just trades approval fatigue for silent mistakes. The right frame is: ask about the right things.

Most of what an agent does genuinely does not need your sign-off:

Doesn’t need a confirmation:

Looking something up: reading a channel, searching your files, checking your calendar. A read changes nothing, so there is nothing to approve.
Pasting text into the app you’re already looking at. You can see it happen; an approval step there is friction without protection.
Marking a task done. It’s the lowest-stakes, highest-frequency write there is, and it’s trivially reversible.

Deserves a confirmation:

Sending a message to a person or a channel. It goes to someone, and you can’t unsend it.
Creating or deleting a ticket, moving or canceling a meeting. Other people see it and act on it.
Running one of your own scripts. It executes real code on your machine.
Anything the agent doesn’t clearly recognize as safe.

The list looks obvious written down. The hard part is that the agent has to make that call correctly, every time, in the moment, before it acts. And that is where the naive approaches quietly break.

Why you can’t just trust the agent to decide

The tempting shortcut is to let the model decide: teach it, in its instructions, when to ask and when not to. Just tell it “confirm consequential actions” and trust it to sort the rest.

This does not hold, for a simple reason: large language models are non-deterministic. The same request can produce different behavior on different runs. A model told to confirm consequential writes will mostly comply and occasionally not, and “occasionally” is exactly the case you built the safeguard for. Worse, a policy that lives only in the model’s instructions can be talked out of it, by a confusing request, an edge case, or a prompt-injection attack riding in on the content the agent is reading.

If the decision to gate an action lives only inside the thing you don’t fully trust, you don’t have a safeguard. You have a suggestion.

So the gate cannot live in the model alone. There has to be a layer between the agent’s intent and your apps, one that doesn’t get talked out of asking.

The layer in between

This is the part mrmr is built around, and it’s worth being precise about how it actually works, because the details are the point.

The gate is deterministic, not a prompt. When mrmr’s agent goes to take a write action, the app itself refuses to execute it unless you have approved a confirmation card that matches that exact action and its exact details. Not a spoken “yes,” which is too easy to misfire or coerce: an approval bound to the specific tool and the specific arguments. Change the message text or the recipient, and the old approval no longer counts. The model is still told to show you the card, but even if it somehow skipped that instruction, the write would be refused. The rule lives in the client, below the model, where a prompt can’t reach it.

It’s calibrated to fight approval fatigue on purpose. Reads never ask, because there is nothing to approve. A small set of genuinely low-risk actions are exempt by design: pasting into the app you’re focused on, or marking a task complete, because a confirmation there is cost without benefit. Everything with real consequences confirms. And critically, anything the system doesn’t recognize defaults to asking, so a new capability is never quietly run without your say-so. The bias is deliberate: skip the asks that don’t matter, so the ones that remain are worth reading.

It extends to your own code. When you let mrmr run your own scripts, each one carries a confirmation flag that defaults to on. You have to explicitly mark a specific script as safe to skip the prompt, in the script’s own header, and only a human can do that; the agent can never author that exemption for itself. Trust is something you grant deliberately, per action, not a default the agent hands itself.

Where exactly does the line between “ask” and “don’t ask” sit today? In a carefully maintained classification of what counts as a consequential action, with a fail-safe rule that anything ambiguous gets confirmed. That is honest work, and it is also not finished work. Making that boundary sharper, and evaluating it systematically so it stays right as the set of actions grows, is the ongoing problem. We would rather say that plainly than pretend the line draws itself.

Why this matters

Approval fatigue sounds like a UX nitpick. It isn’t. It’s the difference between a safety mechanism that works and one that only looks like it does. Two agents can both advertise “human in the loop,” and one keeps you genuinely in control while the other has quietly trained you to click yes. From the outside they look identical. The difference is entirely in what they choose to ask about.

The agents that earn real trust won’t be the ones that ask the most. They’ll be the ones that ask about the right things, and are honest about how hard that is to get right.

Frequently asked questions

What is approval fatigue? Approval fatigue is what happens when an AI agent asks for your confirmation on too many actions, including trivial ones. The requests blur together, you stop reading them, and you start approving reflexively. It’s the same effect as alert fatigue in security or consent fatigue with cookie banners: a safeguard that fires so often it trains you to ignore it.

Should an AI agent confirm every action? No. Confirming everything is self-defeating, because a confirmation you don’t read is theater. Reads and genuinely low-risk, reversible actions don’t need a gate. The consequential ones, sending messages, deleting or changing things, running code, do. The goal is to ask about the right things, not the most things.

How does mrmr decide when to ask for confirmation? mrmr enforces confirmation in the app itself, not just in the model’s instructions: a write is refused unless you’ve approved a card matching that exact action and its exact arguments. Reads never ask, a few low-risk actions like pasting or marking a task done are exempt by design, everything consequential confirms, and anything unrecognized defaults to asking.

Is human-in-the-loop the same as approval fatigue? No, they’re opposites in a sense. Human-in-the-loop is the goal: you stay in control of what the agent does. Approval fatigue is the failure mode of doing it badly, where the agent asks so often that you’re no longer really reviewing, just rubber-stamping. Good human-in-the-loop design is what avoids approval fatigue.

Try it

mrmr is a voice-first AI agent for Mac. It takes real action across your work apps and your Mac, and it’s built around exactly this idea: a deterministic layer between the agent and your apps that asks about the things that matter and stays out of your way on the things that don’t. It’s currently in private beta.

Join the private beta → Book a 20-minute setup call →

Related reading:

Approval Fatigue: Why "Confirm Everything" Breaks Human-in-the-Loop AI