Why your agents pass every test and still break in production
You get clean benchmark scores. Your pre-deployment eval suite is green. The demo goes well. Then the agent ships, and three weeks later a user files a complaint about advice that was confidently wrong. No error was raised, no alert fired, nothing in your logs flagged a problem. The agent just answered incorrectly, politely, at scale.
This is the evaluation gap: the distance between what a controlled test measures and what actually happens when an agent encounters real users, real documents, and real edge cases in sequence. Closing that gap requires understanding why it opens in the first place, and then instrumenting production to catch what pre-deployment checks miss.
The gap is measurable and it is large
Fiddler AI's July 2026 analysis found that 88% of enterprise AI agents that work in controlled demos fail when deployed to real workflows. That figure covers a wide range of failure modes, from incorrect outputs to tool misuse to cascading errors in multi-step chains, so the number is an upper bound on the problem rather than a precise rate for any one failure type. Still, the direction is clear.
The compounding problem is particularly easy to underestimate. In a three-agent chain where each individual agent succeeds 70% of the time, the end-to-end chain succeeds only 34% of the time. Each step multiplies the failure probability of the previous one. Your per-agent evals look fine; your production outcomes do not. This is why step-level accuracy matters as much as end-to-end pass rates when you instrument a multi-agent workflow.
What benchmarks do not capture
Pre-deployment evaluations are good at measuring a model's response to a curated input. They are poor at measuring three things that matter in production: distributional shift, interaction effects between agents, and the quality of outputs that contain no detectable error signal.
Distributional shift means the inputs your agent receives in production are not the inputs you tested against. A customer support agent evaluated on a clean dataset of example tickets will encounter tickets with missing context, ambiguous requests, and references to products or policies that changed after training. RAG-based agents in financial services show hallucination rates around 21.9% in real deployments, across 2,265 measured responses, even when the same underlying models score well on static benchmarks. The retrieval step introduces variance that no static eval captures.
Interaction effects matter in multi-agent orchestrator setups where one agent's output becomes another's input. An error in step two propagates to step three with no human in the loop to notice. The receiving agent has no way to know the context it was handed is wrong.
The silent failure problem is the most insidious. An agent that crashes is easy to detect. An agent that returns a plausible but incorrect answer is not. The Air Canada chatbot case illustrates this precisely: the chatbot gave a customer incorrect information about bereavement fares, contradicting Air Canada's own website. No system error occurred. The tribunal awarded the customer $812.02 in damages in February 2024, establishing that companies bear liability for what their agents say, whether or not an exception was thrown.
Quality decay is not a launch-day problem
Klarna launched its customer service agent in February 2024, handling 2.3 million conversations in the first month with a 67% automation rate and issue resolution time dropping from 11 minutes to under 2 minutes. By Q3 2025 the system was handling the equivalent workload of 853 human agents. Those are real, large gains.
By May 2025, Klarna was rehiring human agents. The quality degradation surfaced on complex cases and edge cases over time, not at launch. The problem was not that the agent was bad on day one; it was that the monitoring infrastructure did not catch the point at which quality drifted below acceptable levels on a growing proportion of cases.
This is quality decay: a gradual shift in output quality that is invisible without continuous measurement. It is distinct from a model regression or a deployment bug. The model does not change; the distribution of inputs does, and the gap between what the agent can handle well and what it is being asked to handle widens. Detecting this kind of production drift requires scoring outputs against a quality rubric continuously, not just at deployment.
What production-grade evaluation infrastructure requires
Catching silent quality decay before users do requires several things that static eval suites do not provide.
First, you need span-level instrumentation across every agent step. If you can only observe the final output, you cannot tell which step in a five-step chain produced the error. OpenTelemetry-compatible tracing lets you record what each agent received, what it called, what it returned, and how long each step took. This is the foundation for everything else.
Second, you need scoring that runs in production, not just in CI. Scoring means applying a quality rubric to sampled live outputs, flagging responses that score below a threshold, and tracking score distributions over time so you can see drift before it becomes a user complaint. This is different from observability, which watches what agents do without evaluating whether what they do is correct.
Third, you need behavior validation against an expected activity schema. Tool misuse accounts for approximately 31% of production failures in agentic deployments, and most of those failures are not obvious from the output alone. An agent that calls the wrong tool with a valid-looking response will pass an output-only quality check. Validating the action sequence, not just the answer, catches this class of failure.
Fourth, you need an audit trail that is queryable after the fact. When a user reports a problem, you need to reconstruct exactly what the agent did and why, without relying on logs that were never intended for that purpose. This is also the foundation of regulatory compliance for agents in regulated industries.
Prefactor instruments agents via SDK, records spans for each step, scores outputs against quality and risk rubrics on live traffic, validates behavior against activity schemas, and keeps a queryable audit trail. If you are building the infrastructure yourself, those four capabilities are the ones to prioritize in that order.
Measuring what agents actually do versus what you think they do requires all four layers working together. Span recording without scoring tells you what happened. Scoring without behavior validation misses tool-level failures. Behavior validation without an audit trail leaves you unable to explain a failure after the fact.
Where to start
Pick one agent in production today, instrument it with span-level tracing, and add output scoring against a rubric you write in plain language. Run it for two weeks and look at the score distribution, not just the average. That will tell you more about your actual quality posture than any benchmark.
Start evaluating your agents or read the docs to see how Prefactor's instrumentation and scoring fit into your existing stack.