Most teams evaluate their first agent the way they evaluated everything before it: they look at the final answer and decide whether it is good. For a single LLM call, that works well enough. For an agent, it hides almost everything that matters. An agent can return a correct answer after taking a reckless path, calling the wrong tools, burning ten times the budget it needed, and getting lucky on the last step. Score only the output and you would call that a success. The next time the luck runs out, the same agent fails in production and nobody can explain why.
AI agent evaluation is the discipline of judging the whole trajectory: the sequence of decisions, tool calls, and recoveries an agent makes on its way to a result. It is one of the fastest-growing skills in AI product work right now, and it is also one of the least understood. This article lays out why output-only evaluation breaks for agents, what to measure instead, the techniques that work in practice, and the honest signal that tells you when the evals you have been running are no longer enough.
It is written for Product Managers and quality professionals who already understand evaluation for simple LLM features and need to extend it to systems that act over multiple steps.
Why scoring the final answer breaks down
A single-shot LLM feature has one input and one output. You can build a dataset of inputs, define what a good output looks like, and score the model against it. The evaluation surface is small and the failure modes are visible.
An agent changes the shape of the problem. Between the goal and the result there is now a process: the agent reasons about a next step, picks a tool, reads what comes back, decides again, and repeats. The same goal can be reached through a clean three-step path or a chaotic fifteen-step one. Two runs on the identical input can diverge completely. The final answer tells you where the agent landed and says nothing about how it got there or whether it will get there again.
This matters for three concrete reasons. The first is reliability: an agent that succeeds by luck will fail when the conditions shift, and output scoring cannot distinguish luck from competence. The second is cost: a path that calls a tool eight times when two would do is a real expense at scale, invisible to anyone looking only at the answer. The third is debugging: when an agent fails, you need to know which step broke. A pass-or-fail verdict on the output gives you nothing to act on.
What to actually measure
Evaluating an agent well means scoring several dimensions of the trajectory, each answering a different question.
Goal completion is the first and most obvious: did the agent achieve what it was asked to do? This is the closest to traditional output scoring, and on its own it is the weakest signal. Keep it, and never let it stand alone.
Path quality asks whether the sequence of steps made sense. Did the agent choose a reasonable approach, or did it wander, backtrack, and stumble into the answer? A reasonable path on a hard task is worth more than a lucky shortcut, because the reasonable path generalizes and the shortcut does not.
Tool-use correctness looks at each action the agent took. Did it select the right tool for each step? Did it call it with sensible arguments? Did it call tools it did not need? Wrong tool selection is one of the most common agent failures, and it is completely invisible if you only read the final text.
Error recovery is where agents reveal their real maturity. Things fail mid-trajectory: an API returns an error, a search comes back empty, a tool gives a malformed result. A strong agent notices, adjusts, and finds another route. A weak one loops, ignores the failure, or charges ahead on bad data. How an agent behaves after something goes wrong predicts production behavior better than any clean-run success.
Efficiency ties it together: how many steps, how many tokens, how much wall-clock time, how much money. Two agents that both reach the goal are not equal if one costs five times as much. Efficiency is a first-class quality dimension for agents, and it belongs in the eval from day one rather than as an afterthought when the bill arrives.
Techniques that work in practice
Trajectory evaluation is the core method. Instead of scoring only the endpoint, you capture the full trace of the run (every reasoning step, tool call, and observation) and evaluate that trace. The trace is the unit of analysis. Everything else builds on having it logged and readable.
Reference trajectories help when a task has a known good path. You define what a competent run looks like (which tools, in roughly what order, with what kind of intermediate results) and compare the agent's actual run against it. This works well for bounded tasks with a clear method and less well for open-ended ones where many paths are valid.
LLM-as-judge extends naturally to trajectories. A capable model reads the full trace and scores it against a rubric: was the plan sound, were the tools used correctly, was the recovery appropriate. The same discipline that applies to judging single outputs applies here, including its risks. An unvalidated judge is an opinion dressed up as a measurement, so a judge scoring trajectories has to be calibrated against human judgment before you trust its numbers, and watched for the usual biases like preferring longer traces or anchoring on familiar patterns.
Component scoring breaks the trajectory into the dimensions above (goal, path, tools, recovery, efficiency) and scores each separately rather than collapsing everything into one number. A single aggregate score hides which part is failing. Separate scores tell you where to fix.
Across all of these, the foundation is the same as for any serious evaluation practice: a representative dataset of cases, including the messy and adversarial ones, scored systematically rather than by eyeballing a few demos. The deeper discipline of building those datasets, reading outputs into a failure taxonomy, and calibrating judges is the broader practice of AI evals, and it sits underneath the product decisions covered in Agentic AI for Product Managers: When to Use It.
A concrete example
Take a research agent that, given a company name, gathers public information and produces a one-page brief. It has three tools: web search, a page reader, and a summarizer.
Score only the output and you read the brief, judge it accurate, and move on. Score the trajectory and a different picture appears. On one run, the agent searched, read four pages, and summarized: a clean path. On another run with a harder company, it searched, got thin results, searched again with the same query (a wasted step), read a page that errored, ignored the error, read two more, and summarized from incomplete data. The brief looked fine because the model wrote fluently around the gaps. The trajectory showed the agent never recovered from the empty search and never noticed the failed page read.
That second trajectory is a production incident waiting to happen. Output scoring would have shipped it. Trajectory evaluation surfaces the real problem: the agent has no handling for thin search results and no awareness of failed tool calls. Now you have something specific to fix, a guardrail to add, and an eval case that will catch the regression if it returns.
When your current evals stop being enough
There is an honest moment in every agent evaluation effort when the techniques you have been using stop covering the system you have built. It is worth naming the signals.
When an agent's valid paths become genuinely diverse, reference trajectories stop working, because there is no single right path to compare against, and you have to lean on rubric-based judging of whether a path was reasonable rather than whether it matched. When you move from a single agent to multiple coordinating agents, evaluation gets harder again: a failure now lives somewhere in the interaction, and you have to attribute it to the coordinator, a subagent, or the communication between them. When the agent runs in production against real users, controlled test sets stop being enough on their own, and you need continuous monitoring, sampling of real trajectories, and regression detection when a prompt or model changes underneath you.
Recognizing these thresholds is itself a skill. Teams that miss them keep applying an evaluation method that quietly stopped measuring the right thing, and they regain confidence they have not actually earned.
Closing
Agents will not be reliable because the underlying models got better. They will be reliable because the teams building them learned to see the whole trajectory and to measure it. Output scoring is comfortable and familiar, and for agents it is a trap that rewards luck and hides cost. The shift to trajectory evaluation is what separates an agent that demos well from one that survives real use.
If you want to build this practice with hands-on work on a real case, the AI Evals program covers exactly this arc, from building test datasets and failure taxonomies through deterministic and LLM-as-judge evaluation to a dedicated session on evaluating agents by their full trajectory and operating evals in production. It is built for two profiles that meet on the same ground: PMs who need quantitative judgment for shipping decisions, and testers moving into AI Quality. If your focus is the product and design side of agentic systems more broadly, the Certified Agentic AI Product Manager program covers agent evaluation alongside design, guardrails, governance, and cost, with evaluation treated as a core deliverable rather than a final check.