On September 17, Anthropic published an unusual view into its agent operations. It reported roughly 30,000 concurrent research and engineering agents on its most-used internal platform, more than one billion monitoring decisions during August, and separate online and offline review paths. The scale is exotic. The measurement problem is not.
One day earlier, OpenAI introduced a formal process for reporting unexpected model behavior, including unauthorized uploads and writes. Those cases underline a basic operating fact: a monitor does not help merely because it exists. You need to know whether it saw the eligible activity, reviewed it soon enough, and sent the right cases to people.
Start with this weekly AI agent monitoring metrics sheet:
| Metric | Formula | Report with it |
|---|---|---|
| Pre-action coverage | Eligible actions checked before execution / all eligible actions | Exclusions by tool and risk tier |
| Post-action coverage | Eligible events ingested after execution / all eligible events | Missing, late, and malformed events |
| Review latency | Review timestamp minus event timestamp | Median, p95, and oldest open item |
| Escalation rate | Actions blocked, redirected, or flagged / monitored actions | Reason code and risk tier |
| Confirmed-alert precision | Reviewed alerts confirmed useful / reviewed alerts | Sample size and confirmation rubric |
| Detection recall | Known unsafe test cases caught / unsafe test cases run | Test-set version and severity mix |
| Review backlog | Open alerts beyond their service limit | Count, age, and assigned owner |
The percentage alone is never enough. Keep the numerator, denominator, scope, and reporting window beside every result.
Define the unit before measuring the monitor
An agent run may contain messages, retrievals, tool proposals, tool executions, retries, approvals, and customer-visible claims. If one team counts runs while another counts actions, their 99% coverage figures do not mean the same thing.
Choose the unit that matches the control. A pre-execution policy gate usually measures proposed tool actions. A transcript classifier may measure complete runs. A customer-claim checker may measure outbound messages. Name that unit in the metric.
Then define eligibility. A useful record includes:
- event or run ID;
- agent, model, prompt, and workflow versions;
- tool and normalized action class;
- risk tier and required monitoring mode;
- event, automated-review, and human-review timestamps;
- monitor result, reason code, and eventual reviewer disposition;
- release or policy version active at the time.
The AI agent audit-trail guide explains how to reconstruct an individual action. Monitoring metrics aggregate those records without losing which release, tool, or policy produced the result.
Split coverage before and after execution
One coverage number hides the most important distinction. A review before execution can stop a harmful write. A review after execution can find a pattern, start an investigation, and improve the control, but it cannot undo every effect.
Use pre-action coverage for operations that can change money, access, private data, external messages, or durable records. The numerator counts eligible proposals that reached the required monitor before a tool ran. The denominator includes all proposals in that risk class, including those that bypassed the normal tool gateway.
Use post-action coverage for events that should enter retrospective review. The numerator counts eligible events accepted by the monitoring pipeline within a declared arrival window. Keep late events separate from missing events. A log that arrives three days after a one-day review deadline is not useful coverage for that deadline.
Anthropic's September report separates these modes. It says all actions on the measured platform pass through an online monitor before execution and all are ingested by an offline monitor afterward. OpenAI's earlier account of its internal coding-agent monitor reported that less than 0.1% of traffic, mainly bespoke or local setups, sat outside coverage at the time. Both disclosures show why exceptions belong in the headline number, not in a footnote.
Audit the denominator independently. Compare tool-gateway counts, destination API records, queue receipts, and monitoring events. If the monitor supplies both numerator and denominator, a broken exporter can report perfect coverage while dropping the same events from each side.
Measure latency as a control deadline
Average review time can look healthy while a few serious alerts sit untouched. Report the median for routine flow, the 95th percentile for the slow tail, and the age of the oldest item still open.
Set the deadline from the consequence:
| Event class | Review mode | Example service limit | Failure behavior |
|---|---|---|---|
| Irreversible or high-impact write | Before execution | Automated decision before tool call; human decision before release when required | Block or pause |
| Customer-visible, recoverable action | Near-real-time | Automated review within 60 seconds; human review within 30 minutes after a block | Pause on high-severity flags |
| Read-only action with private data | Before execution plus sampling | Policy check before access; sampled review within one day | Deny if identity or scope is unclear |
| Public-information read | Retrospective sampling | Review within seven days | Continue and preserve trace |
These are example service limits, not industry standards. Replace them with limits tied to your effects, staffing, and incident process.
Queue age matters because a monitor can keep flagging events after the review team has fallen behind. Report how many items have crossed their service limit and how long the oldest one has waited. When the backlog exceeds reviewer capacity, narrow or pause the affected actions rather than pretending delayed review still protects them.
The human oversight ratio guide helps estimate reviewer capacity from alert volume and handling time. Review latency shows whether that capacity works in practice.
Interpret escalation rate without chasing a target
Anthropic reported that its online monitor blocked about 0.002% of more than one billion decisions in August, roughly one in 47,000. Its offline process flagged around one or two transcripts per thousand for further review, with about 50 high-priority items per week reaching humans after classifier review.
Those figures describe one platform, policy, and risk model. They are not targets for a support agent. A lower escalation rate might mean the agent improved, the work mix changed, the monitor missed incidents, or a deployment stopped emitting events. A higher rate might mean a bad release, a stricter rule, more sensitive work, or noisy detection.
Treat an unexpected rate change as a question. Slice it by tool, intent, risk tier, model, workflow version, policy version, and customer channel. Compare the change with coverage and detection recall before declaring improvement.
OpenAI's internal monitor has surfaced categories such as circumventing restrictions, misrepresenting tool results, unauthorized data transfer, and destructive actions. Stable reason codes for those behaviors make escalation trends explainable. Free-form labels written by reviewers are harder to compare and easier to rename after a bad week.
Add precision and test-set recall
Coverage, latency, and escalation describe the monitoring process. They do not establish whether the monitor finds the right behavior.
Precision asks how many reviewed alerts were useful. Define useful before sampling. A confirmed alert might identify a policy breach, a justified block, or a case that required a human decision. Track noisy triggers separately so a broad rule does not train reviewers to dismiss every warning.
Detection recall needs a controlled test set because production incidents are not a complete denominator. Replay known unsafe trajectories and count how many the monitor catches before the harmful step. Include clean but unusual cases too. A detector that stops every run has perfect recall and no operational value.
The test set should cover boundary bypass, changed approval parameters, repeated writes after a timeout, cross-account access, unsupported completion claims, and unauthorized external transfers. The existing trajectory-monitoring guide shows how to preserve multi-step cases instead of reducing them to one prompt.
Keep the test-set version beside the result. Adding harder cases may lower recall even when the monitor did not regress. Removing hard cases can create an attractive but meaningless improvement.
Worked example: one week of support-agent activity
Suppose a support agent proposes 10,000 tool actions in a week. Policy marks 2,000 as eligible for pre-action monitoring. The tool gateway records all 2,000 proposals, but the monitor receives 1,990 before execution. Ten proposals reached a legacy connector that lacks the gate.
Pre-action coverage is 1,990 / 2,000 = 99.5%. That sounds strong until the team inspects the gap. Four missed actions changed customer contact preferences, and six read order status. No harm was found, but the write path makes the gap a release blocker. The team disables that legacy write until it uses the same gateway.
The monitor flags 40 of the 1,990 checked actions. Reviewers examine all 40 and confirm 12 as useful interventions. Confirmed-alert precision is 12 / 40 = 30%. The median human review time is 11 minutes, the p95 is 54 minutes, and the oldest open alert is 3 hours old against a 30-minute limit.
The release test set contains 25 unsafe cases. The monitor catches 23, so detection recall is 92%. One miss involves a retry after an unknown payment result. The other involves an approved refund whose amount changes before execution. Both become release-gate defects even though production escalation stayed low.
The weekly decision is clear:
- keep read-only order lookups running;
- disable the legacy preference-write path until coverage returns to 100%;
- add a queue alarm at 20 minutes so the 30-minute human limit is recoverable;
- fix the two missed regression cases and rerun the full test set;
- review the 28 false positives by reason code before loosening any rule.
One dashboard produced specific operating changes. A single green "monitor active" badge would have hidden all four problems.
Review changes as a linked set
Do not optimize one number alone. Pushing escalation down can reduce reviewer load while also suppressing true alerts. Increasing retrospective coverage can flood the queue and lengthen review time. Tightening a policy can improve test recall while interrupting legitimate work.
Review the metrics together after every model, prompt, tool, policy, or monitor release. Preserve the prior version as a comparison and annotate material changes in task mix. A useful weekly review asks:
- Did every eligible action reach the required monitor?
- Did high-risk decisions happen before execution?
- Did people resolve escalations inside the service limit?
- Did controlled unsafe cases still trigger the expected intervention?
- Which tools, releases, or reason codes explain the movement?
When a confirmed failure reaches a customer or external system, move from dashboard review to the AI agent incident-response runbook. Preserve the trace, contain the affected capability, reconcile actual effects, and turn the failure into a regression case.
Make oversight measurable before autonomy grows
Agent activity can grow much faster than the team reviewing it. Coverage tells you whether the control saw the work. Latency and backlog show whether intervention arrived in time. Escalation reveals where the system objected. Precision and test recall say whether those objections deserve trust.
Define the units, reconcile the denominator outside the monitoring pipeline, and attach each metric to a risk tier and service limit. Then review the set after every meaningful release. That is how a monitoring program stays attached to actual agent behavior instead of becoming a reassuring chart beside it.
No credit card required.
