Evaluating AI agents: what "works better" actually means

"It works much better." It is the sentence that closes most reviews of an agent in production. And it is a sentence that carries no information. Better than what. Measured by which criterion. With how much confidence that the difference is not noise. Three questions, and in most teams there is no written answer to any of them.

The problem is not personal rigour, it is conceptual. "Better" is not a property of the system: it is a relationship with a reference point. And "good" is not an impression: it is the result of applying a criterion someone wrote before looking at the output. The two missing objects are always the same: the rubric — what counts as correct — and the baseline — what it is compared against. Without them, any comparison between two versions of an agent is a conversation of opinions with technical vocabulary.

In the previous article on LLMOps we described the full cycle and said that maturity level 2 begins when a number can block a deployment. This article is about where that number comes from: how the rubric and the baseline are built from the golden set, how you know whether a difference is real, and what the research on the problem says — because it has spent three years documenting exactly the mistakes we teams keep repeating.

Why the question breaks down with agents

Evaluating a single model call is uncomfortable but tractable: input, output, criterion. Evaluating an agent is something else, for five specific reasons.

There is more than one correct trajectory. A task solved well can be solved by checking the CRM first and then the knowledge base, or the other way round, or without checking the knowledge base at all because the CRM was enough. There is no single "reference answer" to compare text strings against.

The result is not a text, it is an effect in the world. The agent created the ticket, issued the refund, modified the file, sent the email. What has to be verified is the final state of the system, not the elegance of the explanation.

There is partial credit and it does not always count. Eight correct steps out of ten and a ninth that corrupts the state is not 80%: it is a failure. In other tasks, eight out of ten does count, because a human fixes the rest in two minutes. The rubric has to decide which of the two your case is, and that decision is a business one, not a technical one.

Non-determinism compounds. The variance of one step multiplies with the next. In 2025 Toby Ord proposed a surprisingly simple model for this: if the agent has a roughly constant failure probability per minute of human work the task represents, then the success rate decays exponentially with task length, and each agent is characterised by its own "half-life". The operational consequence is harsh: you cannot extrapolate from five-minute tasks to two-hour tasks. Your agent getting 90% of short tasks right says almost nothing about long ones.

And cost varies per run. Two systems with the same success rate can differ by an order of magnitude in what each run costs. Comparing on accuracy alone is comparing half the picture.

"Good" is a rubric, not an impression

A rubric is an explicit set of criteria that turns a holistic judgement into discrete checks. A survey published this summer — From Holistic Evaluation to Structured Criteria, Chen and others, June 2026 — places rubrics at three levels: the evaluative, where they break a global judgement into verifiable dimensions; the training level, where they act as a dense reward signal; and the intrinsic, where they emerge from the model's own behaviour. What a product team needs is the first, and it is the one almost nobody writes.

Let us start with what a rubric is not: a 1-to-10 "quality" scale. Asking a judge — human or model — to score the overall quality of an answer produces a number with the reproducibility of a satisfaction survey. Asking it to verify twelve concrete criteria produces twelve auditable answers, each with its evidence. The difference between the two is the difference between a numbered opinion and a measurement.

How it is derived from the golden set, step by step

You already have the golden set if you followed the cycle in the previous article: thirty or fifty cases per capability, labelled by whoever knows the domain. The rubric is extracted from there, not from an abstract brainstorming session. If you do not have it yet — or if what you have is a sheet with the prompt's examples — start with how a golden set is built: where the cases come from, how many you need, and why labelling error is the ceiling for everything you measure afterwards.

• Take 20 to 30 cases from the golden set with their reference answers. No more: the goal of this phase is to find patterns, not to cover everything.
• Ask the domain person two things, case by case: what must appear no matter what, and what must never appear. Do not ask "is this good?" — that question returns an impression. The other two return criteria.
• Group them. Anything appearing in more than a third of the cases is a general criterion for the capability. Anything appearing once is a case-specific criterion, and that is fine too: HealthBench works that way.
• Rewrite each criterion as a binary check with evidence locatable in the trace. If you cannot point at where it holds or where it fails, the criterion is not finished.
• Weight them and mark the blocking ones. Not all criteria are worth the same, and some do not average: either they hold or the whole case fails.

The industry reference for this method is HealthBench, the clinical evaluation OpenAI published in 2025: 5,000 health conversations, each with its rubric written by physicians — 262 professionals from 60 countries and 26 specialties — totalling 48,562 criteria, each with its point value according to the importance the physician assigned. Nobody wrote "score clinical quality from 1 to 10". They wrote, criterion by criterion, what should appear and what should be avoided. You do not need 48,562 criteria: you need the discipline that produces those criteria.

Anatomy of a criterion that works

The quality test for a criterion is that last line: two different people, the same case, the same verdict. If the criterion needs a conversation to settle, it is not finished. And if it is not finished for a human, a judge model will not apply it stably either.

Weighting, blocking criteria, and the average's trap

With twelve criteria and an arithmetic mean, a system that fails the safety criterion but passes the other eleven scores 92%. It is exactly the wrong number. That is why an operational rubric has two kinds of criterion:

• Cumulative: they add weighted points. They measure quality.
• Blocking: if they fail, the case is worth zero regardless of the rest. They measure acceptability.

Blocking criteria are usually few — two or three — and almost always from the same family: irreversible actions without confirmation, data leaving the perimeter when it should not, and invented claims presented as facts. If your rubric has no blocking criteria, either your system is very harmless or you have not yet thought about what is unacceptable.

In the report, moreover, the aggregate average is never presented alone. It is presented per capability, as we said in the LLMOps cycle: an average that rises while hiding an eight-point drop in the critical capability is worse than not measuring, because it creates confidence where it should raise an alarm.

Outcome rubric and process rubric

There are two distinct questions and they should not be mixed. The outcome rubric asks whether the final state of the world is right: was the order cancelled, is the amount correct, does the file compile? The process rubric asks whether the agent got there by an admissible route: did it use only permitted tools, did it respect the order, did it avoid side effects, did it avoid looping?

Evaluating the trajectory is expensive by hand, and this is where Agent-as-a-Judge (Zhuge and others, ICML 2025) contributes a useful data point: an evaluating agent able to open files, run checks and review each step reached 90% alignment with human judgement on their DevAI benchmark, at 2.29% of the cost and 2.36% of the time of human evaluation. Process evaluation stopped being an academic luxury.

The practical rule we apply: outcome always; process when the right result by the wrong route would be unacceptable. That is, when there are irreversible actions, when there are compliance obligations — covered in Compliance-First AI Design — or when the route determines the cost. In a flow of several chained stages, process almost always matters.

Your rubric can be correct and still be measuring something else

This is the point most often skipped, and the most expensive. A well-written rubric can still fail to measure what you think. Establishing Best Practices for Building Rigorous Agentic Benchmarks (Zhu and others, NeurIPS 2025) formalises it in two conditions:

• Task validity: the task should be solvable if and only if the agent has the capability you claim to be measuring. If it can be solved through a shortcut that does not require that capability, the task is not valid.
• Outcome validity: the check should correctly indicate whether the task was solved. If the check is weak, it measures something else.

The authors' examples are uncomfortable precisely because they are not from improvised benchmarks. They document that SWE-bench Verified uses insufficient test cases and that τ-bench can count empty responses as successes; taken together, defects of this kind can under- or over-estimate an agent's performance by up to 100% in relative terms. If it happens to public, reviewed, widely cited benchmarks, it happens all the more to the rubric your team wrote on a Thursday afternoon.

"Better" is a baseline, not an adjective

With the rubric you can already say "good". To say "better" you need a reference point, and this is where most comparisons fall apart: the new version is compared against a memory of the old one. A memory is not a baseline.

The dumb baseline, or why your architecture may be contributing nothing

In 2024 a Princeton group — Kapoor, Stroebl, Siegel, Nadgir and Narayanan — published AI Agents That Matter, an analysis of how agents are evaluated that remains the most uncomfortable read if your team has just built an agentic pipeline. Their central finding: simple baselines Pareto-dominated state-of-the-art agents — Reflexion, LDB, LATS — on HumanEval, at 50 times less cost. And their diagnosis: the community looks only at accuracy, with no attention to cost, and that produces needlessly complex and expensive agents, plus wrong conclusions about where improvements come from.

Translated into a product team's reality: if nobody measured the simple baseline — a single call with good context, no orchestration — you do not know whether your seven-step architecture adds quality or only adds invoice. The ablation is the cheapest experiment in the catalogue and almost nobody runs it, because the result can be politically uncomfortable.

The human baseline is measured, not imagined

The other mistreated baseline is the human one. The agent is compared against an ideal person who never makes mistakes, and the conclusion is always the same: "it's not there yet". But the human doing that task today has an average time, a cost per task and an error rate that is not zero. Without those three numbers, the comparison is biased from the start.

Measuring it does not require a study: twenty timed tasks reviewed with the same rubric you apply to the agent. The same rubric is the important part — if you judge the human leniently and the agent under a microscope, you are not comparing, you are justifying a decision you had already made.

Cost is not a consequence: it is an axis of the comparison

From which follows the methodological consequence: you do not compare one point against another point, you compare positions on a quality-cost frontier. A system with 92% accuracy at €0.40 per task and another with 86% at €0.04 are not ordered: they are two different points on a frontier, and which is "better" depends on who absorbs the remaining 8% and at what price. The metric that makes that frontier comparable is cost per useful task, and how it behaves at scale is covered in the real cost of putting AI into production.

Reliability is not capability: pass@k versus pass^k

Here is a distinction that decides more deployments than it seems, and it comes from τ-bench (Yao and others, 2024), Sierra's benchmark for agents that converse with a user and handle tools under domain policies.

• pass@k: the agent succeeds at least once in k attempts. It measures potential. It is the right metric when a cheap verifier discards bad attempts: compiling, passing tests, validating a schema.
• pass^k: the agent succeeds all k times. It measures reliability. It is the right metric when the output goes to production without a net.

The τ-bench figure is the one to keep in mind: advanced function-calling agents solved less than 50% of tasks in a single pass, and in the retail domain they fell below 25% on pass^8. In other words: of every four tasks they knew how to solve, only one was solved eight times in a row.

The business question, then, is not "what percentage does it score?" but "at what k do I need it?". And the right k is the number of times the process runs before a human reviews it. If an agent processes 200 returns a day and nobody looks at them, your k is not 8: it is 200. Reporting pass@1 in that scenario is not optimistic, it is incorrect.

Is the difference real? The minimum statistics required

Suppose you already have a rubric, a baseline and a well-chosen metric. The new system scores 85% and the old one 82%. Is that an improvement?

You probably do not know. With 50 cases and a rate near 80%, the standard error is around 5-6 points. A 3-point difference fits entirely inside the noise. And if each case was run only once, part of those 3 points is simply the model's non-determinism.

The reference work here is Adding Error Bars to Evals, by Evan Miller (Anthropic, 2024), which opens by criticising the dominant practice: reporting evaluations with a "highest number wins" mindset, in bold, with no significance testing at all. Its recommendations apply directly to an internal report:

• Report the standard error alongside the mean, using the central limit theorem.
• Use clustered standard errors when questions come in groups — several cases derived from the same document or the same customer — because they are not independent.
• Analyse paired differences: both systems on the same cases, measuring the difference case by case. It is the cheapest way to gain statistical power without enlarging the set.
• Run a power analysis beforehand, to know how many cases you need to detect the difference you care about.
• Generate several responses per case and average them, to reduce generation noise.

None of this requires a statistician on staff. It requires accepting one uncomfortable sentence in the report: "the observed difference is not distinguishable from noise with this number of cases". Writing that sentence when it applies is what separates a team that measures from a team that decorates.

The judge has to be evaluated too

Almost every rubric at scale ends up applied by a model acting as judge. The foundational work — Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, Zheng and others, 2023 — delivered the good news and the bad in the same breath: strong judges reached over 80% agreement with human preferences, the same level of agreement humans have with each other; and at the same time they exhibited position bias (preferring the first option), verbosity bias (preferring long answers), self-enhancement (preferring their own model family) and limited reasoning ability on tasks requiring calculation.

The countermeasures are mechanical and cheap:

• One criterion per call. Do not ask for a global score; ask for a binary verdict with the evidence supporting it.
• A judge model different from the one evaluated, ideally from another family, so as not to reward its own style.
• Alternating order in pairwise comparisons: running A-B and B-A and averaging neutralises position bias.
• Calibration against human labels before trusting it, measuring agreement (kappa) on a sample, plus a permanent human sampling of around 10% to detect when the judge drifts.

And one observation that organises all of the above: a judge is far more reliable verifying a binary criterion with evidence than scoring overall quality. That is the technical reason — not the aesthetic one — why the rubric is not an optional methodological refinement: it is what makes an automated judge usable at all.

When the eval becomes the objective

Every metric used to decide ends up optimised, and every optimised metric stops measuring what it measured. In agent evaluation this takes a very concrete shape: after a few months the system is excellent on the 120 cases of the golden set and just as weak in production.

Three countermeasures that work and cost almost nothing:

• A held-out set. 20-30% of cases are never used for iteration. They are touched only to decide important promotions. If it starts being used for debugging, it is no longer held out — and that has to be said in the report.
• Rotation. Every quarter new production cases come in and those that have been green for six months without ever failing go out. A case that always passes no longer carries information.
• Separation of roles. Whoever optimises the system does not write new criteria without review by the domain person. It is not distrust: it is that whoever knows the failure tends to write the criterion their solution already satisfies.

The feeling of improvement is not evidence

It is worth closing the argument with the most uncomfortable data point of all. In July 2025, METR published a randomised controlled trial with experienced open source developers working in their own repositories: 16 people, 246 real tasks. Before starting they forecast a 24% speed-up. After the session, they estimated they had gone 20% faster. The measurement showed them 19% slower.

It is worth being honest about scope: METR has marked that result as historical — it reflects tools and workflows from early 2025 — and has changed the experiment's design. The lasting conclusion is not "AI slows you down". It is something more useful and more general: perceived improvement and measured improvement can point in opposite directions, even for expert professionals assessing their own work immediately after doing it. That is why "the team says it works much better" is not data. It is a starting point for measuring.

"Better" also means "longer"

There is one last sense of "better" that increasingly matters for agents. METR maintains a time horizon metric: the task length — measured by how long it would take a human professional — that an agent completes with 50% reliability. In its January 2026 revision (Time Horizon 1.1), the post-2023 doubling time is estimated at about 131 days, and as of February 2026 the leading model was around 14 and a half hours of horizon at 50%.

For a team this reorders the question. If reliability decays exponentially with task length — Ord's half-life model — and model horizons grow quickly, the useful question stops being "what percentage does my agent score?" and becomes "up to what task length does it hold the reliability my process needs?". That frontier is what has to be measured, and it is what moves when you change model. Fixing 50% as the threshold is, moreover, a research convention: for a business process without human review, the relevant threshold is usually a good deal higher.

The comparison record: what makes a report credible

All of the above condenses into a very unglamorous artefact: the record with which a team declares that version B is better than A. If any of these lines is missing, the claim is not verifiable by anyone who was not in the room.

The six mistakes that void a comparison

None of them is exotic. We have seen all six in technically solid teams.

1. Comparing against "what we had" without ever having measured it. If the previous system never went through the rubric, there is no comparison: there is a new version measured and a memory.

2. Letting whoever optimises the system write the rubric. With no bad faith, the criteria end up looking suspiciously like what the solution already does well.

3. A single run per case. In a non-deterministic system, one pass is a sample of size one. Three to five per case is the reasonable minimum, and the variance between them is already valuable information.

4. Averaging all criteria equally. Without blocking criteria, a safety failure is diluted among eleven passes and out comes a reassuring 92%.

5. Changing two things at once. New prompt and new model in the same release: you will know the number changed, not why. Atomic change is not purism, it is what makes the result attributable.

6. Leaving cost out of the report. It is the mistake the Princeton work documents, and the one that produces expensive architectures nobody can justify six months later.

The first two weeks

If you already have a golden set — and if not, that is the previous step — this is what produces the most signal per hour invested.

Week 1 · The rubric. Take 25 cases and extract the criteria with the domain person, asking what must appear and what must never appear. Rewrite them as binary checks with locatable evidence. Mark two or three as blocking. And run it through the null agent test before using it for anything.

Week 2 · The baselines and the record. Using that rubric, measure the null agent, the current release, and the simplest ablation that solves the task. Run each case three to five times. Compute the paired difference with its interval. Fill in the nine-line record and publish it where the team can see it.

At the end of the second week you will not have a better system. You will have something more valuable: the ability to know, next time, whether it is. The whole LLMOps cycle rests on that ability — without it, quality gates cannot block anything, and a gate that does not block is decoration.

Measuring is what turns speed into progress

There is a version of AI adoption that consists of moving very fast without knowing where. It is easy to recognise: lots of activity, lots of demos, weekly releases, and nobody able to say with a number whether today's system is better than March's. The discipline of the rubric and the baseline is what separates that version from the other one.

It is the same logic we apply to code with Spec-Driven Development: write the criterion before the artefact. In onext AI-Accelerated Development programmes, the rubric and the baselines are part of the harness we leave installed, not a later deliverable. The results we sign with clients in 2026 — ×7 delivery speed, 0 sprints lost, −50% time-to-production — rest precisely on that: teams that deploy fast because they know, before deploying, whether the change is good.

Frequently asked questions

What is a rubric in AI agent evaluation?

It is an explicit set of criteria that turns a holistic judgement — "this answer is good" — into discrete checks that can be verified one by one. Each criterion is written as a binary check with evidence locatable in the trace: what must appear, what must never appear, which tool should have been used. It is not a 1-to-10 scale of overall quality: asking a judge to score "quality" produces a barely reproducible number, whereas asking it to verify twelve concrete criteria produces twelve auditable answers.

How do you build a rubric from the golden set?

With twenty or thirty already-labelled cases, you ask the domain person, case by case, what must appear no matter what and what must never appear — not "is this good?". Recurring answers become general criteria; the rest become case-specific criteria. Then each criterion is rewritten as a binary check, weighted, and marked as blocking or not. OpenAI's HealthBench is the industry reference for the method: 5,000 conversations with rubrics written by 262 physicians and 48,562 criteria weighted by importance.

What is the difference between pass@k and pass^k, and which matters in production?

pass@k measures whether the agent succeeds at least once in k attempts: it is potential, and it is the right metric when a cheap verifier discards bad attempts (compiling, passing tests). pass^k measures whether it succeeds all k times: it is reliability, and it is the right metric when the output goes to production without a net. On τ-bench, agents with under 50% success in a single pass fell below 25% on pass^8. In business terms, the right k is the number of times the process runs before a human reviews it.

How many cases are needed to claim one system is better than another?

More than most teams use. With 50 cases and an accuracy near 80%, the standard error is around 5-6 points: a 3-point improvement is indistinguishable from noise. The cheap way to gain statistical power is not multiplying cases but comparing paired — both systems on the same cases, measuring the difference case by case — and running each case several times to average out non-determinism. That is exactly what Anthropic's work on error bars in evals recommends.

Which baseline should an agent be compared against?

Four, not one: the null agent (which does nothing, to validate that the rubric does not hand out free points), the previous system, the human doing the task today with their real cost and real error rate, and the ablation — the simplest version of your own system. That last one produces the most surprises: Princeton's "AI Agents That Matter" showed simple baselines Pareto-dominating state-of-the-art agents at 50 times less cost. Without an ablation you do not know whether your agentic architecture adds quality or only adds invoice.

Can I trust the team saying the agent works much better?

Not as data. In METR's randomised controlled trial with experienced open source developers, participants forecast a 24% speed-up, after the session they estimated a 20% speed-up, and the measurement showed a 19% slowdown. METR has marked that result as historical and changed the experiment's design, so the lasting conclusion is not "AI slows you down": it is that perceived improvement and measured improvement can point in opposite directions, even for experts assessing their own work.

Sources cited

• Yao, Shinn, Razavi, Narasimhan (Sierra) — τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (the pass^k metric)
• Kapoor, Stroebl, Siegel, Nadgir, Narayanan (Princeton) — AI Agents That Matter (cost-controlled evaluation, Pareto frontier)
• Zhu and others — Establishing Best Practices for Building Rigorous Agentic Benchmarks (task and outcome validity, NeurIPS 2025)
• OpenAI — HealthBench (rubrics written by physicians, 48,562 weighted criteria)
• Zhuge and others — Agent-as-a-Judge: Evaluate Agents with Agents (trajectory evaluation, ICML 2025)
• Miller, E. (Anthropic) — Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations
• Zheng and others — Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (judge biases)
• Chen, Han, Yan, Zhu, Sun, Che — From Holistic Evaluation to Structured Criteria: Rubrics Across the Evolving LLM Landscape (June 2026)
• Ord, T. — Is there a half-life for the success rates of AI agents? (exponential decay with task length)
• METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity and Time Horizon 1.1 (January 2026)