By Paul Twist, Berlin | July 13, 2026
You've shipped an agent. It works great on your test suite. Three weeks later, your customers are hitting a failure mode you never saw coming.
This is evaluation debt. And 38% of AI teams say it's their primary blocker right now.
Here's what I mean: You write your agent eval suite against a dataset of tasks you already know about. The suite passes. You deploy. But the moment production traffic arrives, it's no longer hitting the world you evaluated on—it's hitting a different one. Your offline eval measures the past. Production measures the future. They are almost never the same.
This is not a framework gap. This is structural.
Every eval framework—LangSmith, Braintrust, Phoenix, DeepEval, Arize, OpenAI Evals—does the same job: it scores agents against a held-out test set you assembled. That set is a snapshot of what you knew last week. The moment real traffic drifts past that snapshot, the eval suite is measuring a world that no longer exists.
In Voker's State of YC AI Agents 2026 survey, teams reported that evals under-deliver not because the frameworks are bad, but because keeping evals current is an impossible chore that competes with shipping. The chore never ends because the distribution never stops moving.
A super-majority said they need to constantly update tests as they observe new failures. The insight is painful: the signal you need is in production, on the turns you haven't seen yet. An offline framework reaches that signal only after you've already labeled it and folded it back into the dataset—which could be weeks later.
Let me separate what evals measure from what actually breaks: Offline evals measure:
Offline evals cannot measure:
Offline evals are reactive by construction. They evaluate after the system has changed, measuring behavior you've already seen. The moment your agent encounters real user input—ambiguous intent, typos, incomplete context, tool failures—it takes a path your test suite never covered.
Single-agent systems have it easier. You control one entity's behavior. Multi-agent systems are evaluation hell because evaluation complexity compounds.
One agent's trajectory has reasoning steps, tool calls, and retries. Five agents have 2-5x the execution paths. Ten agents mean you're trying to debug emergent behaviors you can't predict: agent A calls agent B with stale data, agent C escalates when it shouldn't, the whole chain fails in a way none of the individual evals caught.
Most teams evaluating multi-agent systems end up running three or four tools in production simultaneously:
Stitching four tools together is unglamorous plumbing that nobody optimized for. It's also the difference between an agent system that fails silently and one that fails audibly.
Most teams shift to LLM-as-judge scoring to avoid hand-labeling infinite test cases. The problem: LLM-as-judge fails at systematic rates:
If you're gating CI on an LLM-as-judge score, you're gating on a metric with known 50% error rates. That's a quiet production risk.
Human-in-the-loop is not optional. Seventy-four percent of teams now require manual audit alongside automated eval. You know why? Because discovering your eval infrastructure is wrong after it ships is expensive.
Here's where it gets concrete. The useful signal—the stuff that actually predicts production failure—comes from:
Per-turn labels from real traffic: Did this turn succeed? Did the agent loop? Did it recover? This data is gold. One team (Fintool, fintech domain) found that generic NLP metrics like BLEU "don't work for finance." They built numeric-precision evals that fail if the model says "revenue was 4.2" without a unit, even though 4.2B is correct. They test for adversarial failures: inject fake numbers and verify the model cites real sources. They gate deploys on 5% score drop. That's production-informed eval.
Session-level observability: Every agent session is a trajectory. If you log every step—reasoning, tool calls, results, timing, cost—you have data that evals can consume in real-time. Most frameworks can't ingest session logs. They want datasets you hand them.
Online scoring over live traffic: Offline test of 100 tasks tells you about 100 known inputs. Online scoring tells you about the 10,000 unknown inputs you encounter next week. Online eval needs fast classifiers that return a signal in milliseconds, not LLM-as-judge scoring every turn (too slow, too expensive). But when it works, every labeled production turn becomes data that feeds your offline set, your fine-tunes, and your RL reward function the next iteration.
That closed loop—production label to training signal—is what separates agents that improve from agents that plateau.
When you run multiple agents across different runtimes (Claude Managed Agents, Cursor, Bedrock, custom harnesses), evals fragment:
You end up hand-stitching insights across platforms. When agent C fails, you check logs in three places. When you want to audit "every tool call across all agents that touched customer data," you're running queries in four different systems.
Production teams that scale agents fast don't solve this by picking better frameworks. They solve it by centralizing agent observability: one place where all agents (regardless of runtime) emit structured session data, one place to run evals over that data, one place to gate deploys.
Here's what mature teams are building (and what smart platforms are now shipping):
Control planes that treat agent sessions as first-class primitives:
This is different from frameworks that ask you to hand-assemble a dataset. It's infrastructure that says: your agents are already running in sessions, let's emit eval signals from those sessions directly.
Multi-agent systems need this more than single-agent systems. With five agents, you need to observe:
These require session-level tracing across runtime boundaries. Frameworks can't help you here. Only infrastructure can.
When you're evaluating agent platforms, ask:
If your platform can answer yes to all six, you've got eval infrastructure. If you can answer yes to three or fewer, you've got a framework, and you'll be hand-stitching eval signals for the next year. July 2026 is when this debt comes due. Teams that shipped single agents in May are now running 5-10 agents in July. The eval infrastructure that worked for one agent breaks at five. At ten agents running 24/7, offline evals become noise—they're so stale by the time you run them that they're measuring a system that no longer exists.
The teams that survive this transition invest in session-level observability from day one. They treat eval infrastructure as co-equal to the agent infrastructure itself. They don't ask "which framework should we use?" They ask "where do our agent signals live, and what observability can we build on top of that?"
If you're starting multi-agent infrastructure: This is not optional complexity. This is the infrastructure that separates agents that reliably improve from agents that plateau or regress.
The eval debt you don't know you have? It compounds every week. Pay it early.
Published: July 13, 2026
Learn more about multi-agent infrastructure in production at LiteLLM Agent Platform, which handles session-level observability, multi-runtime abstraction, and structured eval signal emission natively.