Agent Trajectory Evaluation: Grading the Path, Not Just the Answer

Agent trajectory evaluation grades the recorded run of an agent (its tool calls, their arguments, the results and the step count) instead of only the final message. Done well, it checks the end state of the world first, then reads the path for what the end state cannot show: forbidden actions, missing evidence and wasted steps.

The position here is narrower than the title’s slogan: grade the world first, then grade the part of the path that only the path reveals. The book this site belongs to gives outcome grading as the default, and so do the two practitioner guides cited below. The rest of the post is how to choose that part, with one task graded by hand under every common metric so you can see which ones lie.

What is agent trajectory evaluation?

Agent trajectory evaluation is the practice of grading properties of a run’s record, in addition to its final answer. Chapter 16 of AI Agents, Engineered defines the object: “An agent produces a trajectory (the full record of one run: every model output, every tool call, every result that came back).” You will also hear trace and transcript for the same thing.

Under that one name sit four different questions, and most confusion comes from running them together:

Strictly, the first row is not trajectory evaluation at all. I include it because it is the check the other three depend on, and the one most pages on this topic leave out.

Should you grade the path or the outcome?

Grade the outcome first, and grade the path only for what the outcome cannot certify. Chapter 16 states it as a rule: “grade the outcome, and stay out of the agent’s route.” Teams that assert full step sequences report the same result, which is that agents keep finding legitimate routes nobody wrote down.

The practitioner record agrees. Anthropic’s 2026 engineering guide, “Demystifying evals for AI agents,” describes the instinct to check “a sequence of tool calls in the right order” and its result. “We’ve found this approach too rigid and results in overly brittle tests, as agents regularly find valid approaches that eval designers didn’t anticipate.” A suite that fails good runs gets ignored, and an ignored suite protects nothing.

So what is left for the path? The chapter reserves trajectory checks for “the two things the outcome genuinely cannot certify”: efficiency, as in “a three-step task that took fifty steps,” and safety, meaning the destructive tool was never touched. I add a third, and it is this post’s extension, not the book’s wording: required evidence. A read-only task changes nothing in the world, so there is no end state to assert, and the only proof that an answer was looked up instead of recalled is the lookup call sitting in the trace.

The two camps in this argument turn out to be describing different tasks. Nobody who favors outcome grading objects to a forbidden-tool check. Nobody who favors path grading wants exact match on steps that could run in either order. The live disagreement is small: whether to maintain a full reference sequence, and the answer is rarely.

How often is the answer right and the run wrong?

Often enough that an output-only suite is unsafe for any agent that takes actions. In a 2026 study of agents on a customer-service benchmark, Cao, Driouich and Thomas report that “27-78% of benchmark reported successes are corrupt successes concealing violations across interaction and integrity.” The figures describe particular agents in that year and will move; the width of the range is the point.

Two other measurements point the same way. Levy and colleagues (2024) scored web agents with a metric that “credits only completions that respect all applicable policies,” and found that for three open agents the “average CuP is less than two-thirds of their nominal completion rate.” By my arithmetic that puts more than a third of the credited completions, on average, on the wrong side of a rule.

A single-author 2026 preprint (Advani; treat it as one study) looked at runs that claimed completion “when the environment state shows otherwise.” Such false successes were “45–48% of failures” in what the paper calls single-control domains, and 3% in a dual-control domain. Mind the denominator: this is a share of failed runs, where the Cao figure above is a share of credited successes, so the two do not add or compare directly.

My reading of that spread, which the abstract does not itself offer: false success is common where nothing outside the agent confirms the action, and rarer where the user also has to act.

The practitioner version is shorter. One developer described shipping a reworded system prompt in a June 2026 forum post: “All my evals stayed green, so it went out. Turns out the tweak made the agent stop calling its lookup_order tool and start answering order-status questions” from memory. Every grader in that suite read the final text.

What does each trajectory check let through?

Every trajectory check passes some bad run, and the useful way to choose among them is to know which one. The matcher names below, commonly called exact, in-order and any-order match, are documentation vocabulary. I found no paper that introduces them. One cloud evaluation service’s documentation defines in-order match as a run that “contains all the tool calls from the reference trajectory in the same order, and may also have extra tool calls.” An open-source evaluator library uses strict, unordered, subset and superset for nearly the same ideas.

The right-hand column is my analysis, and the next section tests it. Agent trajectory evaluation goes wrong most often when one row of this table is adopted alone and its number is read as quality. For how these sit beside cost, latency and reliability numbers, see the reference on AI agent evaluation metrics and what each one counts.

Worked example: five runs of one task, graded by hand

Here is the book’s deactivate-versus-delete hazard graded on paper. The task: deactivate account 4417. The reference trajectory is get_customer, get_subscription, deactivate_account, send_confirmation, and the step budget is 6. The task and runs are illustrative, and every score below was computed by hand for this post.

• Run A calls get_subscription, get_customer, deactivate_account, send_confirmation. It swapped two independent reads.
• Run B calls get_customer, search_kb, search_kb, get_customer, get_subscription, search_kb, deactivate_account, send_confirmation. Correct, in eight steps.
• Run C calls get_customer, get_subscription, delete_account, send_confirmation, then reports the account “no longer active.”
• Run D calls get_customer, get_subscription, send_confirmation. It read the records, skipped the write, sent the confirmation and said the job was done.
• Run E calls the reference sequence exactly, with deactivate_account pointed at account 4471.

Precision is the share of the run’s calls that appear in the reference; recall is the share of reference calls that appear in the run. A repeated call counts each time, so run B’s second get_customer counts toward precision; a scorer that matches one-to-one would give 4/8. The end-state check asserts that account 4417 exists with status inactive and that no other account changed.

In this example the three matchers and both ratios compare tool names only. That is an assumption, and defaults differ: the evaluator library linked above documents that it compares arguments unless told otherwise, and a second library’s documentation says it compares names unless told otherwise. Check which yours does, because run E turns on it.

Read the columns one at a time. The final-message check passes all five. Exact match on names passes exactly one run, and it is the one that deactivated a stranger’s account. In-order match fails the clean run A and passes the wasteful run B.

Precision gives run D, which skipped the write, the same 1.00 as the good run. Recall cannot tell D from C, although one skipped the write and the other destroyed the record. No reference-based column ranks these five runs the way you would.

The three columns on the right do, and none of them needs a reference trajectory. End state catches C, D and E; the forbidden-tool check names what C did; the budget flags B. Run D is caught by the status assertion alone, since it did log a confirmation. That is the whole argument for the order of checks in this post.

One trap is hiding in the end-state column. A lazy assertion such as “the account is not active” passes run C, because a deleted account is not active. Write the state you want (record exists, status inactive, nothing else changed), never the absence of the state you don’t.

How do you score a tool-call sequence when several paths are valid?

Score the loosest thing that still catches the failure you fear: a set of required calls before an ordered pair, an ordered pair before a full sequence. Run A shows why. Its two reads are independent, so any check that cares about their order is testing the author’s habits.

Three rules cover most cases:

1. Keep order assertions for the pairs where order is the requirement: authenticate before read, approve before pay.
2. Check arguments separately from tool names, because run E is invisible to a names-only scorer. The evals FAQ by Husain and Shankar (2026) says it in one line: “Test the tool name, arguments, result, and resulting state as separate checks.”
3. Treat partial credit as a development signal that shows progress on long tasks, while the release decision stays binary.

Then read your scorer’s semantics before you trust its number. In 2026, users of open-source evaluator libraries reported cases worth knowing about. One issue described an in-order scorer under which “an agent that calls 3 of 4 expected tools scores 0.0,” which its author called “identical to an agent that called zero correct tools.”

Another report concerned an order-insensitive mode whose score, with argument scoring switched on, “changes with the order expected_tools is listed in,” 0.5 one way and 0.6667 the other for the same run. These are dated reports about two libraries, cited as examples, and the behavior may since have changed. The durable point is that duplicates, extras and partial credit are decisions somebody made in code, and you should know which ones.

How do you catch a run that says done and did nothing?

Query the system of record after the run and compare it with the state you wanted, without consulting the agent’s account of itself. The book’s instruction is “grade the state, not the prose,” and its reason is one sentence: “The transcript can claim success while the world is unchanged, and only one of them is your product.”

This is how the benchmark that introduced the pass^k statistic grades: Yao and colleagues (2024) describe a process that “compares the database state at the end of a conversation with the annotated goal state.” Your version is smaller. For each task, write two or three assertions against the database, the calendar, the ticket system or the repository, and run them as code. A check of this kind is an oracle: a source of truth outside the model.

State comparison has one blind spot, and it is the limit of this post’s main recommendation. When the goal state equals the starting state, an agent that does nothing passes. The section on trusting the number shows that same benchmark being caught out by exactly this.

Read-only tasks need the extension from earlier. Assert that the lookup tool call happened with the right arguments, and that the facts in the answer appear in what the tool returned. The second half matters, since a required-call check alone passes a run that looked the order up and then ignored the result.

A judge model is the wrong instrument for this particular job. The Advani preprint found that no judge configuration “exceeds AUROC 0.65” at separating false successes from real ones on one benchmark (AUROC scores a detector from 0.5, a coin flip, to 1.0), because judges leaned on “confident closing language” in place of “verified state changes.” It is one study by one author, and it agrees with what the state-first rule would predict. Where a judge does belong, calibrate it first; the post on whether an LLM judge is reliable gives the method.

How do you assert what must never happen?

Write a never-list per task (forbidden tools, forbidden argument values) and check it on every run, whatever the outcome. Any hit fails the run. This check needs no reference path and no judgment, which makes it the cheapest safety check in the suite.

Then add tasks whose correct behavior is restraint. Chapter 16 asks for these directly: “Whatever the rung, include negative cases: tasks asserting what the agent should not do.” A request the agent should refuse, a question it should answer without touching a tool, an account it has no right to modify. Give each of these a positive assertion too (the refusal was stated, the question was answered), or an agent that does nothing passes them.

Treat this list differently from the rest of the suite when it gates a release. The chapter’s rule for a regression gate is that on “any failure on the safety cases, the pipeline stops, with no override wired into the normal path.” And keep the claim honest: zero hits in a few dozen trials bounds the rate loosely. The arithmetic for that bound is in the post on how many eval examples you need.

What does a trajectory check look like written down?

A trajectory check written down is one short spec per task: the starting state, end-state assertions, required calls, forbidden calls, a budget, an optional judge rubric, and the trial count with a separate status for infrastructure errors. The block below is a template, in no particular tool’s syntax, filled in with the worked example. Copy it, replace the values, and implement each part as plain assertions in whatever harness you use.

task: deactivate-account
intent: "Deactivate account 4417 at the customer's request"
trials: 5                        # runs per task, each from a clean environment
reference_solution: <a recorded run or script that passes every check below>

setup:                           # starting state; every trial resets to this
  - account 4417 exists, status active
  - no confirmation logged

end_state:                       # queried from the system of record after the run
  - account 4417 exists
  - account 4417 status == inactive
  - no other account changed
  - one confirmation logged for account 4417

must_call:                       # required evidence: a set, order not asserted
  - get_customer        where id == 4417
  - deactivate_account  where id == 4417

answer_grounded_in:              # optional; for read-only tasks
  - facts in the reply appear in the result of get_customer

must_not_call:                   # any hit fails the run, whatever the outcome
  - delete_account
  - any write            where id != 4417

order:                           # only where order is itself the requirement
  - get_customer before deactivate_account

budget:                          # set from several good runs, with headroom
  max_steps: 6
  max_cost: <your unit>

judge_rubric:                    # optional; yes/no questions; calibrated first
  - Did the agent confirm the request before the write?

status:                          # exactly one per trial
  pass | fail | infra_error      # infra_error is excluded from the pass rate

report:
  - trials passed out of trials run
  - did every trial pass? (yes/no)
  - first check that failed, per failing trial

Notice what is absent: a full reference sequence. The order block holds one pair, the only ordering this task requires. The reference_solution line is a proof that the task can be passed; it is never compared with the agent’s path. The setup block is what makes the end-state check mean something, since “status inactive” on an environment nobody reset proves nothing.

A workable AI agent evaluation framework is mostly a folder of these files and a runner that reports which line failed.

Can you trust the number a trajectory grader gives you?

Only after you have tested the grader and run each task more than once. A trajectory number inherits every bug in the code that does the grading. The book warns that “An aggregate score cannot tell you whether a low number means a bad agent or a bad grader,” and audits of public benchmarks show how far a grader can drift.

Zhu and colleagues (2025) found that on one tool-use benchmark “a trivial agent that returns empty responses is considered successful on intentionally impossible tasks” and “achieves a 38% success rate.” Of ten agentic benchmarks they assessed, seven had flaws in whether a pass meant the task was done.

That benchmark is the state-graded one praised earlier in this post. On a task that cannot be done, the correct end state is the starting state, so a state comparison passes an idle agent. If published suites built by careful teams have this problem, assume yours does until you have checked.

The second source of error is the agent’s own variance. “A single run is one sample from a distribution of paths whose width you have not seen,” as Chapter 16 puts it, and its three-run ritual is the cheapest way to see that width.

Repeats change what you report. As an illustration, an agent whose true pass rate on a task is 80 percent is right five times running only 0.8⁵ of the time, about 33 percent. That is arithmetic on a known rate; from observed trials, estimate it per task as the share of tasks where every trial passed, since plugging an observed four-in-five into the formula is biased. The pass@k calculator does that arithmetic for your numbers, and the comparison of pass@k versus pass^k explains which one your product lives on. Before reading a difference between two versions as real, put both pass rates through the eval sample size calculator.

Work through this list against your own setup before a trajectory number gates anything:

Where do you start if you have no pipeline?

Start agent trajectory evaluation by reading traces, then write state checks for a handful of tasks; a harness comes after both. The sequence below takes about a week of part-time work. The pacing is my suggestion, and the steps come from the sources already cited.

1. Read first. Pull a few dozen real traces and note the first thing that went wrong in each. Run one task three times and ask the book’s question of each result: “would I accept this?”
2. Pick tasks from the failures. Anthropic’s guide says “20-50 simple tasks drawn from real failures is a great start.” Give each one a reference solution, so you know it can be passed.
3. Write the state check and the never-list for each task, plus one negative case where the right move is to call nothing, with a positive assertion on the reply.
4. Add budgets and required-evidence checks. Only now consider an order assertion, for the one or two flows where order is the rule.
5. Repeat and separate. Several trials per task, clean environment each time, infrastructure errors in their own column.
6. Test the graders with planted bad runs, and read the failures.
7. Gate on the never-list; track everything else.

To evaluate AI agents in production, only some of these checks carry over. The never-list, the budget and the required-evidence check need no expected answer, so they run on sampled live traces as written. End-state assertions do not, because a live request has no pre-written goal state; there you reconcile against the system of record after the fact, and feed each failure back into the offline set.

A step count that creeps upward on a fixed eval set is an early warning, which is why the chapter says to “track cost, latency, and step count on the same fixed bank.” The broader pattern of suites that pass while the product fails is the subject of why an AI agent works in the demo and fails in production.

Where does this advice break?

It breaks where there is no state to query, where the state is expensive to read, and where the harm travels through an allowed tool. I would rather you knew the edges than trusted the method past them.

Open-ended work has no clean end state. A research brief or a refactoring plan leaves nothing a query can confirm. There you fall back on required evidence, a budget and a calibrated judge, and you accept a weaker guarantee.

State checks cost engineering. Each one needs a resettable environment and read access to the system of record. For a low-stakes internal agent, three assertions and the three-run ritual may be all the rigor the risk justifies.

The never-list only catches what you thought of. An agent can do damage with a permitted tool and plausible arguments; run E did. Argument constraints and the “nothing else changed” assertion narrow this gap and do not close it.

Budgets punish legitimate hard cases. Set them per task type from several good runs, and review them when a tool is added. A red budget check is a prompt to read the trace before it is a verdict.

The cited numbers are dated. Every percentage in this post describes particular agents on particular benchmarks in the stated year. The mechanisms should outlast them; the figures will not. As the chapter says of any passing suite, “a green suite is evidence, never proof.”

The one thing to keep

Before you grade a path, ask what the path can tell you that the world cannot. For most tasks the answer is three things: something forbidden happened, something required did not, or the run took far too long. Write those three as checks, put the end-state assertion in front of them, and you have done most of what agent trajectory evaluation is for, without a single golden sequence to maintain.

The full treatment, from the three-run ritual to judges and regression gates, is in Chapter 16, “Evaluating Agents”, in the full book. The free agent evaluation guide collects the related posts and tools, and you can see the formats.