The question I get most often from boards this year is a ratio. How many AI agents can one person supervise?
The answers that arrived over the summer are specific. A Forbes council piece in July suggested a top product manager may supervise 180 agents and a head of supply chain 300. A maturity index in August put the range at hundreds of agents per human in logistics and one agent per one to three humans in legal and underwriting. An engineering guide derived its ratio from hours instead, capping review work at half of a person's time.
To be fair, two of the three mention overload, and one names rubber-stamping outright. None treats the reviewer's reliability as something that changes with the load routed to them. The human-agent ratio prices the human as a fixed resource. The person approving the two-hundredth escalation of the day is assumed to read it the way they read the first.
Human oversight of AI agents has a capacity
I have never met that person. Two research literatures and one breach suggest nobody has.
Two different failures share a cause here. Automation bias is the drift toward accepting whatever the system recommends. A 2017 systematic review found evidence of it in 81 percent of the studies that tested for omission errors and 91 percent of those that tested for commission errors. Alert override runs the other way, the clinician rejecting the warning. A 2006 review of drug-safety alerts in hospital ordering systems found them overridden in 49 to 96 percent of cases and described alert fatigue, too many alerts consuming time and mental energy, as a driver nobody had yet studied properly. Opposite directions, one tired reviewer. Load is a named driver in both literatures, and in neither is it the only one.
Security has its own version. In September 2022 an attacker got into Uber's internal systems. By Uber's own account, the attacker likely bought a contractor's corporate password on the dark web after malware on a personal device, then tried to log in again and again. Each time the contractor received a two-factor approval request that "initially blocked access," until the contractor "eventually" accepted one. With the password already gone, the prompt was the last line, and a yes-or-no prompt holds only as long as the person behind it is still deciding.
Approval fatigue, modeled
In June 2026 an independent researcher, Emre Turan, posted a preprint that put a tiring reviewer inside an agent approval gate and ran the numbers. An agent proposes an action, a guard decides whether to let it through or escalate it, and the modeled human is near-perfect up to a personal capacity and then increasingly likely to miss danger with every review past it. The paper says plainly that the fatigue mechanism is prior art. What it adds is the measurement.
Run the model and safety does not climb in a straight line. It climbs, peaks, and falls. At a reviewer capacity of 25, reproduced from the paper's published code, escalating under 5 percent of actions lets 93 percent of dangerous actions through, escalating everything lets 57 percent through, and the best result, 43 percent through, sits near two-thirds escalation. The model's advice is to escalate most things and stop before the reviewer is past capacity. Anyone quoting it as a licence to escalate less has read the wrong end of the curve. Even at the peak, close to half the dangerous actions still pass. That is the honest ceiling on what a yes-or-no gate buys.
The paper calls its own curve "a modeling result about a plausible model, not an empirical finding about real people." Its reviewers were language-model personas, and they only moderately agreed on what counted as risky. A human study, the author writes, would to their knowledge be the first empirical fatigue curve for agent-action review. So: a decades-old mechanism, a modeled shape, and a curve for your reviewers on your queue that nobody has drawn.
Reproduced from the paper's published code and saved scores at three reviewer capacities. A modeled curve; no real reviewers were measured.
Automation bias is already named in law
The EU AI Act already anticipates a reviewer who tires, and it places the duty where it belongs. Under Article 14(4)(b), a high-risk system must be delivered to the deployer in a way that enables its overseers "to remain aware of the possible tendency of automatically relying or over-relying on the output," and the statute names that tendency: automation bias. That is a design obligation on the provider, on the statute book today and binding for standalone high-risk systems from December 2027. The concession inside it is the point. The overseer's reliability is a variable the system has to support rather than a constant it can assume.
Singapore's voluntary framework for agentic AI, from January 2026, goes to the operational consequence: trigger human approvals at significant checkpoints, and "regularly audit the effectiveness of such human approvals." You only audit something that can decay. India's national AI governance guidelines, guidance rather than statute, have one line I keep coming back to. In some contexts, such as high-velocity algorithmic trading, "direct human oversight is ineffective," and circuit breakers and system-level constraints should carry the load instead. A national government has written down that human oversight has a speed limit. Volume is speed measured over a working day.
Past a reviewer's capacity the gate stops being a control and becomes governance theatre with a signature on it. The signature is the problem. It belongs to the reviewer, while the people who set the escalation threshold, bought the platform with the human-in-the-loop checkbox, and sized the review team appear nowhere on the log.
The four stages are an editorial synthesis. The figures on the graphic come from the sources named on it; no single study has measured this exact curve.
What to measure instead of the ratio
A capacity number describes the design of a queue. Used as a diligence score for the person at the end of it, it will discipline the one reviewer who slowed down to read.
Two numbers per queue are easy to collect: the escalation rate reaching each reviewer and the median time per review. On their own they are ambiguous, because falling review time with rising approvals is also what a maturing deployment looks like once the guard has been tuned on early rejections. The control that separates improvement from decay is the one security teams already use for phishing. Seed known-bad actions into the live queue at a known rate and watch the catch rate per reviewer as load rises. Where the catch rate breaks is the capacity.
Then design for the person who tires. Give each reviewer a defined slice of risk and a named escalation path instead of a shared queue, so overload shows up as one person's load with a name on it. Overflow needs somewhere else to go: a block, a deferral, or a second reviewer. Never the same inbox.
Reversible actions can take a pre-committed, audited path, provided someone is accountable for deciding which actions those are; a payment is reversible until it settles and a deletion never is. Pre-committed stop criteria belong in the same design, so the volume that triggers a pause is decided before the person making the call is the tired one.
If agents behave like labor, the reviewer is a supervisor, and nobody reports a supervisor's span of control without the load that comes with it. Report the ratio the same way.
So the number I would ask a board for isn't agents per employee. It's escalations per reviewer per day, set against a capacity the organization has measured for itself, because nobody else has.
The reviewer who never tires does not exist. Design for the one who does.