Your agent isn't unreliable — your evals are. Notes on the real production bottleneck

There's a conversation that repeats in every organization deploying agents. Leadership asks why the agent works in the demo and fails in production. The team says the model is unreliable. They try a bigger model, a longer prompt, a different framework. Nothing moves the needle predictably, because they're optimizing against a target they can't see.

The teams that escape this loop all did the same unglamorous thing first: they built an eval harness before they built the agent. Not a leaderboard score — a domain-specific, version-controlled set of cases that represent the actual work, scored automatically, run on every change.

Why this is the bottleneck

An agent is a system, not a prompt. It has a model, a tool surface, a context strategy, retries, and a dozen prompt fragments. When it regresses, the failure could be in any of them. Without an eval harness, every change is a coin flip and every fix is anecdotal. You ship something, it feels better, and you have no idea whether you improved the median case or broke the tail.

With an eval harness, the agent's reliability becomes an engineering metric you can move. You change the tool description, the suite tells you whether tool-selection accuracy went up or down. You swap the model, you see the cost-quality trade quantified instead of argued about.

What good evals look like

• Derived from real traffic. The best cases come from production failures, anonymized and frozen into the suite. Synthetic cases miss the weird inputs that actually break things.
• Scored programmatically where possible. Exact match, schema validation, retrieval grounding — anything you can check without a human. Reserve human review for the genuinely subjective.
• Run in CI. An eval suite that only runs when someone remembers is a document, not a guardrail. Wire it to the same pipeline as your tests.
• Versioned with the agent. When the suite and the agent live in the same repo, a regression is a failing check, not a support ticket.

What it means for delivery

For a delivery manager, the reframe is simple: evals are test coverage for non-deterministic systems. You wouldn't ship a service with no tests and call it unreliable. The same standard applies here. Budget for the eval harness as infrastructure, not as a research side-quest, and make "did the eval suite move?" the gate for every agent change.

The unglamorous truth of production AI in 2026 is that the model is rarely the problem. The measurement is. Fix the measurement and the reliability follows.