Here's a number worth sitting with. In LangChain's 2026 State of Agent Engineering report, which surveyed more than 1,300 practitioners, 89% of teams running agents in production have implemented observability — but only 52% have implemented evaluations. That 37-point gap is where most agent quality quietly dies.
If you've shipped an LLM agent, you already feel this gap even if you've never named it. You have traces. You have dashboards. You can replay any session and watch the agent reason, call tools, and respond. And yet, when someone asks "is it actually getting better or worse this week?", the honest answer is a shrug. You can see everything that happened and still have no idea whether any of it was good.
That's the difference between observability and evaluation, and conflating the two is the most expensive mistake in agent engineering right now.
Observability tells you what happened. Evals tell you whether it was right.
Observability is a microscope. It shows you the trajectory: the agent received a query, retrieved three documents, called the search_orders tool with these arguments, got this response, and produced this answer. Invaluable for debugging. Completely silent on the question that matters to your users — was the answer correct, helpful, and safe?
Evaluation is the judgment layer on top of the trace. It takes the same trajectory and asks: did the agent call the right tool? Did it recover when the tool returned an error? Was the final answer factually grounded in what it retrieved, or did it hallucinate a plausible-sounding order number? Did it follow your refund policy or invent one?
The reason so many teams have the first and not the second is simple: observability ships with your framework. Evals you have to build, and building them well means confronting a problem most engineering teams are not set up to solve — you need labeled examples of what good looks like, and you need them to be trustworthy. That is a data problem long before it's a tooling problem.
The three tiers of agent evaluation
The teams closing the gap aren't running one giant eval. They're running evaluation as infrastructure, in three tiers that map cleanly to how you already think about testing.
Tier one: fast checks on every change. These are the unit tests of the agent world. Did the agent call the expected tool with valid arguments? Did it stay under the latency and token budget? Did it avoid an obvious refusal or loop? These are cheap, deterministic, and run on every PR. They catch the dumb regressions — the prompt edit that broke tool-calling for an entire category of inputs.
Tier two: quality regression suites. This is where it gets hard, because "quality" isn't a boolean. Here teams lean on LLM-as-judge — using a strong model to score outputs against a rubric for things like factual accuracy, completeness, and guideline adherence. In the LangChain data, about 53% of teams running evals use LLM-as-judge, because it's the only thing that scales to thousands of test cases overnight.
Tier three: production monitoring. Sampling live traffic and scoring it continuously, so you get an alert when answer quality drifts after a model swap or a sneaky distribution shift in user queries.
Most of the engineering conversation fixates on tier two tooling. But the tooling is the easy part. The hard part is the rubric and the reference data feeding it — and that's where the gap actually lives.
LLM-as-judge has a calibration problem
Here's the uncomfortable truth about LLM-as-judge: an unaligned judge is a confident liar. A model scoring your agent's outputs has its own biases — it favors longer answers, it rewards confident tone over correctness, it misses domain-specific errors a real expert would catch instantly. If your judge says quality is 94% and your users are churning, your judge is wrong, and you won't know until the dashboard and reality have fully decoupled.
The fix is calibration against human judgment. You take a representative sample, have qualified humans score it, and then tune your LLM-judge's prompt and rubric until its scores correlate with the human ones. The same LangChain data shows why this matters: roughly 60% of teams running evals still rely on human review for nuanced and high-stakes cases, more than rely on LLM-as-judge. Human review isn't the legacy approach being automated away. It's the ground truth that makes automation trustworthy.
This is the part nobody likes, because it's labor that doesn't look like engineering. Someone with actual domain expertise — a clinician for a medical agent, a developer for a coding agent, a financial analyst for a finance bot — has to sit down and judge a few hundred trajectories carefully. The quality of that judgment is the ceiling on the quality of your entire eval system. Garbage reference labels produce a garbage judge, which produces a dashboard that lies to you with great confidence.
Where this connects to data quality
If you take one practical idea from this, make it this: your eval system is only as good as the human-labeled data underneath it. Not the framework. Not the dashboard. The labels.
That's why teams who are serious about agent quality treat evaluation data with the same rigor they'd apply to training data — clear rubrics, expert annotators, multiple passes to catch disagreement, and a measured inter-rater reliability so they know the labels themselves are consistent. This is exactly the discipline that high-quality model evaluation and QA work is built on: benchmark dataset construction, response scoring against rubrics, hallucination detection, and red-teaming for the failure modes your happy-path tests will never surface.
It also overlaps heavily with the world of reasoning and human-feedback data — preference ranking, agent trajectory correction, and tool-use validation. The skill of looking at a multi-step agent trajectory and pinpointing exactly where it went wrong is the same skill whether you're generating RLHF data to improve the model or eval labels to measure it. The pipeline that produces good human feedback for training is the same pipeline that produces a trustworthy judge for evaluation. Most teams discover this the hard way, after their first calibration run reveals their judge and their experts disagree on a third of cases.
A concrete starting point
You don't need to boil the ocean. If your team is in the 89% with observability and the 48% without evals, here's a week-one move:
- Pull 100 real production trajectories from your traces — ideally a mix of successes, complaints, and weird edge cases.
- Write a rubric. Three to five dimensions, each with concrete pass/fail criteria. Force yourself to define what "grounded" and "policy-compliant" actually mean for your product.
- Have a domain expert — a real one — score all 100 by hand. Measure how often two experts agree. If they don't, your rubric is too vague; fix it before you automate anything.
- Now build your LLM-judge, and validate it against those 100 human labels before you trust a single automated score.
That sequence — human ground truth first, automation second — is the whole game. The teams that skip step three and jump straight to LLM-as-judge are the ones whose dashboards drift away from reality.
Observability told you the agent did something. Evaluation, built on honest human-labeled data, tells you whether it did the right thing. In 2026, with agents making real decisions in production, that's not a nice-to-have. It's the difference between an agent you can trust and one you're merely watching fail in high resolution.
I work at SyncSoft.AI, where our bilingual, SME-led teams build evaluation datasets, human-feedback data, and QA pipelines for AI teams. If you're wrestling with the eval gap and want to talk through what good reference data looks like for your use case, we're happy to compare notes — reach out anytime.
Top comments (0)