Consent Fatigue and Over-Routing for the CCAR-P Exam

Why "review everything" is not the safe default

Deciding which decisions count as high-stakes takes judgement, and the tempting way to avoid that judgement is to route everything to a person. The CCAR-P exam treats recognising why this fails as an evaluate-level skill, because "review everything" masquerades as the conservative choice while actively degrading oversight. It is easy to defend to an auditor and requires no call about where the stakes sit - which is precisely why it is seductive and precisely why it is wrong.

The mechanism is capacity. Human review is a finite budget of attention, and when the volume routed to a person exceeds what they can read in the time they have, oversight that covers everything ends up reviewing nothing. The reviewer disengages to keep up, and the review collapses into approval. Routing everything does not add safety; it dilutes it across so many items that none receive the scrutiny the high-stakes ones needed.

Consent fatigue is a predictable human response

Consent fatigue is the specific failure that over-routing produces. When a system asks for approval dozens of times in a row, reviewers start clicking through and approving items without reading them or providing the quality of review needed. It is not a lapse of individual discipline; it is the predictable response of any person subjected to a stream of approval requests faster than they can meaningfully evaluate. After the first hour of a flooded queue, approving to keep pace becomes the only way to survive the volume.

Anthropic's own research on agent autonomy reached the same conclusion from the other direction: requiring sign-off on every action adds friction without a meaningful safety gain compared with placing review at higher-value checkpoints. The better pattern is to have a person monitor what is happening and step in when needed, and to move review to higher-value moments - a plan review, an exception, an irreversible action - rather than gating every step. That is the reasoning behind plan-level review in agent workflows, where a person approves the plan rather than each individual step. (Verify the current framing against Anthropic's published agent-autonomy and trustworthy-agents research at publish time.)

Anthropic names the underlying capability diligence, one of the four AI Fluency competencies concerned with ensuring responsible AI collaboration. In deployment terms it means keeping explicit human accountability checkpoints, noticing when automation pressure is quietly eroding oversight, and auditing workflows for places where the system is acting without review as it scales - and consent fatigue is precisely the erosion diligence is meant to catch. For agent workflows the stakes-based routing rule hardens into a checkpoint pattern: a gate that pauses execution for human review, keyed to that task's risk and reversibility. Place a gate before any irreversible or high-stakes action the agent would otherwise take autonomously, and sample the lower-stakes actions instead of gating each one - the same move as routing by stakes rather than by volume, expressed in the gate vocabulary that multi-agent designs already depend on.

Two independent failures that each break review

The subtle, evaluate-level point is that review can be broken in two independent ways, and fixing one does not rescue the other. The first is volume: too many items routed, so the reviewer cannot read them all. The second is missing context: the reviewer sees only an output with an approve button and has nothing to judge it against. These are separate failures with separate fixes - stakes-based routing for the first, a proper reviewer view for the second.

Crucially, either failure alone is enough to make review fail. A small, well-scoped queue with no context still produces rubber-stamping, because the reviewer cannot judge what they see. A well-built reviewer view drowning under thousands of items still produces rubber-stamping, because the reviewer cannot keep up. So a design that fixes only the volume or only the context has not fixed review - it has removed one of two independent ways review was already collapsing. The exam rewards spotting when both are present and requiring both fixes.

What the CCAR-P exam trips candidates on

The first trap is believing that "review everything" is the conservative, safe default. The scenario frames routing all decisions to a person as the cautious choice; the credited reading is that in practice it degrades review quality for every item, including the high-stakes ones, because the volume overwhelms the reviewer. Safety comes from routing by stakes, not from routing everything.

The second trap is adding more reviewers to handle volume instead of fixing the routing rule that sends low-stakes items to the queue. A scenario proposes scaling headcount to absorb the flood; the credited reading is that this treats the symptom while leaving the cause - the over-routing rule - in place, and that the real fix is to route by stakes so only decisions that warrant attention reach the queue. The exam also tests whether you catch that a scenario has both the volume and the context failure and needs both addressed.

Common misreadings to avoid

How this shows up on the exam

Domain 5 items describe a flooded or rubber-stamped review queue and ask what went wrong and how to fix it. The reliable method is to check for both independent failures - excessive volume and a context-poor reviewer screen - and to prescribe stakes-based routing for the first and a proper reviewer view for the second, rejecting "review everything" and "add more reviewers" as answers. If both failures are present, both must be fixed.

This anti-pattern is the failure mode of getting the stakes-based routing rule wrong in the over-routing direction, and its second failure is the absence of what the reviewer's screen must show. It also interacts with review placement trade-offs, since over-applying pre-action approval to low-stakes decisions is one way a queue floods.