Everyone shipping AI agents right now says quality is up. But by how much, and based on what? “It feels better” was never going to be good enough, especially not for the people whose tests our agents write.
At Klarent we build autonomous QA agents. Our planner turns plain-language instructions into user journeys; our coder converts those journeys into real test scripts that run against real applications. If our agents quietly regress, so do our customers’ tests. That is the kind of failure mode you cannot ship your way out of after the fact, so we spend a lot of time making sure we would notice it early.
Here is how we do that, and what the last year of numbers actually looks like.
A score alone means nothing
The first thing worth saying: a single quality number, on its own, tells you almost nothing. 71% sounds fine until you learn it used to be 82%. 65% sounds mediocre until you learn every other model in your shortlist scores 40%.
Quality only matters in comparison. Against last quarter’s system, against a new model you are considering, against the version currently running in production. That framing is what makes the pipeline worth building in the first place. Without a common yardstick, every conversation about “which model is better for this” collapses into taste.
The dataset is most of the work
Building trustworthy evals is hard, and most of the difficulty lives in the dataset rather than the scoring code.
We source real data from real test flows, deduplicate aggressively, and sample so the distribution roughly matches what we see in production, not what looks impressive in a demo. Then we go through every example, one by one. Real review, by a human, on each row. It is slow and it is not glamorous, and it is the single most important thing we do to keep our numbers honest.
The temptation is always to skip that step. A synthetic set is faster to build and easier to grow. But synthetic data quietly overfits the model you built it with, and by the time you notice, you have been grading on the wrong test for months.
Calibration is its own beast
Once you have a dataset, you have to calibrate it. Too easy, and every model scores in the high nineties and you learn nothing about which one to pick. Too hard, and every model scores in the teens and, again, you learn nothing. The noise floor swallows any signal.
Hitting the sweet spot where a good model clearly separates from a mediocre one, without the whole suite becoming trivial, takes real iteration. We adjust difficulty by rebalancing the mix of easy, medium, and hard journeys, and by tightening the rubric on the ambiguous ones. Every time we rebalance, we rerun the older models on the new suite so the history stays comparable. Skip that step and you cannot tell real improvement from a change in the ruler.
The rest is discipline
After the dataset and the calibration, the rest is discipline. Consistent scoring criteria. Reruns of older models on the same suite whenever the suite changes. Same environment, same prompts, same retries. It sounds boring because it is, and it is exactly the part teams cut first when they are moving fast.
Without it, you cannot tell real improvement from measurement noise, and you end up making model decisions based on a delta that is not actually there.
Questions we can finally answer
The point of putting all this in place is to turn model conversations from opinion into arithmetic. With a stable, calibrated eval running continuously, we can finally answer things like:
- Is this new model worth the switch?
- Where would we regress if we shipped it today?
- Which model fits each task best: planning, coding, self-healing?
Quality is not the only axis, though. Sometimes a “better” model is slower, more expensive, or simply unavailable in a region where we operate. Sometimes the quota we can get is a fraction of what we would need to serve customers. Those constraints are real, and the pipeline has to surface them alongside the quality number so the tradeoff is visible instead of buried.
What that looks like in practice
We have built a pipeline that continuously benchmarks our agents, adapts as new models and quotas land, and shows us exactly what is changing week over week. Every quality decision is backed up with numbers, and with the confidence that the numbers mean what we think they mean.
Here is what that has looked like on our internal quality score over the last year:
+23 points in under a year, with the biggest jump landing in the most recent cycle.
Each of those points is a decision we made. A model swapped in, a prompt reworked, a coder agent tuned. None of them felt dramatic in the moment. The chart is what happens when you keep the ruler honest for long enough.
Why this is the hardest part
Keeping quality moving up while staying reliable is, by a wide margin, the hardest part of shipping autonomous agents. It is what everything else depends on. A faster agent that regresses is not faster. A cheaper agent that misses bugs is not cheaper. The whole system is only worth using if the quality curve keeps bending the right way, and if we can prove it.
Next, we will dig into what one of those decisions actually looks like, agent by agent, with the numbers that pushed us to make the call.
How are you measuring quality in your own AI systems? What tradeoffs matter most to you?
