Evaluating agents
An agent takes many steps, calls tools that change things, and can reach the same goal by different routes. A list of questions with expected answers can't tell you whether it is safe. This lesson shows how to test an agent with golden tasks in a sandbox store, check both where it ended up and how it got there, run every task several times, and turn the results into a gate for Ama's five-store pilot.
By the end you can
- Write golden tasks: a seeded starting situation, a request, and checks
- Build a sandbox of fake tools so evals never touch a real store and give the same inputs every run
- Write outcome checks on the end state and trajectory checks on the trace, without demanding one exact path
- Run each task k times and read pass@1, all-k pass, steps and cost per category
- Turn failures into fixes and new cases, and set a gate for a pilot
The everyday picture
Think of a driving test. The examiner doesn't hand the learner a list of turns and fail her for taking a different street. She checks a few things that matter: did you reach the car park and stop inside the bay, did you check your mirrors before every lane change, did you ever go through a red light. Many routes pass. One red light fails, however good the rest of the drive was.
The first lessons happen on a closed practice yard, where a mistake hurts nobody and every learner meets the same cones. And one good drive proves little. An instructor who sees you drive well five times in a row trusts you more than one who saw a single lucky drive. Agent evals work the same way: a sandbox yard, a check on where the agent ended up, rules about how it drove, and several attempts at every task.
Why agent evals are different
In Evals: knowing if it got better and Evals: measuring AI quality you learned to test single answers: a golden set of questions, code assertions, a calibrated model grader and a gate in CI. Keep all of that. An agent adds four problems that a list of question-and-answer pairs can't see.
- Many steps. Ama's request "the yoghurt shelf is empty but stock says 40, get it recounted by Friday" takes a stock look-up, maybe a delivery look-up, a task, and a reply. A wrong answer can come from any step.
- Side effects. The agent creates tasks and asks other stores for stock. A good-sounding reply after the wrong transfer is still a failure. You have to look at what changed as well as at what it said.
- Many valid paths. One run checks deliveries first, another checks stock first. Both can be right. A test that demands one exact sequence fails good runs and teaches you nothing.
- Randomness compounds. If each step is right 98% of the time and a task needs 8 steps, the whole task is right about 0.988 ≈ 85% of the time, if the steps fail independently. Long tasks fail more, and the same task can pass on Monday and fail on Tuesday.
So an agent eval has a different unit. You keep a set of golden tasks instead of golden answers, you check two things for each run, and you run each task more than once. The rest of this lesson builds each of those pieces for the operations assistant you have been building since What makes an agent.
Quick check
An agent's task needs 8 tool steps, and each step is right 98% of the time, independently. Roughly how often is the whole task right?
Every step has to go right, so the chances multiply: 0.98 to the power 8 is about 0.85. Some agents do recover from a bad step, but you can't count on it without measuring it, and "a coin toss" ignores the numbers you have.