Skip to content

All lessons

Area 04 // EvalsLesson 72 / 14014 min read

Agent evals: tool calls and trajectories

Agents are evaluated not only on their final answer but on how they got there, checking whether they called the right tools with the right arguments (tool call accuracy) and whether the whole sequence of steps was sensible, safe and efficient (trajectory evals).

Think of it like this

Analogy

A driving test doesn't just check that you arrived at the destination. The examiner watches how you drove: did you check your mirrors, signal at the right times, take a sensible route, and not run a red light? Arriving safely by luck after three near-misses is a fail.

Trajectory evals are the examiner watching the drive; tool call accuracy is checking each manoeuvre.

The problem it solves

An agent's final answer can look right while the run behind it was a mess: wrong tool first, wrong arguments, ten wasted steps, a call to a tool it shouldn't touch, or recovering only by luck. In production those messy runs cost money, fail more often on slightly different inputs, and occasionally do harm. You need to evaluate the path, not just the destination.

How it works: tool call accuracy

  1. For each test case, define the expected calls: which tools, with which arguments (exact values or rules like "city = Lisbon, nights between 1 and 30"), and sometimes which tools must not be called.
  2. Run the agent and collect its trace (tracing).
  3. Compare: was each expected tool called? With correct arguments? Were there extra or wrong calls?
  4. Score: tool call accuracy as correct calls ÷ calls made, plus "all required calls made" and "no forbidden calls".
  5. Use exact matching for structured arguments where possible; an LLM judge for fuzzy ones (search queries).

How it works: trajectory evals

  1. Look at the whole sequence of the run (trajectory): thoughts, tool calls, results and decisions.
  2. Check order and dependencies: did it look the data up before calculating? Did it ask for approval before acting?
  3. Check efficiency: steps, tokens, time and cost compared with an expected or best-known path.
  4. Check robustness: when a tool failed, did it recover sensibly or loop?
  5. Check safety: no forbidden actions, no leaking data between tools, respected permissions.
  6. Score with rules (exact sequences, step limits) and judges ("was each step reasonable given what the agent knew?").
  7. Run several times per case and report rates (passed 4 of 5), since agents vary.
  8. Combine with outcome evals: final answer correct, task completed, user goal met.
Three layers of agent evaluation, all scored from the trace.

See it in code

Needs
Nothing: plain Python 3. The trajectory is a recorded trace; real ones come from your tracing tool.

Scoring one agent run: right final answer, but one wrong call and a wasted step.

agent_eval.py
# Expected behaviour for one test task, and what the agent actually did (from its trace).
expected_calls = [("hotel_price", {"city": "Lisbon", "nights": 3}),
                  ("calculator", {"expression": "285 + 400"})]
actual_trajectory = [
    ("hotel_price", {"city": "Lisbon", "nights": 2}),    # wrong argument
    ("hotel_price", {"city": "Lisbon", "nights": 3}),    # corrected itself
    ("calculator", {"expression": "285 + 400"}),
    ("finish", {"answer": "685 GBP"}),
]
final_answer_correct = True
 
# TOOL CALL ACCURACY: were the right tools called with the right arguments?
actual_calls = [c for c in actual_trajectory if c[0] != "finish"]
correct = sum(1 for call in actual_calls if call in expected_calls)
print(f"tool call accuracy : {correct}/{len(actual_calls)} calls correct "
      f"({correct / len(actual_calls):.0%}), all expected calls made: {all(e in actual_calls for e in expected_calls)}")
 
# TRAJECTORY EVAL: judge the path, not just the destination.
names = [name for name, _ in actual_trajectory]
in_order = names.index("hotel_price") < names.index("calculator")
efficiency = len(expected_calls) / len(actual_calls)
print(f"right order        : {in_order}")
print(f"efficiency         : {efficiency:.2f} (expected steps / actual steps)")
print(f"final answer       : {'correct' if final_answer_correct else 'wrong'}")
Output
tool call accuracy : 2/3 calls correct (67%), all expected calls made: True
right order        : True
efficiency         : 0.67 (expected steps / actual steps)
final answer       : correct

An outcome-only eval would have scored this run perfect. The trajectory shows it misread "3 nights" at first: on a slightly harder question, that habit could produce a wrong answer.

A real example

Example

A travel agent that booked the wrong dates, sometimes

A travel-booking agent passed 92% of outcome evals. Trajectory evals over five runs per case showed something worse: in 15% of runs it called search_flights with the dates swapped and only recovered because the results looked odd. On real trips with fewer search results, it sometimes didn't notice and booked the wrong dates.

The team tightened the tool schema (separate departure_date and return_date, with validation that departure comes first), added a trajectory check for argument correctness, and the wrong-date rate dropped to nearly zero. Outcome-only evals had hidden a real production risk.

The easy way

Start here

For five typical tasks, write down the tools and arguments a good run would use. Run your agent five times on each, print the tool calls from the trace, and count: right tools? right arguments? how many steps? That's your first agent eval.

When you grow: the production setup

Teams store expected trajectories with golden cases, compute tool-call precision and recall, use judges for step reasonableness, track steps, tokens and cost per task, include adversarial and tool-failure cases, run multiple trials and report pass rates with variance, and gate releases on agent evals in CI (regression evals).

Trade-offs

What you gain

  • Catches inefficient, fragile and unsafe behaviour that outcome checks miss.
  • Points to the exact step (and tool or prompt) to fix.
  • Gives cost and step metrics alongside quality.

What it costs you

  • Needs good tracing and expected trajectories, which take effort to define.
  • Many valid paths can exist; overly strict expectations penalise good alternatives.
  • Multiple runs per case multiply eval cost.

When not to use it

  • Single-call features with no tools: ordinary output evals are enough.

Common mistakes

  • Evaluating only the final answer.
  • Requiring one exact path when several are valid.
  • Running each case once and trusting the result.
  • No tracing, so trajectories can't be scored.
  • Ignoring cost and step counts.

Interview questions

Try answering out loud first, then open the model answer.

How do you evaluate an AI agent?

Model answer

At three levels, from traces: outcome (task completed, final answer correct), tool use (right tools, correct arguments, no forbidden calls, measured as tool-call accuracy or precision/recall against expected calls), and trajectory (sensible ordering, efficiency in steps, tokens and cost, recovery from errors, safety and permission adherence). Use exact checks where possible and calibrated judges otherwise, run multiple trials per case, and gate releases on regressions.

What is a trajectory eval?

Model answer

An evaluation of the entire sequence of an agent's actions for a task, not just its final output: whether steps were appropriate and correctly ordered, arguments right, errors handled, unnecessary steps avoided, and constraints respected. It can compare against reference trajectories, apply rules (e.g. approval before payment), or use an LLM judge to assess each step's reasonableness.

Why do agent evals need multiple runs per test case?

Model answer

Agents are stochastic and path-dependent: small differences in sampling or tool results lead to different trajectories and outcomes. A single run may pass or fail by chance, so reporting pass rates over several runs (and variance) gives a reliable picture of behaviour and makes regressions detectable.

Quiz

Pick an answer to see whether it’s right and why.

  1. 01Why isn't checking the final answer enough for agents?
  2. 02What does tool call accuracy check?
  3. 03Which is a trajectory problem even if the answer is correct?
  4. 04Where does the data for trajectory evals come from?
  5. 05Why run each agent eval case several times?

0 of 5 answered

Key terms

Tool call accuracy
How often an agent calls the right tools with the right arguments, compared with the expected calls.
Trajectory eval
Evaluating an agent's whole sequence of steps for order, efficiency, recovery from errors and safety, not just its final answer.
Trace
The full record of one request or task, made of nested timed spans for every step it took.
Agent
A system where a model decides, in a loop, which tools to call and what to do next until a task is done.

Before and after

Read first

Read next

Progress is saved in this browser only.