Pull last month's approval log for your Business Central agents and sort it by the seconds between a card landing and the approver acting on it. Then open one of those cards, read it aloud, and time yourself. If the median in the log sits below your reading time, the log is recording clicks. Every row still carries a named approver and a timestamp, so nothing in it looks wrong.
AI approval fatigue is what happens when a named human is asked to approve more agent actions than they can read, and the approval turns into a reflex. The gate stays in place and the log keeps filling. Dwell time falls toward zero, the approval rate climbs toward 100%, and overrides disappear. The control no longer controls anything, and the record says someone decided.
Most governance plans treat a human on every agent action as the conservative setting. This article rejects that assumption. Every added gate lowers the attention available to every other gate, so the setting with the most approvals is the one where the approvals that matter get the least reading.
The roadmap article covers one failure of blanket governance: over-restricted agents push people toward workarounds outside IT's line of sight. Reflex approval is the same failure staying inside the system. The workaround is the click. The stop-button article covers who can halt a run that is already posting. This one asks whether anyone is still reading the card that started it.
From the work
Written from 5+ manufacturing and distribution engagements, 2022-2026, on Business Central approval routing. No approval-rate benchmark from a live deployment appears below. OpsGrid has not published one, and every figure you act on here comes from your own log.
AI approval fatigue has a precedent: MFA push fatigue
Identity teams have a documented version of this failure. A push notification asks one yes-or-no question, the approver cannot check the answer from the prompt, and the cheapest response is yes. Microsoft's documentation on protecting authentication methods in Microsoft Entra ID (Microsoft Learn, page dated 4 May 2026) records the response: "in response to increasing MFA fatigue attacks, Microsoft recommended ways for customers to defend users. To prevent accidental multifactor authentication (MFA) approvals, enable number matching." The same page says "As MFA fatigue attacks rise, number matching is critical to sign-in security." Microsoft made it the default for every Authenticator push notification, and users cannot opt out. CISA's archived More than a Password page gives the same advice in one line: "consider using numbers matching MFA to block mobile push bombardment and SMS-based attacks."
One difference changes your design. MFA fatigue is an attack: an adversary controls the volume and floods one user until the user taps yes. Nothing attacks your approvers. Your own routing rules generate the volume. The mechanism is the same, an approver answering faster than they can evaluate, with one consequence for the fix. You cannot cap an attacker's prompts. You can cap your own, which makes the first half of your fix a volume decision that Microsoft's fix never had to include.
The second half changed what a yes requires. Microsoft did not ask users to try harder. Three of its controls translate to an agent approval card.
| Entra control | What Microsoft Learn says it does | Equivalent on an agent approval card (design principle) |
|---|---|---|
| Number matching | "When users respond to an MFA push notification by using Authenticator, they see a number. They need to enter that number into the app to complete the approval." | Typed confirmation. The approver enters the figure the card releases (PO value, quantity, payee) before the Approve button enables. A reflex click cannot complete it. |
| Additional context | The prompt shows "the name of the application that requests the approval and the location" the request came from. | Evidence on the card. The figures behind the proposal travel with it: stock cover in days, supplier, change against the last PO, the customer commitment it would touch. |
| Default on, no opt-out | "users can't opt out of number matching in Authenticator push notifications." | The read-forcing step applies to every approver. Nobody switches it off to clear a backlog. |
The first row carries the weight. A typed confirmation costs seconds, and the cost is the point: it sets a floor under dwell time. Decision latency work pushes dwell time down, and a plain Approve button has nothing to stop it falling past reading speed.
How to detect AI approval fatigue in a Business Central approval log
Your approval log already answers three questions. A fourth needs a test.
- Dwell time against reading time. Seconds from card delivered to decision, by card type. Read five cards of each type aloud, take the median, and call it your floor. A card type with a median dwell under that floor has an approver who is not reading it.
- Approval rate by card type. A rate at or near 100% has two readings that look identical in the log: the agent is right every time, or nobody is checking. Dwell time against your floor tells you which.
- Edits, rejections, and send-backs. A gate that never produces a no has no evidence it works.
- The canary card. Stage a proposal with a planted error, such as a quantity ten times the usual or the wrong payee, in a sandbox environment or the CRONUS demo company. Route it through the real approval path to each approver class and record who approves it and how fast. A canary approved in less time than your floor is the finding, and no log analysis gives you a clearer one.
OpsGrid's management view lists, per signal, cards sent, approved, rejected, and average response time. The page reads a high rejection rate as a threshold firing on false positives. Read it from the other end too: a signal with almost no rejections and a short average response time is the one to run a canary on. OpsGrid has published no approval-rate data, and this article cites none.
A reflexive approval still puts a name on the record, attached to someone who spent less time on the card than it takes to read. For what a defensible record holds, see why a correct AI decision still needs a named approver.
Fewer, ranked approvals: human-in-the-loop thresholds that get read
Adding a second approver to a queue nobody reads doubles the clicks and leaves the reading where it was. The repair is less volume per approver and more evidence per card. Five moves, in order:
- Count the cards per approver per day. An approval matrix lists who approves what. Add a column for cards per approver per day. That column is the one you can tune.
- Split by reversibility before value. Actions that are cheap to undo, such as reorder-point proposals, item reclassification, and reversible posting corrections, leave the synchronous gate for sampled after-the-fact review. The oversight-pattern table in the roadmap article maps these to Business Central document types.
- Set value bands where an undo is expensive, and rank by cost impact. Keep the synchronous gate for a PO above the approver's limit, a credit hold release, or a change to a supplier's payment terms. Rank the queue so a $400,000 exposure does not sit behind forty $400 reorders in a chronological list. If you set the bands in Business Central's own engine, its native limits are covered here.
- Put the read-forcing step on every card that remains, and cap the daily count. Use the typed confirmation and the evidence from the table above. When an approver's queue passes the cap, the overflow escalates to a named delegate. It does not wait for a faster click.
- Review dwell time and rejection rate monthly, and treat 100% as a finding. A card type that holds a 100% approval rate for a quarter has either an agent worth promoting to sampled review or an approver worth interviewing. Both are decisions. Leaving it alone is not one.
The Decision Latency Diagnostic scores one side of the Approve stage: how long approvals sit, and whether a delegation rule fires when the approver is out. This article covers the opposite side. Score the slow side first. Cutting approval latency with no floor under dwell time builds the reflex.
Where approval fatigue meets decision infrastructure
This is the Approve stage of decision infrastructure: a named owner per decision, a threshold that decides who sees it, and a record of what the approver saw. OpsGrid's published pages describe cards ranked by cost impact in Microsoft Teams, a dollar figure and days of cover on the stockout card, a named decision owner, and nothing posting to Business Central without that owner's approval. They also describe the flow as one confirmation per card. That is the card shape this article warns about, and the per-signal view above is how you would see whether it is being read. The pages do not describe typed confirmations, daily caps, or autonomy tiers, so the table above is a design principle, not a feature.
Frequently asked questions
What is AI approval fatigue?
AI approval fatigue is what happens when a named human is asked to approve more AI agent actions than they can read, and the approval becomes a reflex. The gate stays in place and the log keeps filling with named approvers and timestamps. Dwell time falls, the approval rate approaches 100%, and overrides disappear, so the record shows a decision that nobody made.
How do you measure approval fatigue in AI agent approvals?
Run four checks. Compare dwell time, the seconds from card delivered to decision, for each card type against the time it takes to read that card aloud. Look at the approval rate for each card type, where 100% means the agent is always right or nobody is checking. Count edits, rejections and send-backs. Then send a canary card, a staged proposal with a planted error, through the real approval path in a sandbox and record whether it is approved and how fast.
Does requiring human approval on every AI agent action make it safer?
No. Every added gate lowers the attention available to every other gate. Security teams saw the same failure with MFA push prompts. Microsoft responded with number matching, which makes the approver enter a number shown on the sign-in screen to complete the approval, and made it the default for Authenticator push notifications. For agent approvals the fix is fewer, ranked approvals: reversible actions leave the synchronous gate, value bands decide who sees what, and the cards that remain force the approver to engage with the figures.
What should replace a blanket approval gate on Business Central agents?
Tiered oversight. Count the cards each approver receives per day, move actions that are cheap to undo to sampled after-the-fact review, and keep synchronous approval for actions that are expensive to undo. Rank the queue by cost impact, cap the daily count per approver with escalation to a named delegate, and review dwell time and rejection rate monthly.
Ask your approvers when each last rejected an agent's proposal. If nobody remembers, run the canary card this week. For who can halt an agent that is already posting, see your AI agent has an approval gate and no stop button.