A conversation with a single AI agent can seem flawless on its own and still point to a defective product. That gap is driving a shift in how companies evaluate agents, away from rating individual trails and comparing cohorts of users to a baseline.
In VB Transformation 2026, Harrison Chase, CEO of LangChain; Hui Zhang, CTO and co-founder of Conviva; and Emmanuel Turlay, director of engineering at CoreWeave, described that shift, along with a parallel move toward cheaper, more limited judge models.
Agent as Judge (judging the output of one AI agent against another) has not replaced LLM as Judge, which Chase says is still the default. The biggest tension, Zhang said, is between automated assessment, whether by an LLM or an agent, and human review.
"It has scalable but no foundation, whether it’s agents as judges or LLMs as judges, you rate the outcome, you rate the work. It’s still very difficult to ground it and then you use humans and that’s just not scalable." Zhang said. "The entire industry is facing this, what poison do you want to choose."
Evaluation criteria now function as product specifications.
That gap—a conversation that scores well but still indicates a defective product—is what teams try to close by creating a set of thorough evaluations before shipping something. Chase said that doesn’t work.
"Sometimes we see teams that almost have evaluative paralysis," Chase said. "They say, this is an evaluation set, I can’t start it. The best teams launch and then iterate."
Chase framed the evaluation criteria as a living specification, not a set of single tests: a product requirements document, the standard software development specification for what an application should do. "Those evaluated are like the new PRD," said. "They define what your agent should and should not do."
Turlay described approaching the same ruling from a different angle. "I was trying to reach 100% coverage for my tests and was still having errors in production." he said: a set of tests that seemed complete but still left out what mattered, the same gap Chase was describing with the assessments.
He said extensive, ongoing monitoring detects more actual failures than a set of extensive pre-launch tests. Teams should first set up broad online checks, use them to identify classes of failures as they occur, and then create a specific offline assessment around the issues that arise.
Why writing down traces one at a time is a mistake
Even a well-designed evaluation process can give incorrect results. Zhang’s objection is to the way most teams conduct the assessment: by sampling traces, whether 50 of them or an entire population, scoring each of them in isolation. That approach misses a signal that only appears when comparing cohorts of users to a baseline, a method Zhang calls contrastive analysis.
Zhang illustrated this with a retail example: A buyer asks an agent for a running shoe before a half marathon, the agent asks qualifying questions, and the buyer purchases a shoe. Individually graded, that interaction looks good. But the clarification rate, how many follow-up questions an agent asks before completing a task, was three times higher than the baseline value for that shoe category across the entire user population. A second metric, how often shoppers completed their purchase outside of the conversation, was five times higher than the baseline for the same category.
None of the numbers are visible from a single trace. Both point to a category-specific problem that can be debugged. Zhang said the industry also lacks a second source of data: what happens before, between and after the conversation, not just the trace itself.
Sizing the judge for the job
Once contrastive analysis points out which category is truly broken, the next issue is who polices it in the future and at what cost. Turlay’s rule was to start with the most capable model available to demonstrate that a task has a solution and then work down. If it can’t be done with a top-tier model, he said, it won’t work with a smaller one. Once a pattern is viable, teams can sample a fraction of the traffic instead of judging every interaction and move simpler tasks, such as binary classification, to smaller open source models.
LangChain went further and tuned its own model to detect when a user believes the agent made a mistake, a signal Chase calls perceived error. "The model we tuned was a Qwen model," he said, referring to Alibaba’s open source family. Combining manual labeling with distillation, the result was good. "The same as (Claude)Sonnet, for, depending on how we serve it, a cost reduction of 10 to 100 times," Chase said.
Not all railings need a model. Chase pointed to Claude Code’s own guardrails as proof: regular expressions, the common programming technique for finding and validating patterns in code. "A lot of the barriers they had were just regular expressions," said. "They weren’t little LLMs, they were just regular expressions."
LLM as a judge does not mean that the human being in the circuit disappears
The bigger question is whether using LLM as a judge eliminates the need for a human being in the loop.
Turlay pointed to liability, based on his previous work at an autonomous vehicle company. His team compressed data ingestion and retraining into a two-week cycle to send a new model to the car. Even then, someone still had to log out.
"I felt confident on behalf of the company in saying that this model should go on the car." said. The same logic extends to the legal, financial and health fields. "Before we can remove a human to say, I support this and I take legal responsibility for it, it will be a while before agents can do it themselves."
Zhang agreed that a human has to remain the gatekeeper in corner cases, even when automation eventually runs at a scale that surpasses individual human precision: Machines can see more at the pattern level.
Chase went further: that human control is not just a safety net. "Human in the loop is really important for building trust in how these agent systems work, and also very important for systems memory and learning." said. "There have to be interactions for the system to learn."
