Evals

An eval (short for evaluation) is a test case for a system whose output is language rather than a fixed value. You give it an input, you define what a good answer looks like, and you score what comes back. A suite is a few hundred of these, run on every change, producing a number you can watch move.

The scoring is the hard part. Sometimes there is a right answer and you can check it exactly. More often the answer is a judgment, so you score against a rubric, using a human, a second model, or both. Every eval program eventually becomes an argument about the rubric, which is the correct argument to be having.

Why it matters now

Software teams have always had a green light that meant “safe to ship.” For agents there isn’t one, because the same input can produce different output tomorrow, and because the failure that hurts is rarely a crash. It is a confident, plausible, wrong answer that no exception handler catches.

Evals are the substitute for that green light, and they are the first thing separating teams who deploy agents into real operations from teams who deploy them into a demo. They also give you something to push back with in procurement: a vendor’s benchmark scores tell you how their agent does on their work, and your eval suite tells you how it does on yours.

The misuse

The common failure is an eval suite built entirely from cases the system already handles. It goes green, stays green, and tells you nothing, because the cases that matter never entered it.

A suite is only worth the exceptions in it: the ambiguous input, the adversarial user, the record with a missing field, the case your best operator would escalate. Those are expensive to collect and unglamorous to maintain, which is why most suites do not contain them.

Keep one more distinction in mind. An eval measures whether a step produced a good answer. It does not measure whether the whole task succeeded, and on a multi-step agent those diverge quickly. Score the outcome at the boundary the customer sees, not the step.