The setup
The pilot ran with a team operating 10 AI agents in production, handling customer-facing conversations where a wrong answer has a real cost: a promise the company can’t keep, an action outside policy, a decision nobody reviewed. Before the pilot, the team’s signal for “is an agent working” was the same signal most teams have: uptime, error rate, and whichever mistakes happened to turn into a support ticket.
Zespan traced every agent run and evaluated the content of each response against the team’s own rules, not a generic quality score. The question wasn’t whether a request completed. It was whether the agent got it right.
What the numbers mean
104 raw failures
Every agent run was checked, including the ones that returned 200 and looked healthy on every infrastructure metric. Across the pilot window, 104 individual responses failed that check: a wrong answer, a decision outside policy, or an action the agent wasn’t authorized to take, each one otherwise indistinguishable from a normal, successful request.
10 real issues
104 individual failures did not mean 104 separate problems. Grouped by root cause, they collapsed into 10 distinct issues, each with an AI-written explanation of what actually went wrong. A single missing constraint or misread field typically accounted for a cluster of failures, not one.
2 permanent tests
Two of the ten issues were turned into enforced guardrails during the pilot window, each backtested against the team’s own past traffic before it went live. Both fixes became permanent regression tests, built from the real failures that caused them, so the same mistake is caught automatically if a future prompt or model change reintroduces it.
What one issue looked like
The pattern below is illustrative of the kind of issue the pilot surfaced — the shape of a real finding, not a verbatim transcript from the pilot itself.
The failure
A support agent had no explicit statement of the company’s return-window policy in its prompt. Asked about a return outside that window, it approved a refund anyway — a response that was fluent, confident, and wrong. Nothing about the request errored.
Why it repeated
The gap wasn’t specific to one phrasing. Every customer who asked about a late return in a slightly different way hit the same missing constraint, which is why one root cause accounted for a cluster of the 104 raw failures rather than a single instance.
The fix
The constraint became an enforced guardrail rather than a second prompt edit: tested against the team’s own historical conversations to confirm it caught the real violations without blocking legitimate refund requests, then enforced in-process on every future request.
What this pilot is, and isn’t
This is one pilot, with one team, over one window of production traffic. The 104, 10, and 2 are the real, measured results of that pilot — not a projection, a benchmark, or an average across customers. We’re not naming the company or quoting anyone, because that wasn’t part of the arrangement, and we’d rather publish accurate anonymized numbers than a named story we can’t fully back.
What it demonstrates: checking the content of every agent response, not just whether the request completed, finds real problems that standard monitoring misses — and grouping them by root cause turns a large number of individual failures into a short, fixable list. See how to know when an AI agent is wrong in production for the detection side of this, and how to stop an AI agent from making the same mistake twice for how a caught issue becomes a permanent fix.