Zero of 20 Agent Platforms Mention Approval Fatigue. Seven Ship the Button That Causes It.

TL;DR: Because the gate degrades into a reflex, and nobody who sells the gate has written that down. On August 15, 2026 I read the public approvals documentation of 20 agent platforms. Zero of 20 acknowledge reviewer fatigue, rubber-stamping or over-approval. Zero of 20 document any rate limit on how many approvals an agent may request. Zero of 20 document a time-boxed or expiring approval grant. Meanwhile 7 of 20 document an "approve all" escape hatch, and in 4 of those it is permanent. Only 3 of 20 let you condition approval on a built-in risk signal rather than on tool identity alone.

Human-in-the-loop is the answer every vendor gives when you ask what stops the agent doing something catastrophic. It is a real control and I use it. It also has an obvious failure mode that the entire category has declined to write down: a gate a human passes fifty times a day is not a gate, it is a turnstile.

What did 20 vendors' approval docs actually say?

I read primary vendor documentation only, no marketing pages and no third-party blogs, and coded five questions per platform. Twenty had readable docs. Ten more candidates were dropped and deserve naming, because "we could not read it" is not "it does not exist": Decagon's docs redirect to a login, Sierra's and Moveworks' doc paths 404, and Glean, Salesforce Agentforce, ServiceNow, Make, Lindy, Dust and Writer either render client-side into nothing a fetcher can read or have no locatable approvals page. Everything below describes what the public documentation says, not what the product does.

Question (n=20, read 2026-08-15)	Result
Approval conditioned on a built-in risk signal	3
Conditioning possible but DIY (your own callback)	7
Per-tool / per-task toggle only	7
Gate is the model deciding to ask	3
Documents an "approve all" hatch	7 (4 permanent, 2 scope-capped)
Documents an approvals audit log	3 partial, 0 complete
Documents a rate limit on approval requests	0
Acknowledges reviewer fatigue anywhere	0

The three with real conditioning are worth crediting. Gumloop ships an actual policy engine: "App Rules let you define conditional approval requirements using CEL expressions that evaluate the actual arguments of each tool call." Cursor lets you write plain-English block rules and is honest that "auto-review is not a security boundary." Devin hard-codes a never-auto-approve list covering rm, sudo, mutating git operations, kubectl delete and anything touching dotenv files or key material. Google's ADK is the only documentation set I found that shows a money threshold as the example, return amount > 1000, and it is marked experimental.

Everyone else conditions on tool identity or nothing. CrewAI is per-task: human_input=True prompts before the agent delivers its final answer, which is not a tool gate at all. Microsoft Copilot Studio's per-tool "Ask the end user before running" is documented as "set to No by default."

The finding I did not expect is the third row. In three platforms the gate is a prompt. Zapier Agents tells you to "add a sentence like 'ask for my confirmation through [messaging app] before continuing.'" UiPath says the prompt "acts as a triggering condition." Relevance AI has a mode where the agent decides based on "its confidence and context." An instruction in a system prompt is not a control, which is the exact lesson from the agent that deleted a production database in nine seconds.

Why is "approve all" the whole ballgame?

Because it is the pressure valve, and the pressure is never measured. Seven platforms document a way to stop asking. Two cap it by construction: OpenAI's Agents SDK alwaysApprove lasts for the run, and Microsoft's Agent Framework holds standing approvals inside an AgentSession. Four are durable. Cursor's "Run Everything" mode runs every tool call automatically. Devin offers five tiers ending at "allow globally." The Claude Agent SDK documents an "approve and remember" choice that writes the rule to a local settings file "so future sessions skip the prompt." Gumloop saves "don't ask again for this tool" to the agent's configuration, and its "always allow" setting is documented as the default.

None of the twenty expire. Not one documents an approval grant that lapses after an hour, a day or a deployment. Revocable by editing a config file is not expiry, because nobody goes back.

And nobody counts. Zero of 20 rate-limit approval requests, and Gumloop states the opposite outright: it "can wait indefinitely for your response." Temporal has timeouts and UiPath routes tasks to "the group member with the fewest pending tasks," which is the only mechanism in twenty vendors' documentation that touches reviewer load at all, and it distributes fatigue rather than detecting it. So the volume of asks is unbounded, the escape hatch is permanent, and the record of who clicked what is partial in 3 platforms and complete in none. Not one of the twenty documents a log that records who approved a call, when, and whether they read it.

The three passages that come closest to the subject treat prompt volume as a UX cost to eliminate. Cursor: "you want fewer prompts." Devin: "grant blanket access to a trusted MCP server without approving each tool individually." Gumloop: "internal emails go through without interruption." CrewAI puts the load on the human instead and asks you to "respond to HITL prompts promptly."

Is the cookie-banner comparison fair?

Partly, and only as an analogy. It is not evidence about agents, and I am not going to pretend it is.

The study is Nouwens, Liccardi, Veale, Karger and Kagal, CHI 2020, which scraped the five most popular consent platforms across the top 10,000 UK websites, n=680, and found "only 11.8% meet the minimal requirements that we set based on European law." The authors are explicit that this is a ceiling, not a point estimate: their three testable conditions "provide a window on the maximum level of compliance." So the number is 11.8%, not the single-digit figure that circulates, and it measures banner design against three legal conditions, not whether anyone read one.

The half of that paper that actually transfers is the field experiment, n=40 participants across eight designs. Removing the opt-out button from the first page increased consent by 22 to 23 percentage points. Adding granular controls to the first page decreased consent by 8 to 20 points. That is a measured effect of interface friction on what a human agrees to, and it is the closest published thing I have to a mechanism. It does not measure agents, reviewers, or repetition. It measures forty people clicking dialogs in a lab. Treat it as the reason to be suspicious, not as the proof.

What would change my mind?

A vendor publishing approval telemetry. Median time-to-decision, approval rate by tool, share of approvals granted in under two seconds, share of sessions where "always allow" got switched on and never off. Any one of those turns this from an argument into a measurement, and every platform in the sample already has the data.

Until then the honest read is narrow. Absence from documentation is not absence from the product, and several of these teams have surely thought about this internally. But the docs are what an operator buys on, and what the docs describe is a confirm dialog, a button that turns it off, and no instrumentation in between. That is the same walk-back pattern as the very expensive cron job with a reviewer, and it is probably a real contributor to the cancellation rates the agentic-project forecasts already predict. The gate is not the problem. Shipping the gate and never measuring whether anyone is still reading it is.