Oversight Capacity

A51
Concepts · Agentic AI Explained

Oversight capacity: the budget your approval gates are spending.

A reviewer is a finite instrument with a measurable throughput, and once your agents escalate more decisions per hour than that instrument can make, each gate you add buys less safety than the one before it — and past some rate, buys negative. Oversight capacity is that throughput written down as a number, and it is what separates an approval gate that is a control from one that is a receipt.

Step 1Count reviewer-seconds, not gates.

Every piece of guidance on human-in-the-loop design answers the same question: which actions should stop for a human. Gate the irreversible, the externally visible, the privilege-changing, the high-value. That rubric is correct and it is incomplete, because it says nothing about how many. Two deployments running the identical policy — same tools, same rubric, same wording in the dialog — behave like different systems at 4 escalations an hour and at 400. The quantity that separates them is not on the policy page.

Write it down. Oversight capacity is the number of escalations your reviewers can genuinely decide per hour: attention actually available, divided by the attention one competent decision costs. The numerator is easy to estimate and always smaller than a headcount suggests — nobody reviews for sixty minutes in an hour. The denominator is the hard half, because the cost of a decision is set by how much context the reviewer must reconstruct before the verdict means anything.

# One reviewer, one shift, one honest decision cost.
reviewers                          1
attention available per hour    2400 s   # 40 of 60 minutes
seconds per competent decision    90 s   # read the diff, check the two
                                         # records it touches, decide
----------------------------------------------------------
oversight capacity                26 decisions/hour

# The fleet it is asked to cover:
40 agents x 12 actions/hour  =   480 actions/hour
gate rate 20%                =    96 escalations/hour
2400 s / 96                  =    25 s per escalation, against 90 s needed

Notice what does not happen when demand exceeds capacity. The queue does not stall and nothing raises an alarm, because an approval queue has no backpressure: the reviewer silently reprices every decision from ninety seconds to twenty-five. Throughput is preserved and the thing you were buying — a competent verdict — is quietly discontinued. This is why over-capacity oversight is so hard to notice from the dashboard. Approval latency improves.

If you have never computed this number, you do not know whether your gates are controls. The fastest way to find out is not an audit: take your escalation rate from last week's logs, divide the reviewer-attention you actually believe exists by it, and compare the result with how long a careful decision takes. Most teams discover they are running at several times capacity and have been treating the resulting approvals as evidence.

Step 2Past capacity, the gate inverts.

The intuitive model is that oversight degrades gracefully — more gates, a bit more friction, slightly worse decisions. The mechanism says otherwise. Model the reviewer as fatiguing rather than tireless and realized safety becomes an inverted U in the escalation rate: it climbs while coverage is cheap, peaks, and then falls, because the marginal escalation costs attention that the decisions already in the queue were relying on. Emre Turan's Oversight Has a Capacity: Calibrating Agent Guards to a Subjective, Fatiguing Human (arXiv 2606.08919, submitted 8 June 2026) derives exactly that shape, along with a flooding attack: bury one harmful action in a long stream of routine approvals and it is rubber-stamped, while a reviewer asked five times reads each request.

Read that paper for the mechanism rather than the magnitudes, and the paper says so itself — the inverted U and the flooding result are consequences of a plausible fatigue model, offered to motivate a human study, not measurements of humans; the dataset is 125 hand-labelled coding-agent actions from one domain, which demonstrates the instrument rather than estimating a population. What travels further is a measurement from the same work that needs no fatigue assumption at all: on those 125 adversarially weighted actions, reviewer agreement on which ones were risky came out at a Fleiss' kappa of 0.52 — moderate. Three competent people shown the same agent action disagree about whether it should have stopped.

That number is the one to sit with, because it is a property of the task and not of the roster's tiredness. If agreement is moderate, a gate's output is partly a function of who is on shift, and the threshold you tuned is sitting on top of noise you have not characterised — the threshold-setting problem in its human form.

Then there is the half that makes this a security property rather than an ergonomics one: the escalation rate is attacker-controllable. A compromised or injected agent that can cause two hundred benign-looking approval requests has bought, for free, a twenty-five-second review of the one request that matters. It is the oversight analogue of denial of wallet — call it denial of attention — and it means your capacity figure is not merely a staffing input. It is a control with an adversary.

An agent does not need to be compromised to flood you. A badly scoped gate does it by accident: one team's "gate every outbound HTTP request" turns a single research task into a hundred near-identical dialogs, and the reviewer who clears them has been trained, by your own design, to clear the next one too.

Step 3Four things to measure instead of assuming.

  • Time-to-decision, as a distribution, per escalation class. Not the mean — the mean hides the mode. A spike of sub-five-second decisions is the signature of a reviewer over capacity, and it is visible in data you already have.
  • The approve rate. An approve rate near 100% is not evidence of a well-behaved agent; it is evidence that the gate is not discriminating. Either the policy is stopping the wrong actions or the reviewer has stopped reading, and both are findings worth the query.
  • Queue depth at the moment of decision, paired with the verdict. This is the one measurement that lets you find the inverted U in your own traffic rather than taking it on trust: if approval probability rises with queue depth, you have located your capacity, empirically, in production.
  • Inter-reviewer agreement. Route a small sample of escalations to two reviewers independently and compute agreement. If it is moderate, stop tuning the threshold and go fix what the dialog shows — the usual cause is that the request describes an intent instead of an effect.

All four are cheap, and none of them require a new tool: they are joins over the decision log you need anyway for decision receipts. The reason they are rarely computed is that nobody owns the number. Oversight capacity has no natural home — it is a safety property measured in staffing units, so it falls between the security team and the operations team and lands with neither.

Step 4Spend the budget deliberately.

Capacity can be raised, and the leverage is almost entirely in the denominator. Cutting the cost of one decision from ninety seconds to twenty quadruples capacity without hiring anybody, and it is the same work as making the decision correct:

  • Bind the approval to a computed effect. A dry run that shows the diff the same code path will apply turns reconstruction into reading. A dialog describing what the model intends to do leaves the reviewer to work out the effect themselves, which is most of the ninety seconds.
  • Batch into plans. One reviewable plan — "send these three emails, update these two records" — costs a fraction of thirty separate dialogs and gives the reviewer the only context in which the individual actions mean anything. The UX half is approval and confirmation UX; at fleet scale it becomes a review queue with a priority order.
  • Reduce demand before raising coverage. Most escalations in a mature deployment should never have been escalations. Narrow the tool, scope the credential, and the action becomes safe to run unattended — blast radius is the cheaper lever and it needs no reviewer at all.
  • Price the gate. If every gated action costs the same attention, you are spending the budget uniformly on a non-uniform risk distribution. Risk-scored permissions is how you spend more on the few.
  • Set a cap, and decide now what happens at it. This is the decision that determines whether the gate survives contact with a busy week. When escalations exceed capacity, the agent should pause, degrade to read-only, or shed lower-risk tasks — failing closed. The common alternative, auto-approving the overflow, does not degrade the control; it deletes it, and does so precisely when an attacker would want it deleted.

Capacity also sets the honest ceiling on fleet size, which is the uncomfortable part. If a reviewer can decide 26 escalations an hour and your agents produce 96, you have three options and only three: make decisions cheaper, make escalations rarer, or run fewer agents. Buying a fourth — more agents behind the same gate — is a decision to stop overseeing them, and it is usually made without being written down anywhere. The cost side of this trade is in the cost of human review, and the version where the checker itself must act is when the check has to act.

Compute one number this week. Take last week's escalation count, divide the reviewer-attention you actually believe in by it, and put the result next to how long a careful decision takes. If you are over capacity, do not add a gate — bind an existing one to a computed effect, batch the rest into plans, and set the rule for what the fleet does when the queue exceeds what a human can decide. A gate nobody has the time to decide is not oversight; it is a log line that says a human was present.