Track 05 · EvalsLesson 04 of 10
Evaluating each step, not just the answer
Find where a multi-step agent goes wrong, tool call by tool call.
- Lesson library · reference
- 45 min read
- 75 min hands-on
- Pro
What you'll be able to do
01- Explain why grading only the final answer hides unsafe, lucky, wasteful and state-corrupting runs, with an example of each.
- Design a trajectory specification: required tools, argument matchers, order constraints, forbidden tools, efficiency limits and recovery rules.
- Implement a trajectory matcher and final-state checks against a sandbox seeded from golden-case fixtures.
- Isolate components (retriever, router, extractor, tool, guard) with fixtures, and attribute an end-to-end failure to the component that caused it.
- Use trace spans as the source data for span-, trace- and session-level evaluation.
- Evaluate multi-agent handoffs, and design a τ-bench-style user-simulation suite scored with pass^k.
Before you start
- The agent loop, written by hand: steps, budgets and stop reasons.
- Designing tools a model can use well: tool-level evals and what a good tool returns on error.
- Approval gates and bounded autonomy and Retries, fallbacks and failing gracefully: approvals and idempotency are what several checks here enforce.
- Supervisor, router or swarm? and Handing off to a person, well.
- Golden datasets and the metrics that matter (fixtures) and LLM judges and rubrics you can trust (judged trajectories).
The short version
An agent can produce a perfect reply after reading account data before verifying the customer, issuing a credit nobody approved, or creating the same dispute twice. A final-answer score gives all three full marks. Evaluate agents at three levels. The outcome: the final answer and, more importantly, the final state of the systems it touched. The trajectory: which tools it called, with which arguments, in what order, how efficiently, and how it recovered from errors. The components: retriever, router, extractor, tools and guards, each tested in isolation with fixtures so failures can be traced to an owner. Get the trajectories from trace spans. Match them against a specification using the loosest mode that still captures the requirement, with hard constraints (forbidden tools, precedence) checked separately. For conversational agents, simulate users, grade the final state and report pass^k, because customers get one attempt each.
- Outcome is state, not text. "Your case is created" is a claim; the case table is the fact.
- Constrain order with precedence rules, not exact sequences, unless the workflow is genuinely fixed.
- Forbidden calls and precedence violations are hard failures regardless of the final answer.
- Component evals tell you what to fix; end-to-end evals tell you whether it matters.
- Reliability is pass^k, not pass@1.
Pro lesson
The rest of this lesson is in Pro.
The mental model, worked example, field note, failure table, exercise and self-check, with the voice tutor.
- Every stage and specialisation, in full
- Every lab and every role project
- Halden weeks 2–10, on your record
- Every drill, live in the playground
- All solutions, plus the server judge
- Lab Assistant and every Teach with AI