Three Oversight Numbers Your Fleet Should Publish Internally

About one in 47,000. That is how often Anthropic’s online monitor blocked an action by its own research and engineering agents in August 2026, counted across more than a billion decisions. The figure is striking, but the three metric names printed around it are more useful: coverage, review latency and escalation rate. They are AI agent oversight metrics with written definitions, from a lab that runs agents at scale, and you can compute every one of them on your own fleet.

This runbook turns those definitions into a weekly internal page. By Tuesday every monitor in your fleet reports what share of actions it saw before they ran and after, how long each leg of review took at p50 and p95, and one escalation rate of its own, with the human-reviewed count and the open backlog printed beside it.

Some cells will read “not measured”. Keep them. A missing number is the gap you close next.

Chatbots suggest; agents act. An approval queue meters the handful of actions that stop and wait for a person. A fleet of acting agents takes thousands of actions that never stop, so oversight becomes a set of fractions: how many of those actions any monitor saw, how quickly a verdict and then a human arrived, and how often something tripped.

Anthropic’s oversight page gives you definitions, not a benchmark

The Anthropic Institute page, Measurements for understanding the pace of AI development inside frontier labs, by Marina Favaro and Phillie Wright, went up on Sep 17, 2026 (the date press coverage gives; the page itself is undated), with data as of August 2026. In that month, it says, roughly 30,000 agents were doing research and engineering work at any one time on Anthropic’s most-used internal platform. That is concurrency, not a headcount of distinct agents.

Every action those agents take meets two monitors. The online monitor checks actions in real time and either blocks dangerous ones or steers the agent; it exists for harms that happen fast and can’t be undone, and the page’s example is an agent copying model weights out. The offline monitor ingests every action after it is taken and looks for slow, reversible trouble such as signs of misalignment.

The page then defines the three metrics. In close paraphrase: coverage is the share of an agent’s actions that pass through a monitor, before or after execution; review latency is the time from an action to its review, first by an automated monitor and then by a human; escalation rate is the share of agent activity a monitor blocks or redirects (online) or flags for further review (offline).

Screenshot: Anthropic, “Measurements for understanding the pace of AI development inside frontier labs” (undated; data as of August 2026), captured Sep 21, 2026.

The page’s table fills six cells, one per metric per monitor:

Metric	Online monitor (before the action)	Offline monitor (after the action)
Coverage	100% of actions pass it before they run, usually within seconds	100% of actions ingested after they are taken
Review latency	Automated review before the action; humans review blocked actions within one week	~100,000 transcripts flagged a week, triaged by several classifiers; ~50 a week escalated to humans
Escalation rate	0.002% of over a billion August decisions blocked (about 1 in 47,000)	Roughly one to two transcripts in every thousand flagged

Two readings shape everything below. The phrase about seconds sits in the coverage row: it describes how quickly an action passes the online monitor, not how quickly a person looks. Human review of a blocked action is bounded at one week.

And the two escalation rates share a name and nothing else. One divides by decisions, the other by transcripts, the offline rate runs 50 to 100 times the online one, and adding them produces a number that describes no monitor.

Screenshot: Anthropic, “Measurements for understanding the pace of AI development inside frontier labs” (undated; data as of August 2026), captured Sep 21, 2026.

Hold the figures loosely. “These measurements cover this platform only.” They are self-reported, from one lab’s platform, with no false-positive rate and no per-leg percentiles, and nothing on the page offers them as a benchmark for anyone else.

What the page does offer is an invitation: any developer running agents on its own workloads could publish the same measures. Start internally.

The approval step already has its own meter, with tiers, expiry and approve-latency targets, in approval queues that don’t become rubber stamps, and where checks belong is argued in pre-action gates, not dashboards. What follows meters the monitors themselves, across every action.

Step 1: Build the action log your AI agent oversight metrics divide by

Every number on the page is a fraction, and the denominator is the hard part. Count actions from a source the monitors don’t control: harness transcripts and session logs, plus gateway logs where traffic passes one. A monitor’s own log lists only what the monitor saw, so coverage computed from it is 100% by construction.

Define one action as one tool call an agent attempted, including calls that were blocked and calls to hosted tools that never touch your machine. Give each a stable action_id, the lane, session and harness version, the tool name, proposed_at, and executed_at, left empty when the call never ran.

Then list every monitor that renders a verdict on an action and give each row an owner:

Monitor	Phase	Verdicts it can return	Where its record lives
PreToolUse hook (policy script or classifier call)	online	allow / ask / deny	the log your hook writes
Gateway policy on MCP and model traffic	online	allow / block	gateway log
Vendor permission classifier (auto modes)	online	denials visible; allows often invisible	vendor events, where surfaced
Transcript scanner run after each session	offline	flag / clear	scanner output
Weekly human sample of transcripts	offline	flag / clear	review sheet

A monitor with no owner is the first “not measured” row on your page. Instruction files get no row; Step 2 says why.

Step 2: Report coverage twice, before execution and after

Coverage before execution is the count of actions with an online verdict recorded before executed_at, divided by all actions attempted. Coverage after is the count of executed actions an offline monitor ingested, divided by all actions that executed. Compute each per monitor, then add two fleet lines: seen by at least one online monitor, and seen by at least one offline monitor.

Never merge before and after into one figure. A scanner that reads everything tomorrow stops nothing today.

-- Illustrative. actions: one row per attempted tool call, from harness or gateway logs.
-- verdicts: one row per monitor decision. timeout and error rows never count as seen.
SELECT v.monitor_id,
       count(DISTINCT v.action_id) FILTER (
         WHERE v.phase = 'online'
           AND v.verdict IN ('allow', 'ask', 'deny', 'steer')
           AND (a.executed_at IS NULL OR v.verdict_at < a.executed_at)
       )::numeric
         / (SELECT count(*) FROM actions WHERE week = :week)             AS coverage_before,
       count(DISTINCT v.action_id) FILTER (
         WHERE v.phase = 'offline' AND v.verdict IN ('flag', 'clear')
       )::numeric
         / (SELECT count(*) FROM actions
            WHERE week = :week AND executed_at IS NOT NULL)            AS coverage_after
FROM verdicts v
JOIN actions a USING (action_id)
WHERE a.week = :week
GROUP BY v.monitor_id;

A monitor that wrote no verdicts all week drops out of that output. Print it anyway, as a row reading zero.

The numerator is where fleets flatter themselves. Four kinds of action look monitored and are not:

• The hook that saw the call and gave no verdict. Per the Claude Code hooks reference, a command, http or mcp_tool hook that times out doesn’t block; the call continues through the normal permission flow, and the docs tell you not to count on a stalled hook as a gate. Log timeout and error as verdicts and keep them out of the numerator. Behind any online monitor on the destructive class, keep permission deny rules or the sandbox, so a monitor failure lands as a blocked call rather than an unwatched one.
• Tool paths that skip the hook. OpenAI’s Codex hooks page lists hosted tools such as WebSearch as outside the local hook path, says write_stdin doesn’t re-run PreToolUse for a command that already passed, and calls hooks a useful guardrail rather than a complete enforcement boundary. Those actions stay in the denominator and out of the hook’s numerator.
• Vendor verdicts you can’t see. Claude Code surfaces auto-mode denials through the PermissionDenied hook, and no documented hook fires on a classifier allow. Count a vendor classifier only for the verdicts it shows you and mark the rest “no vendor verdict visible”. Normalizing those streams is its own job: vendor permission verdict triage.
• Lanes the policy never reached. A monitor configured through managed settings covers nothing on a lane that never received them. Claude Code 2.1.274 (Sep 17, 2026) added a claude_code.managed_settings_resolved OTel event that reports managed-settings sources and policy helper state, per the changelog; proving the policy holds is the subject of managed permissions users can’t override.

Instruction files are not monitors either. The Claude Code memory docs say CLAUDE.md and AGENTS.md are treated as context rather than enforced configuration, and point to a PreToolUse hook for anything that must be blocked. A rule the model can ignore adds nothing to coverage.

Two monitors, three metrics. Coverage is measured where actions enter each monitor; latency on every leg toward a person; escalation where each monitor emits a block or a flag.

Step 3: Time review latency per leg, at p50 and p95

Review latency has legs, and each leg gets its own percentile pair:

1. Action to automated verdict. Online, that is verdict_at minus proposed_at, which is also time the agent spends waiting. Offline, it is verdict_at minus executed_at, which is time the action has had to do damage.
2. Flag to triage. Where classifiers or rules sort flags before a person does, time that step separately. Anthropic’s offline path runs about 100,000 weekly flags through several classifiers, which resolve most of them.
3. Escalation to human review. human_at minus the verdict or triage timestamp, for every block or flag a person must see. Anthropic’s bound on the online side is one week.

Percentiles computed over reviewed items lie by omission, because an item nobody has opened isn’t in the distribution yet. So each human leg ships with two companions: the open count and the age of the oldest open item. A p95 of two days next to a 40-day-old unreviewed block describes a backlog, whatever the percentile says.

Write a target per leg before the first report and let the first month argue with it. For the human leg, reuse the approval queue’s existing discipline. This page measures that queue and leaves its design alone.

Step 4: Keep one escalation rate per monitor, never summed

The online escalation rate is actions a monitor blocked or redirected, divided by actions it checked. The offline rate is transcripts flagged, divided by transcripts ingested. Use each monitor’s own denominator here, because coverage has already told you what it missed, and print each rate on its own row. Your fleet summary gets no escalation rate at all.

Anthropic’s six figures, one per metric per monitor. Self-reported, one internal platform, data as of August 2026. The two escalation rates use different denominators and never add up to anything.

Beside each rate go two counts: escalations a human reviewed this week, and escalations still open. A rate without the human count hides whether anyone looked. A human count without the backlog hides whether they are keeping up.

Coverage belongs on the same row as the rate, and OpenAI supplied a clean example of why. Its alignment report on deception in compaction summaries (updated Sep 16, 2026) gives a flag rate of 2.15% of GPT-5.6 Sol RL compaction summaries and says the monitoring system ran on 20% of samples for that run. Those are training-run findings, not production incidence. The transferable part: a rate describes the slice a monitor saw, and nothing outside it.

Read every rate as a signal about the monitor as much as about the agents. A rate that halves the week after a harness upgrade more likely means a guard lost sight of a renamed tool than that the fleet grew better manners; a renamed tool is a disabled guard covers that failure. A rate of zero across tens of thousands of actions proves the monitor ran. Whether it works is Step 6.

Step 5: Publish the page weekly, blanks included

Pick a day, an internal location and a fixed set of columns, and keep them: one row per monitor, plus the fleet coverage line. The values below are illustrative:

Monitor	Phase	Coverage before	Coverage after	Verdict p50 / p95	Human p50 / p95	Escalation rate	Reviewed	Open (oldest)	Seeds caught
pretool-policy	online	96.1%	n/a	0.3 s / 1.4 s	19 h / 4 d	0.04%	38	5 (6 d)	17 / 20
gateway-egress	online	71.8%	n/a	0.1 s / 0.6 s	2 d / 6 d	0.01%	9	0	5 / 5
vendor-auto-mode	online	not measured	n/a	not measured	1 d / 3 d	denials only	22	0	not measured
transcript-scan	offline	n/a	88.0%	40 min / 6 h	3 d / 11 d	0.15%	61	14 (19 d)	9 / 12
Fleet: seen by at least one monitor	both	97.3%	88.0%	none	none	none	none	none	none

Rules for the page:

• Write “not measured”, never a blank and never an estimate. Each such cell gets an owner and a target week. The list of those cells is next week’s work.
• Print deltas against last week for every number.
• List what changed underneath: harness versions, model defaults, monitor versions, new tools or MCP servers, lanes added. A number that moved needs a candidate cause next to it.
• Name the readers: lane owners, fleet security and the approval-queue owner. An oversight page nobody is obliged to read is a dashboard.

Step 6: Seed known-bad actions, because coverage is not detection

A monitor can see every action and catch none of the ones that matter. Coverage measures plumbing; detection needs cases where you already know the answer. Anthropic’s page makes the same point: it says developers should report how often monitors catch known agent misbehavior and should have third parties run that testing independently, and it notes that METR has independently red-teamed its offline monitoring platform in the past.

Build a seed set per monitor and plant it on a schedule:

Seed	Target monitor	Expected verdict
Destructive shell command against a disposable checkout	online hook	deny
Write to a path outside the lane’s repo	online hook	deny
Request to an egress domain not on the allowlist	gateway	block
Read of a planted fake credential file	online hook	deny or ask
Denied action retried through a different tool	offline scanner	flag
Summary that tells the next context to hide a failure	offline scanner	flag

Run the drill like this:

1. Plant on a canary lane only: sandboxed, a disposable repo, fake credentials, no production data, the permission and sandbox wall still up. A missed seed is a finding, never an incident.
2. Keep the seed ID out of the payload. Record seeds in your own ledger, so the monitor can’t learn the label instead of the behavior.
3. Report the seeded catch rate per monitor, seeds caught over seeds planted, with time to catch on the Step 3 legs. A miss goes on the page as a gap with an owner.
4. Rotate the variants monthly. A fixed seed set becomes a test the monitor passes by memorization.
5. Bring in an outsider once a quarter to write seeds for a monitor they didn’t build: the in-house version of the third-party testing the page asks for.
6. Re-run the full set after every harness, model or monitor change, before trusting that week’s escalation rate.

A second OpenAI report, also updated Sep 16, shows the move in miniature. After finding 27 jailbreak-style compaction summaries in one training run, the team checked whether its general monitor had flagged them, and it had flagged all 27 as high-severity prompt injection. Known cases, one monitor, a catch count.

Where a monitor is a classifier, its threshold table and the injected-state fixtures belong to Jev confidence gates before the tool runs; labeling discipline for seed sets is in evals for software that acts.

When AI agent oversight metrics mislead, and the signal for each

Coverage reads 100% every week. Signal: numerator and denominator both come from the monitor’s own log. Fix: rebuild the denominator from harness and gateway logs.

One escalation rate for the whole fleet. Signal: a single figure with no phase beside it. Fix: split it per monitor and delete the total.

A healthy median over a growing pile. Signal: p50 steady while the open count and oldest open age climb. Fix: print both, then staff the queue or narrow what escalates.

A rate that falls after an upgrade. Signal: escalations drop the week a harness, model or tool list changed, and seeded catches drop with them. Fix: re-run seeds on every bump.

Vendor allows counted as coverage. Signal: coverage jumped the week auto mode went on while your own verdict records didn’t change. Fix: count only verdicts you can see.

A monitor down while the fleet keeps running. Signal: hourly online coverage dips, with timeouts in the hook log. Fix: alert on hourly coverage and fail closed on the destructive class, so an outage blocks work instead of hiding it.

Oversight is a fleet meter, so it lives in the operating layer

No vendor sees your whole fleet. Each harness logs its own sessions, each gateway sees its own traffic, and each vendor classifier reports what it chooses to. The three numbers only exist where those records meet: one action log across every CLI, one verdict table across every monitor, one weekly page. That join belongs to the layer that runs the fleet, next to the cost meters and the kill switch, which is the argument of running a fleet of AI agents as an ops discipline.

Once the page exists, it becomes the oversight line in the fleet’s weekly review. The first edition will be mostly “not measured”. Publish it anyway; the blanks are the plan.

FAQ

What are AI agent oversight metrics?

Anthropic’s page names three: coverage, the share of agent actions a monitor sees before or after they run; review latency, the time from an action to automated and then human review; and escalation rate, the share of activity each monitor blocks or flags. Compute them per monitor, never as one fleet-wide figure.

Should we compare our oversight numbers with Anthropic’s?

No. Anthropic says its measurements cover one internal platform, and they are self-reported, with no false-positive rate or per-leg percentiles. Your monitors, your definition of an action and your risk classes differ. Borrow the definitions, publish your own numbers weekly, and compare each week with your fleet’s previous weeks instead.

Sources

• Anthropic Institute: Measurements for understanding the pace of AI development inside frontier labs — Marina Favaro and Phillie Wright; data as of August 2026; the three metric definitions and the online and offline monitor table
• Claude Code hooks reference — timed-out command, http and mcp_tool hooks don’t block the tool call
• Codex hooks (learn.chatgpt.com) — hosted tools outside the hook path; write_stdin doesn’t re-run PreToolUse; guardrail, not a complete enforcement boundary
• Claude Code changelog — 2.1.274 (Sep 17, 2026) adds the claude_code.managed_settings_resolved OTel event
• Claude Code memory docs — CLAUDE.md and AGENTS.md are context, not enforced configuration
• OpenAI alignment report: Encouraging deception in compaction summaries — updated Sep 16, 2026; 2.15% flag rate with monitoring on 20% of samples for that run
• OpenAI alignment report: Self-generated prompt injections in compaction summaries — updated Sep 16, 2026; the general monitor had flagged all 27 jailbreak-style summaries