A buying reference for agent training data

Content reviewed

Topics Evaluation sets

Evaluation sets for agents

What a held-out evaluation set has to prove, how to slice it so failures stay visible, and which versions belong in every score you are asked to accept.

Answer in brief

An evaluation set is a held-out collection of tasks used to measure one stated agent capability under a stated scoring method. Each item should answer a concrete question — did the agent complete this kind of task with the permitted tools and the expected end state? — and the set should be defined before the first item is collected.

Aggregate accuracy is a weak buying signal. Ask for scores per slice, with item counts, and for the model, prompt, dataset and scorer versions named in the report. A score without those details cannot be reproduced, compared or audited.

This entry is editorial guidance on how to specify and check an evaluation set. It does not rank suppliers or certify a score as an independent measurement. Ask to see a scored sample, including the failures, before you accept any headline result.

Entity chain

Held-out tasksScoring methodFailure slicesVersioned report

What an evaluation set is for

An evaluation set is not training data, as the glossary entry sets out. It measures what the agent does on tasks it has not been trained on, so keep it out of the training pipeline and out of prompt iteration. If a supplier tunes prompts against the same items, the result is a development score wearing an evaluation label.

Each item should name the capability it tests and the evidence that counts as a pass. Three signals are usually worth scoring separately: output validity (does the response parse into the agreed schema), tool correctness (the right tool, valid arguments, no forbidden action) and task success (the final state meets the objective). A run that returns fluent prose after calling the wrong tool is a failed example, not a partial win.

The demonstration teaches a decision; the evaluation item measures whether that decision generalizes. Both need the tool-use trajectory behind them to be reviewable.

Failure slices and why averages hide them

An aggregate score hides the distribution of items. A set that is mostly one-step lookups with a handful of five-step recoveries can report a comfortable average while the recovery behavior — usually the reason the agent is being built — is barely tested. That is arithmetic, not a claim about any supplier.

Ask for scores by slice: task family, number of steps, ambiguity level, tool type, environment state and known failure mode. For each slice ask how many items it contains. If a slice is too small to support a conclusion, name it as insufficient rather than folding it into the average.

Slices should be chosen from deployment risk, not from what the data happened to contain. Write down the two or three failure modes that would matter most in production and confirm that each has enough items to detect a change.

Hold-out hygiene and contamination

Items leak into training in ordinary ways: a public benchmark is reused by several teams, examples come from the same prompts that generated training data, or a supplier tunes prompts against the evaluation items. Ask how items were kept out, who had access, and whether the set informed a prompt or rubric change.

Two honest arrangements exist. A development set can be reported with the caveat that it informed tuning, alongside a blind set that only the buyer holds. Or the set stays frozen, which supports comparison over time but limits what the team can learn from it. Ask which applies and get it in writing.

Retiring an item is also a version change. A failed item that disappears between reports needs a recorded reason; otherwise the next score measures a different set.

The four versions in every reported score

A usable score names the model, prompt, dataset and scorer versions. Without them, two reports cannot be compared even when they describe the same task. Ask for a report template before the pilot starts and fill one example together.

The scorer deserves its own inspection. It may be a test suite, a state check, a rubric applied by reviewers or a model judge; each has a different failure mode. Request the scorer definition and a scored sample that includes rejected runs, not only the runs that passed.

Also ask what the buyer receives: items, gold labels, run logs and the ability to re-run the set in your own environment. Delivery of items makes an audit possible but exposes them to tuning; a buyer-held blind set is one workable compromise.

Acceptance checklist

Use this list when reviewing an evaluation set proposal, and pair it with the bounded pilot.

  • One written capability question that the whole set is designed to answer.
  • Validity, tool correctness and task success scored as separate dimensions.
  • Per-slice results with item counts, and small slices labeled as insufficient.
  • A documented hold-out process and a statement of any contamination risk.
  • Model, prompt, dataset and scorer versions named in the report.
  • A scored sample containing failures, plus the scorer definition or code.
  • A pass threshold agreed in writing before collection starts.
  • A named owner for ambiguous items and a log of their decisions.

Questions to ask a supplier

  • Which capability does each item test, and what end state counts as a pass?
  • How many items are in each slice, and which slices are too small to report?
  • Have these items been used for training or prompt iteration? How do you know?
  • What is the scorer — code, state check, rubric or model judge — and how was it calibrated?
  • Can we see a scored sample with failures and the reviewer notes behind them?
  • Who decides when an item is ambiguous, and where is that decision recorded?

Questions & answers

How large should an evaluation set be?
Size follows from the slices, not from a target total. Each slice needs enough items for a change in the score to mean something, and the report should give the count per slice. Ask the supplier to justify the slice sizes against your failure modes rather than quoting one overall number.
Can one supplier’s benchmark score be compared with another’s?
Usually not. A score is comparable only when the model, prompt, dataset and scorer match, and even then the harness and environment should be documented. Treat published scores as separate measurements until a supplier can show that the conditions are the same.
Should the evaluation set be delivered to the buyer?
Delivery supports audit and re-running but exposes the items to tuning. One workable arrangement splits the difference: a documented development set is delivered, and a blind buyer-held set stays with you. Decide which arrangement your program needs before the contract, not after.

Sources for this entry

  1. Editorial checklists on this site — Original guidance written for this reference. It describes what a buyer can check; it does not report test results.
  2. WebArena: a realistic web environment for autonomous agents — Public paper describing realistic web environments and reproducible evaluation of autonomous agents (not a ranked supplier).
  3. AgentBench: evaluating LLMs as agents — Public paper describing multi-environment evaluation of LLM agents (not a ranked supplier).

Editorial checklists on this site are original guidance. Links to official product documentation help readers understand the category; they do not establish comparative performance and are not endorsements of any supplier.

Ready to specify an evaluation set?

Send the capability question, the tools the agent may call and the failure modes you care about. We reply with clarifying questions and, where it fits, a short list of suppliers whose published scope matches the work.

Request a provider shortlist

Contact: contact@bestaiagenttrainingdata.com

Cite this entry

Best AI Agent Training Data. “Evaluation sets for agents.” Content reviewed .

https://bestaiagenttrainingdata.com/