Evaluating a single LLM call is comparatively simple: you have an input, an output, and some notion of a correct or acceptable output to compare against. Automated metrics (exact match, ROUGE/BLEU for text similarity) or an LLM-as-judge comparing against a rubric can usually get you a workable signal.

An agent breaks this model. A single user request might trigger ten tool calls, three reasoning steps, and a final answer — and the final answer can be correct even though the agent took an inefficient, wasteful, or lucky path to get there, or incorrect even though every individual reasoning step was locally sound. Grading only the final output throws away most of the information about whether the agent is actually working well.

What actually needs to be measured

A thorough agent evaluation looks at several distinct dimensions, not just one pass/fail signal:

Task success — did the agent ultimately accomplish what was asked? This is the outcome-level metric most similar to single-call evaluation.

Trajectory quality — was the sequence of steps the agent took reasonable? Did it call the right tools, in a sensible order, without unnecessary detours or redundant calls?

Tool-use correctness — did each individual tool call have valid, well-formed arguments? Did the agent correctly interpret each tool's output before acting on it?

Efficiency — how many steps, tokens, and dollars did it cost to reach the result? Two agents that both succeed can differ by 10x in cost.

Robustness — does the agent recover gracefully when a tool fails, returns an error, or gives an unexpected result, rather than giving up or hallucinating a result?

Trajectory evaluation in practice

Trajectory evaluation means scoring the full sequence of Thought/Action/Observation steps an agent took, not just its final output. There are a few common approaches:

Exact-match trajectory comparison — for tasks with a known correct sequence of tool calls, compare the agent's actual calls (name and arguments) against a reference trajectory. Rigid, but useful for well-defined tasks like "book this specific flight" where the correct steps are known.

LLM-as-judge over the full trace — feed the entire Thought/Action/Observation transcript to a separate LLM along with a rubric ("did the agent use tools appropriately? did it avoid unnecessary steps? did it correctly interpret each result?") and have it score the trajectory. More flexible than exact match, but inherits the known weaknesses of LLM judges — inconsistency, susceptibility to verbose-sounding-but-wrong reasoning.

Step-level annotation — a human (or a judge model) reviews individual steps and flags specific failure points: wrong tool selected, misread observation, redundant call. Slower to run but gives the most actionable debugging signal.

json

Note

Task-success-only evaluation systematically overrates agents that get lucky. An agent that misreads a tool result but happens to land on the right final answer anyway will look identical to a genuinely reliable agent if you only check outcomes. This matters most for safety-relevant or high-stakes tasks, where you need to know the agent's process was sound, not just that this particular run turned out fine.

Benchmarking and test design for agents

Good agent test suites share a few properties:

Deterministic or near-deterministic environments. If the tools an agent calls return different results every run (a live web search, a flaky API), it's very hard to tell whether a failure was the agent's fault or the environment's. Many agent benchmarks use mocked or sandboxed tool environments with fixed, reproducible responses.

Graded difficulty. Easy tasks (1-2 tool calls) catch basic regressions; hard tasks (10+ steps, ambiguous instructions, tools that occasionally fail) catch the failure modes that only show up under real production stress.

Held-out and adversarial cases. Include tasks designed to tempt the agent into a known failure mode — a tool that returns a plausible-looking but wrong result, an instruction that's subtly ambiguous — to specifically test robustness, not just the happy path.

Single-call eval vs. agent eval

Dimension	Single LLM call evaluation	Multi-step agent evaluation
What's scored	One input -> one output	A full sequence of reasoning, actions, and observations
Main failure signal	Wrong or low-quality output	Right output via a broken process, or wrong output despite sound steps
Reproducibility	High — same input, same prompt	Lower — depends on tool/environment determinism across the run
Cost of running evals	Low, one call per test case	High — many calls per test case, scales with trajectory length
Common tooling	Exact match, similarity metrics, single-shot LLM judge	Trajectory judges, step annotation, sandboxed tool mocks

Note

The real value of trajectory-level evaluation isn't the aggregate score — it's the specific failure points it surfaces. An eval suite that tells you "73% task success" is far less useful than one that tells you "the agent consistently misreads paginated search results on page 2 onward." Design evals to produce that second kind of signal, not just a headline number.

What's next

Good evals matter not just for correctness but for cost — and cost is dominated by how many LLM calls an agent makes and how much context each one re-sends. The next lesson covers prompt and context caching, one of the most effective levers for cutting agent API cost and latency without changing behavior.

I build these systems professionally.

Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.

Work With Me →

Need production AI or MarTech expertise? I build custom LLM workflows, server-side GTM tagging, and analytics infrastructures professionally.

Need custom AI or MarTech setup? Let's build together.

Let's talk →