Alert fatigue: what health IT learned about too many prompts, applied to AI approvals

The short answer

Alert fatigue is the drop in attention people give to warnings as they receive more of them. A study of 112 primary care clinicians found that the likelihood of accepting a reminder fell by 30% for each additional reminder per encounter, and by 10% for each five-point rise in the share of repeated reminders. A quarter of drug alerts were repeats for the same patient within the year.¹ A simulation study found 30% of drug safety alerts handled incorrectly, and an alert shown as a second alert on one screen overridden several times without the physician noticing.²

Agent approval prompts are alerts by another name. The lesson carries over: ask rarely, never ask twice about the same thing, and make each prompt worth reading. Otherwise people approve on reflex, or choose “always allow”.

What the studies found

Repeats and complexity (2017). Ancker and colleagues analysed drug alerts and clinical reminders from 112 ambulatory primary care clinicians over three and a half years. They tested two explanations for alert fatigue: cognitive overload, from the amount and complexity of work, and desensitisation, from seeing the same alert over time.¹

Their conclusion: clinicians became less likely to accept alerts as they received more, particularly repeats, and reducing within-patient repeats is a promising target.¹

How alerts are handled (2010). Van der Sijs and colleagues watched 18 physicians enter 35 orders containing 13 drug safety alerts in a simulated order-entry system.² Thirty percent of alerts were handled incorrectly, because the action or the reason given was wrong. One alert, shown as the second alert on a screen, was overridden several times without the physician realising. A quarter of residents showed signs of alert fatigue. The authors questioned a predefined override reason, “will monitor”, and showing two alerts on one screen.²

Repeats are the worst kind

The 2017 study’s most actionable result is about repetition. Seeing the same alert again for the same patient made clinicians less likely to accept alerts in general, not just that one.¹ A repeated alert carries no new information, so it teaches the reader that alerts can be skipped.

In agent terms: if an agent asks to run SELECT count(*) FROM orders and you approve, then it asks again ten minutes later, and again, the third prompt is training you to stop reading.

Handled isn’t the same as handled correctly

The 2010 simulation separated two things a dashboard would blur: whether an alert was dealt with, and whether it was dealt with correctly. Most were handled, but the reasoning behind many was wrong.² A predefined reason such as “will monitor” let people dismiss an alert with an answer that sounded responsible.

Approval systems have the same trap. A green “approved” count looks like safety. What matters is whether the approver checked what they approved.

The same dynamics in agent approvals

The mapping from clinical alerts to agent prompts is close:

The last two rows have a direct, documented counterpart. In the GitHub MCP case, Invariant Labs noted that many users choose “Always Allow” for tool confirmations and stop watching individual actions.⁴ The MCP specification still asks clients to keep a human able to deny tool calls and to show inputs before calling a server.⁵ Both are right, which is why the number of prompts has to be managed.

The automation-bias research adds the other half: people over-rely on systems they trust, especially under time pressure, and accountability and good presentation help.³

An approval budget

One practical way to apply this is to give each approver a budget: a target for how many prompts a person should see in a day, set low enough that each gets real attention. Then design to stay under it.

1. Let rules decide the clear cases. Reads of non-sensitive data run without asking; destructive SQL is refused without asking. Only the ambiguous middle reaches a person.
2. Don’t ask twice. If an action with the same arguments was approved recently, don’t prompt again within a window you choose.
3. Group by effect, not by call. “This task will update 12 rows in orders” once, rather than twelve prompts.
4. One prompt per screen where you can, so nothing is overridden by accident as the second item.
5. No reflex answers. Avoid “always allow” for anything that writes; avoid canned reasons.
6. Measure. Prompts per approver per day, median time to approve, and how often a later review finds an approval was wrong.

If the budget is blown every day, that’s not a training problem. It’s a sign the rules are too loose or the agent’s tasks are too broad.

A checklist

1. Count prompts per person per day. Set a ceiling.
2. Suppress repeats for the same action within a window.¹
3. Move clear cases into rules, allowed or refused.
4. Show the effect, not just the call, so a prompt can be checked quickly.
5. Record who approved, what, and how fast.
6. Review a sample of approvals each week for correctness, not just completion.²

For the trust side of the same problem, see automation bias and human-in-the-loop. For setting up prompts in practice, approvals for MCP tool calls and Claude Code’s ask rules; for moving clear cases into rules, a tool-call policy. To see rules and approvals on a real database in your browser, try the playground; to grade what an agent can reach on your machine, run npx deedglass scan (the grade, explained).

Written with AI assistance and checked against our claims register.