The eval set is the spec. Build it before the agent.

Ask a team how accurate their AI feature is and you will usually get a story rather than a number: it handles most things well, it struggled with a few cases last week, the new prompt seems better. Every one of those sentences is a measurement problem wearing the clothes of a quality problem. The fix is unglamorous and it is always the same: a labelled evaluation set, written before the agent exists.

It is a file of real inputs, each with the correct output written down by somebody who knows the domain. Not synthetic examples, not the ten cases you remember, and not a benchmark someone else built for a different business. A couple of hundred rows drawn from a real window of traffic is usually enough to be decisive, and small enough that a domain expert will actually finish labelling it.

{"id":"tri-0117","input":"where is order 88214? ordered tuesday","label":{"intent":"order_status","action":"draft_reply","human":false}}
{"id":"tri-0118","input":"Following up on the invoice attached last week.","label":{"intent":"vendor_billing","action":"filter","human":false}}
{"id":"tri-0119","input":"my daughter had a reaction to the product, what do i do","label":{"intent":"safety","action":"escalate","human":true}}

Three rows, and the third one is why the file matters. Any competent system answers the first two. The value of the set is that it forces a decision about the third before a model gets a vote, and that the decision is now written down, testable, and impossible to lose in a prompt revision.

The most common way an eval set lies is by being tidier than production. On an email support engagement for a D2C consumer brand, roughly 65% of everything arriving in the shared inbox was never a support request at all: promotional mail, vendor outreach, billing reminders. An eval set built only from genuine customer queries would have scored beautifully and predicted nothing, because the first job the system actually had was deciding what to ignore.

So the sampling rule is a real, unfiltered window of traffic rather than a curated selection, plus deliberate over-sampling of the cases that are rare and expensive. And the label vocabulary has to include the boring answers: filter, do nothing, escalate, not enough information. A set with no negative and no abstention labels teaches a system that it must always act.

Once the set exists first, the sequence of an engagement inverts. This is the order we run, and the order the deck describes on the work that has held up longest in production:

1. Pull a real sample window. Whatever actually arrived, for a period long enough to include a bad week.
2. Label it with the people who own the outcome. The labelling argument is the requirements gathering. It is where you learn that two departments disagree about what “urgent” means.
3. Write the existing response as an explicit workflow. The if/else version of the standard operating procedure, before any model is involved.
4. Measure the workflow against the set. Deterministic rules will resolve a surprising share of it, at zero inference cost and total predictability.
5. Only now, build agents, and tune them to a target accuracy on the set. The residual is the actual job, and it is now a much smaller, much better understood job.

Steps three and four are the ones teams skip, and skipping them is what produces an agent doing work a rule could have done more reliably and for nothing.

The labelling argument is the requirements gathering. Everything after it is engineering.

Silent regression, first. Prompts get edited constantly, and without a set the only regression test is a customer. With one, a change is a number that moved, and a change that improves the common case while breaking the rare expensive one is caught the day it is made rather than the quarter it is noticed.

Then model migration, which becomes routine: a cheaper model is a measurable substitution rather than an act of faith. Then scope: a system tuned to a target accuracy on a known set has a defensible definition of done, which is the difference between an engagement that finishes and one that becomes a permanent prompt-tinkering habit. And finally handover: the set is the artefact your team keeps, and the reason the system can be changed after we leave without anybody guessing.

The set is not overhead ahead of the real work. It is the specification, in a form a machine can check. It is typically the first week of an agentic workflow engagement, and if you do not know where to start, it is exactly the kind of question an audit answers in days.