Agent Evals: Trajectory vs Outcome Scoring
Overview
Evaluating an agent based on the sequence of tool calls and actions it took (trajectory), not just the final text it returned (outcome).
Agents can arrive at the right answer through luck, hallucinations, or dangerous tool loops. Outcome evaluation hides these catastrophic failures.
Where used: Evaluating agent loops, Test suites for agentic applications, Continuous integration for LLM architectures
Why learn this
- Traditional LLM evaluation (input-to-output) fails when applied to autonomous agents.
- You cannot trust an agent in production if you only measure its final text string.
- Companies are shifting from pass@k to pass^k to truly measure reliability.
Code walkthrough
def evaluate_agent_run(trace_object):
# BAD: Outcome-only evaluation passes even if the path was chaotic
assert 'Booked' in trace_object.final_output
# GOOD: Trajectory evaluation inspecting the exact sequence
tool_names = [step.tool_name for step in trace_object.steps]
# A bad trace might be: ['search', 'search', 'hallucinated_api', 'book']
# We must explicitly forbid loops and hallucinations
assert len(tool_names) == 2, f'Expected 2 tool calls, got {len(tool_names)}'
assert tool_names[0] == 'search_flights'
assert tool_names[1] == 'book_flight'
# Assert the environmental impact actually occurred
assert db.get_flight_status() == 'Booked'Focus: Outcome evaluation only checks the final string ('Booked'), which would pass an agent that hallucinated 15 failed database queries before accidentally succeeding. Trajectory evaluation asserts the exact sequence of tools used and verifies the environment state. Helper names are placeholders — the control flow is the point.
Common mistakes
- pass@k proves reliability: If an agent achieves a high `pass@k` score, developers assume it is highly reliable. In reality, `pass@k` artificially inflates success by hiding catastrophic tool-loop failures. A positive outcome often hides a broken trajectory. `pass^k` (consistent success across `k` attempts) is the true measure.
- Exact-match JSON grading: Failing an agent because it formatted a payload with different whitespace (e.g., `{'price': 199.99}` instead of `{'price': 200}`) is brittle. Evaluation must score the sequence of actions and their ultimate environmental impact, not just strict string matching of the final JSON.
Recall questions
- A developer sees an agent output the correct final string 'Flight Booked', but ignores the trace showing the agent hallucinated 15 failed database queries before accidentally retrieving the right row. What evaluation failure does this highlight?
- What is the difference between pass@k and pass^k in the context of agent evaluation?
- Why is exact-match JSON grading a brittle way to evaluate agents?
Understanding checks
An agent evaluates a complex database query. It gets the answer right 1 out of 5 times. If we use `pass@5`, the score is 100%. If we use `pass^5`, the score is 0%. Which metric provides a safer evaluation for deploying this autonomous agent to production, and why?
`pass^5` is safer. Autonomous agents can cause harm or incur massive costs if they fail or loop infinitely 80% of the time. `pass^k` measures the required consistency.
Agents have compounding error rates due to their multi-step nature, meaning consistency is critical.
What is the flaw in this trajectory evaluation?
It checks the first tool call but doesn't limit or check the total number of tool calls. The agent could have hallucinated 50 tool calls after the first one before eventually outputting 'Success'.
Trajectory evaluation must ensure the agent didn't take unnecessary or dangerous steps, which requires validating the entire tool call sequence.
Practice tasks
Write a Trajectory Evaluator
Write a Python function `eval_trajectory(trace)` that takes a trace object (which has a `.steps` list of strings representing tool names). The function should return True only if the agent called 'search' exactly once, followed by 'execute' exactly once, and made no other tool calls.
Continue learning
Previous: Evaluation & Test Sets
Previous: Observability & Tracing