What this article covers
You will leave with a clear account of why agent pilots stall before production, which categories of measurement close that gap, and how to sequence evaluation before you commit to scale. The failure rate is not an abstract industry problem: CIO reporting puts it at 88, 95% of enterprise AI agent pilots, and the failures cluster on governance and observability gaps, not on the underlying models.
The gap between deployment and production
Nearly every engineering team that has shipped an agent has also shipped something they could not fully explain afterward. The agent ran. It produced output. Whether it did the right thing, in the right sequence, at the right cost, was harder to answer.
That ambiguity is tolerable during a two-week proof of concept. It becomes a blocker when a risk committee asks whether the agent can be trusted across thousands of daily transactions, or when a customer-facing failure needs a root cause in under an hour.
Gartner projects that 40% of enterprise agentic AI projects will cancel by end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. Those three cancellation reasons are all measurement failures. You cannot defend a cost you have not tracked. You cannot demonstrate business value you have not defined. You cannot enforce a risk control you have not validated.
The teams that reach production are not running better models. They are running better instrumentation around the same models.
Why pilots fail where they do
Agent pilots fail in a predictable sequence. The first sign is usually a confidence problem: the team cannot agree on whether the agent is performing well because they have no shared definition of "well." The second sign is a trust problem: stakeholders outside engineering cannot inspect what the agent did, so they apply precautionary limits that make the agent too constrained to be useful. The third sign is a cost problem: token usage and latency were never measured in the pilot, so the production cost estimate surprises everyone in the wrong direction.
None of these failures originate in the language model. They originate in the absence of structure around the agent's behavior.
The statistics support this sequence. 97% of companies deployed AI agents in the past year, but only 11, 12% are using them in production at genuine scale. That gap, from deployment to scale, is where evaluation lives. Deployment is easy; it only requires the agent to run. Scale requires the agent to run correctly, verifiably, and within cost and risk tolerances that you can state in advance and measure in operation.
Understanding what agents actually do versus what you think they do is the first problem to solve, and it is a measurement problem before it is a model problem.
What measurement actually looks like
Measurement for agents covers four distinct categories. Teams that reach production typically have at least partial coverage across all four before they scale. Teams that stall have partial coverage of one.
Behavior against a schema. Before you scale, you need a definition of what the agent is supposed to do, expressed precisely enough to validate against. This is not a product requirements document. It is a structured specification of the agent's expected action sequences, the conditions under which each action is permitted, and the outcomes that count as success. Without this, every evaluation is subjective. With it, you can run the agent against the specification on every deployment and get a binary result per check. Validating agent behavior against expected outcomes is the discipline that makes this repeatable.
Step-level accuracy, not just final output. Agents fail in the middle, not just at the end. A research agent that retrieves the right document but summarizes it incorrectly has a step-level failure that final-output evaluation will miss entirely. Step-level accuracy and trajectory evaluation give you the resolution to find where in a multi-step sequence the failure occurred, which is the only information that lets you fix it precisely rather than prompt-engineering around it.
Quality and risk scores in production. Offline evaluation, run before deployment, cannot capture the distribution of inputs your agent will actually see. The gap between offline evaluation and production is where agents that pass all pre-deployment tests still fail in ways that accumulate quietly over weeks. Production scoring, applied to live traffic on a sampling basis, closes this gap incrementally. Prefactor records spans across agent runs and applies quality and risk scores to those spans, which means a team can see whether score distributions are shifting before a failure becomes visible to a user.
Token efficiency and cost. Token usage is not an engineering detail to optimize later. It is a production readiness criterion. Hidden token overhead and the cost metrics that matter documents the categories most teams miss during pilots: repeated context injection, redundant retrieval, and model-router mismatches that send cheap-task prompts to expensive models. A pilot that looks economical at fifty runs per day may be unviable at five thousand.
What the teams that ship look like
The companies that have reached production with agents share a pattern: they treated evaluation as an engineering deliverable, not a pre-launch checklist item.
Presidio Production deployed agentic AI across a fleet of approximately 2,300 wells for well surveillance, production intelligence, and artificial lift optimization, reporting a 3, 5% production increase as a direct result. That kind of claim requires measurement. You cannot report a 3, 5% production increase against an agentic deployment unless you have baseline metrics, a comparison methodology, and ongoing monitoring that attributes the change correctly.
The PGA Tour debuted a fully automated television broadcast production system with AI-driven camera selection and graphics, and reported writing tournament coverage ten times faster than before. Automated broadcast production operates under tight latency and correctness constraints. An agent that selects the wrong camera at the wrong moment produces an observable, timestamped failure. The measurement infrastructure exists because the production environment requires it.
KPMG adopted Microsoft Agent 365 specifically to manage how AI agents are deployed, monitored, and updated across its global organization. Governance and monitoring were the adoption criteria, not the agent capability itself. That ordering is not coincidental. A professional services firm cannot deploy agents that it cannot audit, and it cannot audit agents that it cannot observe.
PowerBank Corporation moved its IntelliScope agentic platform from beta to full operational deployment, including a public-facing investor relations agent, by February 2026. The transition from beta to production is precisely where measurement infrastructure either exists or prevents the transition from happening at all.
The sequencing problem
The most common mistake is treating evaluation as something you add before launch. Evaluation that is added before launch is a checkpoint. Evaluation that is built into the development cycle is a feedback loop. The difference in outcome is significant.
Silent agent failures in production do not announce themselves. An agent that is gradually drifting in its behavior, producing outputs that are slightly less accurate over three weeks, will not trigger an alert unless you have a baseline to compare against and a monitoring system that looks for drift. Detecting agent quality decay and production drift requires that the measurement infrastructure was in place before the drift started, which means before launch, not after the first incident.
For teams building multi-agent systems, the sequencing problem compounds. A failure in one agent propagates through the orchestration layer before any individual agent's output looks wrong. You need span-level tracing across the full call graph to identify where in the system the failure originated.
Evals and observability are related but distinct disciplines. Watching an agent run tells you what it did. Evaluating an agent run tells you whether what it did was correct. Both are necessary. Neither substitutes for the other.
The audit trail that governance stakeholders require is a byproduct of measurement infrastructure that was built for engineering reasons. Build the measurement first, and the audit trail is a reporting query. Build nothing, and the audit trail is a reconstruction project that happens after something goes wrong.
Where to start
Pick one agent that is currently in a pilot, define its expected behavior as a concrete schema, and instrument it to record what it actually does against that schema. That single step separates pilots that can be promoted from pilots that remain experiments indefinitely.
Start evaluating your agents or read the docs to see how instrumentation, scoring, and behavior validation connect in practice.