Asked about Evaluating agents and multi-step systems
How would you evaluate a customer support agent that can issue refunds?
An answer that works
Build tasks in a sandboxed copy of the systems it touches, and grade the end state: the right order changed, nothing else changed, the refund amount is correct. Separately check tool calls in the trace and have a validated judge assess the reply. Run each task several times and report both per run success and the share of tasks that pass every time.
Then they push further
It passes 85% of runs. Is it ready to ship?
Not on that number alone. I would want the all-runs-pass rate, which could be far lower, the failure modes of the 15%, and whether any failure is costly, such as refunding the wrong order. A system that fails harmlessly at 15% may be fine; one that occasionally issues wrong refunds is not.
How do you stop the eval from teaching the agent to game the checks?
Keep a held-out task set nobody tunes against, check side effects as well as the target change so shortcuts are caught, and read a sample of passing traces, not just failing ones.
What gets marked up
Strong answers grade the resulting state rather than the transcript, mention repeated runs, and bring up the cost of each failure type. Weak answers describe only an LLM judge reading the conversation.
Reading an answer is not being able to give one. The section that teaches this is Evaluating agents and multi-step systems, 5 hours of Evaluation.
Learn this properlyAlso asked about Evaluation