The agent that failed quietly for two days

Ordinary monitoring checks that a service is up. An AI agent can be up, fast and returning a clean response while giving wrong answers. We keep meeting teams that learned about a quality problem from a customer email, not from a dashboard.

“The dashboard is green. Why are people complaining?”

Uptime, latency and error rate are the usual signals. They say nothing about whether an answer was correct, whether the right tool was called, or whether the agent quietly gave up and returned a polite non-answer. The failure is silent, so the first alert is a person.

“What did the agent actually do?”

We start with traces. For each request we record the input, the retrieved context, every tool call with its arguments and result, the model version, the prompt version, the output, token counts and latency. Without this, a bad answer cannot be reproduced. With it, most incidents are diagnosed in minutes instead of days.

“Which signals tell us quality dropped?”

We choose a few signals that match the workflow and score a sample of live traces. Typical ones are groundedness against the retrieved text, tool-call success, the rate of refusals and fallbacks, corrections made by users, and sentiment across a conversation. Scoring every trace is expensive and rarely needed. A sample, split by use case, shows a trend early enough to act on.

“When does a person get paged?”

Alerts go on trends against a rolling baseline, not on single bad answers. A drop in groundedness for one document type goes to the owner of that pipeline. A rise in handoffs to humans is a signal as well, because it often means operators are losing trust before the numbers show it. Every confirmed failure becomes a test case, so the same fault does not come back unnoticed.

“Can the operators see this too?”

We give workflow owners a plain view: volume, handoff rate, flagged answers and the reasons behind them. Operators decide when autonomy widens, so they need the same evidence the engineers have.