AI Agent Monitoring: How to Know Yours Still Works

TL;DR: An AI agent almost never fails loudly. It keeps responding, the dashboard stays green, and the outcomes quietly get worse — a supplier changes their PDF layout, an edge case starts escalating everything, a scheduled run stops firing. Uptime and latency will not catch any of that. Track six outcome signals instead, and give one named person fifteen minutes a week to read them.

Why normal monitoring misses agent failure

Traditional software fails by stopping. It throws a 500, the alert fires, someone fixes it. Monitoring is built around that assumption: if the thing responds and responds quickly, it works.

Agents break the assumption. An agent that reads an order email, checks stock and files it in your ERP can be up, fast and error-free while filing the wrong quantity on every order from one supplier. Every request returns 200. Every trace looks normal. The business impact is a credit note three weeks later.

So agent monitoring is a different question from uptime monitoring:

	Traditional monitoring asks	Agent monitoring asks
Health	Did it respond?	Was the outcome correct?
Failure	Error rate, 5xx	Reversal rate, silent drift
Speed	p95 latency	Time to resolved, including the human leg
Cost	Infra spend	Cost per completed task, with retries
Absence	Process is down	A scheduled run didn't happen and nothing complained

You still want the left column. It just tells you almost nothing about whether the agent is doing its job.

The four ways agents fail silently

These are the failures we actually see in production, in rough order of frequency.

1. Upstream drift. A supplier switches invoicing software. The layout changes, extraction confidence drops, and the agent starts guessing at the line-item table. Nothing errors — the model is happy to produce a plausible number. This is the single most common cause of an agent that "used to be great."

2. Escalation creep. The agent meets a case it's not confident about and does the right thing: it escalates. Then the case becomes common. Six weeks later a human is handling 60% of the volume, the agent looks perfectly healthy, and you have quietly rehired the process. This is the failure mode we wrote about in 94% accurate, 40% automated — accuracy is fine, automation collapsed.

3. Silence. A scheduled agent stops firing — a credential expires, a trigger is disabled during an unrelated change, a queue backs up. Absence produces no signal at all. Nobody gets paged because nothing happened is not an event unless you make it one.

4. Orphaned runs. The client disconnects — someone closes the tab, a network blips — and the run keeps going on the server. This one surprises people: closing the window is not a stop. It matters most for agents with write access and a spend budget, and the control you need is an explicit stop, not a closed browser tab.

The six signals worth tracking

Vendor dashboards will offer you thirty metrics. These six are the ones a business owner can act on.

1. Zero-touch rate

The share of items the agent completed end to end with no human edit. This is the number that maps to money, and it's the one to put on the wall. Falling zero-touch rate is the earliest reliable sign of drift, usually visible weeks before anyone complains.

2. Escalation rate — with reasons

Not just how often the agent hands over, but why. Group escalations by reason and the top group is your next automation increment. If "unknown supplier code" is 40% of escalations, that's a data-mapping fix, not an AI problem. An exception queue without reason codes is a to-do list; with them it's a roadmap.

3. Reversal rate

How often a human undoes what the agent did. This is the closest thing to a true accuracy measure, and it's free — you don't need an eval harness, you need to notice edits and cancellations. A rising reversal rate with a flat zero-touch rate means the agent got more confident and less right, which is the worst combination and the hardest to spot from usage stats.

4. Cost per completed task

Total spend divided by tasks that actually finished — not by tasks attempted. Retries, failed runs and escalated items all consumed tokens and produced nothing. This is the denominator most vendor calculators quietly get wrong; we broke down the honest version in AI automation ROI.

5. Time to resolution, including the human leg

Measure from the moment the work arrives to the moment it's done, including anything sitting in the escalation queue. An agent that answers in four seconds and parks 30% of the volume in a queue nobody drains is slower than the manual process it replaced.

6. Expected-run coverage

For anything scheduled: did the runs that should have happened, happen? This is the only one of the six that requires you to define the expectation up front — "invoices are processed every weekday at 07:00" — and it's the one that catches the silent-stop failure nothing else sees.

What good instrumentation looks like

You don't need an observability platform to get this. You need three things to exist and be readable by a non-engineer.

A run record per task. One row per run: what triggered it, what it read, which tools it called with which arguments, what it changed, what it cost, how it ended. If you build agents yourself, this is what OpenTelemetry's GenAI semantic conventions standardise, and what tools like Langfuse and Arize consume. If you buy a platform, it should be there already — and the buying question is not "do you have traces" but "can my operations manager read one without calling engineering."

An exception queue with context attached. Every escalation should arrive with the partial work, the reason, and a link back to the run. An escalation that just says "needs review" costs a human more time than doing the task from scratch. This is the practical core of human-in-the-loop automation: the handoff is a feature, not an error branch.

An immutable audit log. Who or what did the action, when, under whose authority, and what the approval chain was. This is one of the five guardrails and it is also, in practice, your debugging tool — most "why did it do that" questions are answered by the log, not by the model.

Add one control that isn't a metric: a stop button a non-engineer can press. Scoped write access means little if the only way to halt a misbehaving run is to file a ticket.

The weekly review

Monitoring that nobody reads is theatre. The review that works is short and owned:

1. Zero-touch and escalation rate, week over week. Any move over a few points gets explained.
2. Top three escalation reasons. Pick one to fix.
3. Reversals. Read two of them in full. Not a sample — the actual runs.
4. Cost per completed task. Compare to the manual baseline you set at pilot time. You did set one.
5. Missed runs. Anything scheduled that didn't fire.

Fifteen minutes, weekly for the first quarter, monthly after that. The owner is a named person in the business function that owns the process — the same ownership rule that decides whether a pilot ever reaches production in the first place. Agents without a named owner don't fail dramatically; they drift until people stop trusting them and route around them.

One extra note for agents that act inside a browser session: those carry the highest privilege of anything an agent does, and their monitoring bar is correspondingly higher — every action logged, every session scoped. We covered the controls in AI browser agents: four controls that actually work.

The short version

An agent is not a service that's up or down. It's a colleague whose work you spot-check. Track outcomes, not heartbeats: zero-touch rate, escalation rate with reasons, reversals, cost per completed task, time to resolution, and runs that should have happened. Read them weekly. Fix the top escalation reason each time.

That's how agentic systems stay useful past month three, and it's the part of the work OIDO runs alongside your team rather than handing over as a dashboard. If you'd rather talk about your process than watch a demo, get in touch.