What to Put in Your First Agent Evaluation Dataset

Shashank Agarwal

Your first evaluation dataset should expose the decisions you need to make about an agent. A large collection of unrelated conversations can be harder to interpret than a small, reviewed set with clear expected behavior.
Quick answer: Begin with representative tasks, previously observed failures and important boundary cases. For each item, preserve the task, appropriate source evidence, expected behavior, required check inputs and selection method. Keep routine cases alongside difficult ones, and report missing evidence separately from a failing answer.
Give each case a job
For an illustrative article-summary agent, a starting set could include these case types:
| Case type | Decision it tests |
|---|---|
| Accessible article with complete content | Can the agent produce a supported summary? |
| Extractor returns an empty body | Does the agent report missing content? |
| Returned page is unrelated | Does it notice the source mismatch? |
| Page contains navigation but little article text | Does it confuse page chrome with the requested content? |
| Source contains an explicit uncertainty | Does the summary preserve that uncertainty? |
| Tool request fails | Does the assistant avoid inventing a result? |
These categories are proposed fixtures, not observed service-performance statistics.
Store the evidence the check needs
A case title such as “bad summary” is not enough to reproduce a judgment. Retain the user task, relevant captured content and actual response. Add a reviewed reference when the chosen check needs one. Record the source or fixture version so a later run does not silently use different material.
Keep sensitive data handling deliberate. A synthetic fixture can often reproduce a parsing or routing failure without retaining an entire customer conversation. When a case comes from production, preserve its origin and the transformations applied to it.
Microsoft’s evaluation checklist recommends defining test cases around the agent’s core scenarios. The table here applies that idea to extraction and summarization, where unavailable content is a different condition from an inaccurate summary.
Preserve the selection method
Record why an item entered the set: ordinary traffic sample, reported incident, adversarial exercise or a deliberately constructed boundary. Those categories serve different purposes.
A failure-focused set helps prevent known regressions. Its failure rate is not automatically the failure rate of production traffic. Keep a representative slice if the intended report concerns ordinary usage, and state the denominator.
Check the dataset before blaming the agent
Inspect input mapping, missing fields and contradictory expected answers. If one case’s source is obsolete, correcting that case is different from improving the application. Preserve both changes in the comparison record.
I’m Shashank Agarwal, founder and CEO of Noveum AI and creator of API.market. In an evaluation workflow, prepared items should make the check’s question inspectable. See the workflow walkthrough for preparation and the monitoring guide for connecting results to captured operations.
Follow my work on LinkedIn. Drafted with AI assistance.
Get Early Access to Noveum.ai Platform
Join the select group of AI teams optimizing their models with our data-driven platform. We're onboarding users in limited batches to ensure a premium experience.