Grading the Trajectory: Evals for Long-Horizon Agents

Two runs of the same agent both end in the correct state. One got there by reading a record, checking a permission, and making a single scoped write. The other tried nine things, wrote to a production table it should not have touched, and got lucky. A single pass/fail label rates them identically.

For anything that runs more than a couple of turns, the path is part of the result. Evaluation has to look at the trajectory, not just the destination.

Score the workflow in layers

Break the run into stages you can grade independently: did it understand the task, was the plan sound, did it pick the right tool, were the arguments valid, did it track state correctly, did it recover from failures, did it verify before declaring done, and did it explain itself to the user honestly.

Layered scores tell you where a regression came from. An aggregate score tells you only that something got worse — and then you spend two days finding out whether it was the model, the tool layer, the context assembly, or a policy change someone shipped on Tuesday.

• Completion: did the requested outcome actually happen in the real system?
• Safety: were permissions, approvals, and data boundaries respected throughout?
• Efficiency: how many turns, tokens, retries, and external calls did it consume?
• Recovery: did it detect and correct tool or environment failures on its own?
• Evidence: can a reviewer verify the final claim from recorded artifacts alone?

Build a set that reflects your traffic

The natural instinct is to build an eval set from cases the system already handles, because those are the ones you have clean examples of. That produces a suite that passes forever and predicts nothing.

Include the ordinary work, the edge cases, the genuinely ambiguous request, the case where access is missing, the one with stale data, and the one containing adversarial content. Weight it toward your actual distribution. If a fifth of production requests are ambiguous, a fifth of your eval set should be too.

Watch for cost regressions dressed as quality wins

A change that raises completion by taking twice as many turns is not automatically an improvement — it may have just moved money from the quality column to the infrastructure column. Track efficiency alongside correctness in the same report so the tradeoff is visible at decision time rather than at the end of the billing cycle.

Keep humans in the loop

Automated graders give you coverage and speed. Domain reviewers catch the subtle wrongness and the shifting business expectations that no rubric anticipated. Use both, look hard at cases where they disagree — that disagreement is usually where your rubric is wrong — and promote every newly discovered failure into a permanent regression case.