Agent evals: tool calls, goals and trajectories

Why it matters

An answer is one output you can grade. An agent is a sequence of decisions: which tool, with what arguments, how many times, and when to stop. Two agents can reach the same correct result, one in three steps and one in forty with a loop that cost a dollar, and an answer eval scores them the same. Worse, an agent can finish the task and do something forbidden on the way. The interview question is "how do you evaluate the agent?", and the strong answer is that you evaluate the trajectory, not the final message.

The idea

Three levels of question

Tool-call accuracy: at each step, did the agent pick the right tool and pass the right arguments? Given a reference trajectory this is a code check: the tool name matches, the arguments match after normalisation of key order, whitespace and date formats. Agent goal accuracy: at the end, was the user's goal met? Not "did it answer" but was the ticket opened, the refund issued, the bug fixed; a judge given the goal and the final state decides, or a test does. Trajectory quality: was the path reasonable? Step count against the reference, loops, redundant calls, tokens and seconds spent, and whether a human would accept the route. Ragas names the agent metrics tool-call accuracy, topic adherence and agent goal accuracy; topic adherence asks whether the agent stayed inside the scope it was given.

Per-step versus end-to-end

A per-step eval freezes the history up to step n and asks whether the next action is right. It is cheap, deterministic and pinpoints the failing decision, but it only tests the paths in your reference. An end-to-end eval runs the whole task and judges the outcome; it catches recovery and alternative routes but cannot say which step went wrong. Use per-step for the decisions you care most about (the first tool call, the stop decision, the approval request) and end-to-end for the goal.

Simulated users and environments

Multi-turn tasks need a counterpart. A simulated user is a second model given a persona and a goal: "you want a refund, you do not know your order number, you get irritated after three questions." It talks to the agent until the task ends. A simulated environment is a sandbox with the real tools stubbed: a fake CRM, a disposable repository, a mock payment API that records calls. Together they let you run a hundred conversations per change without touching production. The simulator is itself under test: check on a sample that its conversations resemble real ones, or you are evaluating against an imaginary customer.

Evaluate the thread, not the call

Scoring each model call in isolation misses the failures that matter: the agent that asked the same question twice, the one that answered the wrong turn, the one that dropped the goal after a tool error. Score the whole thread: the inputs, every tool call and result, the final state. That is also what a trace is, which is why agent evals and observability share a schema.

Cost and safety as metrics

A trajectory has a budget: steps, tokens, wall time, money. Record each and gate on them, because an agent that gets the right answer at twice the cost is a regression. Safety checks are code: no call to a forbidden tool, no write outside the allowed scope, an approval requested before every irreversible action. One violation fails the case whatever the outcome.

Flakiness

Agents are more variable than single calls because variance compounds across steps. Run each case several times, five is common, and report a pass rate per case rather than one pass or fail. A case that passes three of five is flaky, and flakiness is a finding: the decision at that step is on a knife edge. Set the gate on the aggregate, and treat a case that falls from five of five to two of five as a regression even when the mean barely moved.

	Answer evals	Step evals	Trajectory evals	Simulated-user evals
What they catch	A wrong final message	A wrong tool or argument at a frozen point	Loops, cost, forbidden actions, dropped goals	Clarification, recovery and persistence across turns
Cost per case	One judge call	One model call per step tested	A full run, times the repeat count	A full conversation with two models, times repeats
Setup	Cases with checks	Reference trajectories	Sandboxed tools and budgets	Personas, goals and a validated simulator
Blind spot	Everything before the answer	Alternative routes	Which step went wrong	Real users behave differently