At a glance
- A weekly operating review turns AI agent monitoring into a routine: nine signals, each with a named owner, a cadence, and the threshold that turns a number into a decision.
- Override rate and escalation rate measure different things: escalation rate is how much reaches a person, override rate is how much of what reaches a person gets changed.
- Cost per item and error classes catch problems a single "is it still running" check misses.
- Drift checks compare today's inputs and outputs against the mix measured at launch, using a method a small team can run without a data scientist.
- A one-page dashboard puts all nine signals in one place, so the weekly review can be timeboxed to a few minutes instead of spent hunting for data.
What changes when an agent goes live
A pilot is judged against a test set someone chose. Production is judged against whatever shows up: real customers, edge-case documents, and traffic nobody scripted. NIST's AI RMF Playbook suggests monitoring how metrics observed in production differ from the same metrics collected during pre-deployment testing [3]. That comparison is the whole point of watching an agent after go-live.
If your team doesn't have a data scientist watching a drift dashboard, monitoring still falls to whoever already runs the agent day to day, such as an operations or IT owner who has other work too. And if the team that scoped and built the agent has moved on to the next project, someone still has to notice when it gets slower, costs more, or starts making a new kind of mistake.
- Unless someone is named, no one owns "is it still working?" once the people who built it move on.
- A threshold that seemed obvious in testing needs real production data before it means anything.
- A single "still running" check hides cost creep, quiet drift, and a growing backlog.
A weekly operating review fixes this without adding headcount: a short, recurring look at a fixed set of signals, each with a named owner and a rule for when a number becomes a decision. The rest of this article is that review and dashboard.
The weekly operating review
Nine signals cover what an agent costs, whether it's doing its job, and how much work it creates for people. Each row names what it measures, who owns it, how often to check it, and its threshold for action.
| Signal | What it measures | Owner | Cadence | Threshold that triggers action |
|---|---|---|---|---|
| Override rate | Share of escalated items a person reverses or edits before they take effect. | Process owner | Weekly | Moves away from the baseline set in the first weeks live. |
| Escalation rate | Share of items routed to a person instead of completed on its own. | Reviewer or team lead | Weekly | Rises without a matching change in volume or rules. |
| Cost per item | Model, tool-call, and infrastructure cost divided by items processed. | Budget owner or IT | Weekly | Moves outside the agreed budget band. |
| Error classes | Failures by type: wrong answer, tool-call failure, timeout, refusal, malformed output. | Technical owner | Weekly | A new type appears, or one type's share grows. |
| Drift checks | Current inputs and outputs compared against the mix measured at launch. | Technical owner | Every 2–4 weeks | Comparison flags a meaningful shift from baseline. |
| Latency | Response time at the slow end of the distribution (p95), not the average. | IT or engineering | Weekly | Exceeds the response-time target for the workflow. |
| Queue age | Time an escalated item waits before a person opens it. | Reviewer manager | Weekly | Oldest waiting items exceed the service target. |
| User-reported issues | Count and theme of complaints or corrections from people using the output. | Process owner | Weekly | A rising count, or a new complaint theme. |
| Uptime / completion rate | Share of requests that finish without a system error (wrong answers are tracked under error classes). | IT or engineering | Weekly | Falls below the agreed availability target. |
Treat the threshold column as a first draft: the right number comes from your own production data — the next section covers how to set it.
Signals and thresholds
None of these nine signals needs a monitoring platform or a data-science team. Override and escalation rate come from whatever system logs when a person changes or receives the agent's output; cost per item comes from the usage and billing data your model provider tracks.
Both OpenAI and Anthropic expose that usage and cost data directly. OpenAI points teams to a usage tracking dashboard and a cost notification threshold [1]. Anthropic reports usage in fixed time buckets down to the minute, and cost at daily granularity [2]. Either one turns cost into a weekly-review number instead of an end-of-month surprise.
Drift, latency, errors
Drift checks are the one signal that sounds like it needs a data scientist, but the method is closer to a periodic audit than a modeling project. NIST's AI RMF Playbook suggests monitoring how production metrics differ from pre-deployment testing [3]; running that comparison on a fixed cadence, rather than only after something looks wrong, is what turns it into a routine.
That comparison uses hypothesis testing or human domain expertise to catch a meaningful shift in the input or output mix [3] — a comparison method, not a retraining pipeline. Writing a handful of evals against a fixed set of cases, the same habit OpenAI recommends for testing a model upgrade [4], is one practical way to run that comparison on a schedule.
Latency and errors (and so uptime/completion) borrow from an older monitoring tradition. Google's site-reliability guidance names "the four golden signals of monitoring" as "latency, traffic, errors, and saturation" [5]. It defines latency as the time to service a request, distinguishing successful requests from failed ones [5], and errors as the rate of requests that fail outright or complete with the wrong content [5]. An agent that answers slowly, or "succeeds" with a malformed tool call, fails the same test.
- A signal with no owner doesn't get watched, however good the dashboard looks.
- A signal with no cadence gets checked only after something has already gone wrong.
- A signal with no threshold produces a chart, not a decision.
Override rate and escalation rate measure two stages of one flow: escalation rate is the share of all items routed to a person; override rate is the share of those escalated items later changed. A workflow can have a low escalation rate and a high override rate at once, if the agent rarely asks for help but is often wrong when it does.
Who looks and who acts
NIST's AI RMF Playbook suggests answering an ownership question directly for any deployed system: who will be responsible for maintaining, re-verifying, monitoring, and updating this AI once deployed [6]. For a small team, the honest answer is rarely "the team" — it's a named owner for each row in the table above, with one person free to hold several rows, plus someone accountable for the review meeting itself.
- Refresh the dashboard first
Its owner updates it the morning of the review, so the meeting starts with current numbers.
- Each owner reports their row
The named owner for each signal states whether it's inside or outside its threshold — timebox each to a couple of minutes once the dashboard is ready.
- Flag what's outside threshold
Anything outside threshold gets a named next step and owner, decided in the meeting.
- Log the decision, even a 'wait'
Record what was flagged, what was decided, and who owns the follow-up — including a decision to wait.
- Escalate what the routine can't close
A signal still outside threshold after the agreed follow-up goes to whoever owns the agent's go/no-go decision.
Which decisions must keep a person in the loop is a separate, upstream question; see human-in-the-loop AI governance for how to decide that first. If escalation rate holds steady but queue age keeps climbing, the queue is understaffed, not the agent misconfigured; how to measure human review workload turns that into a staffing number.
The review needs a plan for when something breaks between meetings. NIST's AI RMF Playbook suggests establishing and regularly reviewing response plans for incidents or negative impacts [6]. Keep that plan short: site-reliability guidance is blunt about the alternative, noting that paging a person is "a quite expensive use of an employee's time" [5] — alerts should be rare and trustworthy.
The one-page dashboard
Timebox the review to a few minutes by keeping the numbers in one place: a one-page dashboard with all nine signals, organized by purpose, refreshed before anyone opens it.
| Panel | What it shows | Signals it covers | Refresh cadence |
|---|---|---|---|
| Header strip | Agent name, launch date, and time since the last incident. | — | Every load |
| Volume & cost | Items processed and cost per item, against the agreed budget band. | Cost per item | Daily or weekly |
| Human load | Override and escalation rate over time, each against its own baseline. | Override rate, escalation rate | Weekly |
| Quality | Error classes by type, plus the count and theme of user-reported issues. | Error classes, user-reported issues | Weekly |
| Speed & availability | Latency at the slow end of the distribution, queue age, and completion rate. | Latency, queue age, uptime | Weekly |
| Drift status | Date of the last drift check and its result: on baseline, or flagged. | Drift checks | Every 2–4 weeks |
Keep it to one page: designed so anyone in the review can see at a glance which signals are inside threshold and which aren't, without checking several separate tools.
When this operating review doesn't apply
This review assumes the agent makes probabilistic calls that can drift, and a wrong output matters enough to justify the routine. A fully deterministic automation needs no drift checks or override rate. See when not to use an AI agent for how to tell the two apart first.
A pilot processing a handful of items a week probably doesn't need a dedicated meeting yet; fold the same signals into an existing meeting until volume justifies a separate one. Setting up the logging, dashboard, and cadence is handover work covered on AI operations and enablement.
Frequently asked questions
How do you monitor an AI agent in production?
Run a short weekly operating review of a fixed set of signals — override rate, escalation rate, cost per item, error classes, drift checks, latency, and queue age — each with a named owner and a threshold that triggers action. Put them on one dashboard and timebox the review to a few minutes.
What metrics should you track for an AI agent?
Track nine signals: override rate, escalation rate, cost per item, error classes, drift checks, latency, queue age, user-reported issues, and uptime or completion rate. Each needs a definition, an owner, a cadence, and the threshold that turns a routine check into an action, not just a number on a chart.
How often should someone review agent performance?
Weekly, for override rate, escalation rate, cost per item, error classes, latency, and queue age. Drift checks run on a separate, longer cycle, since that gives each comparison enough new items to be meaningful — but a known upstream change, like a new model version, should trigger an immediate check. Anything outside threshold gets a decision in that meeting.
What is a good override rate?
There's no universal "good" override rate — the share of escalated items a person changes — because it depends on the workflow, the confidence threshold, and how much judgment the task needs. Measure it for the first few weeks in production, treat that as the baseline, and act when it moves away from it.
How do you detect drift without an ML team?
Compare recent inputs and outputs against the mix you saw at launch on a fixed schedule, watching whether the item mix, the share of low-confidence outputs, or the rate of one rule failing shifts over time. This is a comparison method, not a modeling exercise, and a spreadsheet can be enough for a small volume.
Who should own agent monitoring?
A named owner for each row in the weekly operating review — a process owner, technical owner, reviewer manager, and so on — not "the team" as a whole. One person can hold several rows on a small team, but someone is also accountable for the review meeting itself. Name owners before launch, not after an incident.
Related reading
- The AI agent implementation service page covers how an agent like this gets scoped and built.
- The AI operations and enablement service page covers the handover this review runs on.
- On which decisions must keep a person accountable, see human-in-the-loop AI governance.
- If escalation rate points to a staffing problem, see how to measure human review workload.
- On whether an agent is the right tool at all, see when not to use an AI agent.
Sources
- OpenAI, "Production best practices" (accessed 2026-09-30)
- Anthropic, "Usage and Cost API" (accessed 2026-09-30)
- NIST, "AI RMF Playbook: Measure" (accessed 2026-09-30)
- OpenAI, "Evals" (accessed 2026-09-30)
- Google, "Monitoring Distributed Systems" (Site Reliability Engineering) (accessed 2026-09-30)
- NIST, "AI RMF Playbook: Manage" (accessed 2026-09-30)
More in Agent governance
Build vs. Buy AI E-Commerce Back Office Automation: Point Tools vs. an AI Implementation Partner
Build vs buy AI e-commerce back office automation: a six-factor decision table comparing packaged tools with an AI-agent layer, plus how to scope one workflow.
Ecommerce OperationsBuild vs. Buy AI for the Energy and Utilities Back Office: AI Agents vs. Entrenched Land, JIB and Billing Software
Build vs buy AI for the energy and utilities back office: a five-factor decision table comparing land, JIB and billing software with an AI-agent layer.
Utilities and Energy CompaniesAI Agent Approval Gates for Finance: A Role and Action Matrix
AI agent approval gates for finance: which actions an agent may do, suggest, or never touch, who approves each one, and what evidence to keep.