Evaluating agents: trajectories, tool accuracy and reliability

In this article

1. Before you start
2. Why interviewers ask this
3. Evaluating agents from first principles
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

Why interviewers ask this

Agent evaluation is asked about because accuracy on a final answer hides most of what goes wrong in an agent. A weak answer proposes "check whether the final answer is correct" and stops. A strong answer separates the outcome from the path, names the metrics for the path, explains why one run proves little, and says how to keep the test set honest as the agent changes.

The question appears in applied machine learning (ML) and AI engineering rounds, for example as "how would you evaluate a customer-support agent" or "how do you know your agent got better". The AI agents guide lists the neighbouring design questions, and retrieval-augmented generation (RAG) evaluation covers the retrieval-only case.

Evaluating agents from first principles

Agent trajectory

An agent trajectory is the ordered record of everything an agent did on one task, meaning each reasoning step, tool call with its arguments, and tool result, ending in a final state.

Tool-selection accuracy

Tool-selection accuracy is the share of an agent's tool calls that use a tool that the reference path or rubric allows. The reference path is the list of tool calls a correct run would make, in order.

pass^k

The pass^k metric is the chance that an agent succeeds on all of k independent trials of the same task, averaged across tasks, so it measures consistency rather than best-case success.

In plain words

Think of a driving test. Arriving at the destination is not enough. The examiner also watches the route, the signals and whether you would pass the same test on another day. Agent evaluation has the same three parts: where the agent ended, how it got there, and how reliably it repeats. The analogy breaks in one place. A driving examiner needs only one session per candidate, but an agent's output varies from run to run, so one run is a weak sample.

Stated precisely, agent evaluation compares an agent's final state and its trajectory with a reference, over many tasks and many runs. A benchmark is a fixed set of tasks with a scoring rule, so that different agents can be compared. The survey by Yehudai et al. describes the field as moving toward more realistic, continuously updated benchmarks. It flags gaps in assessing cost-efficiency, safety and robustness (Yehudai et al., 2025).

Step 1: Define the task and the goal state

The first step fixes what success means before any run. The input is a task description plus the tools and rules the agent has; the output is a written goal state. A goal state is the condition of the world, such as a database record, that counts as the task being done. In tau-bench, success is judged by comparing "the database state at the end of a conversation with the annotated goal state", and it also checks that the agent's replies contain the required information (Yao et al., 2024).

The agent is given domain policy rules, which that check does not fully verify. Checking a state, such as a booked flight, is sturdier than reading the agent's last message, because the message can sound right while the state is wrong. What you now know: a task is paired with a checkable goal state.

Step 2: Score the outcome

The second step scores where the run ended. The input is the final state; the output is a pass or fail for the task. For software tasks the check can be a test suite: SWE-bench asks a model to edit a codebase so that real GitHub issues from 12 Python repositories are resolved, and judges the result by tests (Jimenez et al., 2023). Outcome is the metric that matters to a user, and it is cheap to automate where a state or test exists. It says nothing about cost, safety or luck. What you now know: outcome is one binary number per run.

Step 3: Score the trajectory

The third step scores the path. The input is the recorded trajectory and a reference path or rubric; the output is several numbers. Tool-selection accuracy asks whether each call used the right tool. Argument validity asks whether the arguments were correct. Step efficiency divides the reference length by the agent's length. These three are common practice rather than one paper's standard, so name them in an answer as your own definitions. AgentBench, which spans 8 environments, names poor long-term reasoning, decision-making and instruction following as the main obstacles (Liu et al., 2023), which show up in the path more clearly than in the final answer. What you now know: the path is scored separately from the end.

Step 4: Repeat the run and report pass^k

The fourth step measures reliability. The input is n trials of each task; the output is pass^k, the chance that all k trials succeed. Yao et al. define it as "the chance that all k i.i.d. task trials are successful, averaged across tasks" (i.i.d. means independent and identically distributed), and show that even their best retail agent, with over 60% average success, dropped below 25% at k of 8 (Yao et al., 2024).

The estimate is the average over tasks of C(c, k) divided by C(n, k), where c is the number of successes in n trials and C(a, b) counts the ways to choose b items from a. Its mirror, pass@k (pass at k), is the chance that at least one of k trials succeeds. What you now know: one run is a sample, and pass^k exposes the spread.

1 · Task2 · Outcome3 · Trajectory4 · RepeatReplay

Step-by-step description

1. Write the goal state first.
2. Compare the final state.
3. Score tools, arguments, steps.
4. Report pass^k over runs.

• Define a goal state before any run.
• Score the outcome, then the trajectory.
• Repeat runs and report pass^k.

Worked example

Two small computations show the metrics. The first uses made-up trials (illustrative: no real agent was run), and it estimates pass@k as 1 minus the average of C(n − c, k)/C(n, k). Eight tasks are each run 8 times. Four tasks succeed in all 8 trials and four succeed in 4 of 8, so the mean success rate is 0.75. Then pass@1 and pass^1 are both 0.75. pass@2 is 0.8929 and pass^2 is 0.6071. At k of 8, pass@k is 1 because every task succeeded at least once, while pass^8 is 0.5 because only the four consistent tasks always succeed.¹ The tau-bench authors use the same pair of definitions and call pass^k the reliability view (Yao et al., 2024).

If runs are independent and a single run succeeds with probability 0.7 on every task, the chance of eight successes in a row is 0.7 to the power 8, which is 0.0576. If per-trial success rises to 0.9, the same eight in a row has probability 0.9 to the power 8, which is 0.4305, so a modest gain per run lifts pass^8 a lot.¹

Text description of the diagram

• Pass at k is 0.75 at k of 1 and 1 at k of 8.
• Pass^k is 0.75 at k of 1 and 0.5 at k of 8.

The second computation scores four illustrative trajectories against a three-call reference: look up the user, search flights, book the flight. Trajectory A matches the reference exactly. Trajectory B reaches the right state but makes 6 calls instead of 3, so its step efficiency is 0.5 while its outcome is still a pass. The outcome check is the final state: the booked flights must be exactly flight F2.

Trajectory C looks up the user, then searches hotels and books a hotel, so no flight is booked: tool-selection accuracy is 0.333 (one of three calls used a reference tool), step efficiency 1.0 and outcome a fail. Trajectory D uses the right tools but books flight F9, so its tool selection is 1.0, argument validity 0.667 and outcome a fail. Argument validity is counted only over calls that used a reference tool, so each metric isolates one error.¹ Outcome alone cannot tell A from B, and tool selection alone cannot tell A from D.

Text description of the diagram

• Outcome cannot tell an efficient run from a wasteful one.
• Tool selection cannot see a wrong argument.

Trade-offs and edge cases

Trajectory scoring has a catch. A reference path assumes one correct route, but many tasks have several valid ones, so a strict match can punish a good agent that took a different order. Use the reference as a guide for tool selection and argument checks, and score the final state as the arbiter.

A judge model that reads the trajectory against a rubric is the alternative: use a reference path when the task has one valid route, and a judge with a rubric when it has several. Anthropic's engineers report that checking a fixed sequence of tool calls is too rigid because agents find valid approaches the designers did not anticipate, and they advise grading what the agent produced rather than the path (Anthropic Engineering, January 2026).

Public benchmarks are narrow samples. GAIA has 466 questions on which humans scored 92% and GPT-4 with plugins 15% when it was published (Mialon et al., 2023), and SWE-bench's best model solved 1.96% of issues in the original paper (Jimenez et al., 2023). Those figures are dated: models have improved since, so cite the benchmark's current leaderboard for any present claim.

Cost and safety are separate axes. A path that passes but makes six calls is slower and more expensive, and an agent that takes a destructive action on the way to a pass should fail a safety check even if its outcome is correct. For the attack side see AI agent security, and for review steps see human in the loop.

How to answer it in an interview

The spoken structure is: outcome, then trajectory, then reliability, then how you keep the set honest.

Common mistakes

1. Scoring only the last message. (wrong) "The answer looks right, so it passed." (right) "Check the end state or run a test; text can sound right while the state is wrong."
2. Reporting one run. (wrong) "It scored 70%." (right) "It scored 70% on average, and pass^8 shows how often it repeats."
3. Mixing up pass@k and pass^k. (wrong) "pass@k measures reliability." (right) "pass@k is at least one success in k; pass^k is all k succeeding."
4. Treating the reference path as the only valid path. (wrong) "Any deviation is a failure." (right) "Use the path for tool and argument checks, and let the final state decide success."
5. Ignoring cost. (wrong) "A pass is a pass." (right) "Track calls, tokens and latency, because step efficiency separates two passing runs."

Follow-up questions

How do you evaluate an agent's trajectory and tool-use accuracy, not just its final answer?

Record every tool call with its arguments and compare it with a reference path or a rubric. Report tool-selection accuracy, argument validity and step efficiency next to the outcome, as in the worked example. Judge models for the rubric case are covered in LLM evaluation.

What if the per-trial success rate rises to 0.9?

Pass^8 jumps from 0.0576 at 0.7 per trial to 0.4305 at 0.9, because for independent runs it is the per-trial rate to the power 8.¹ Reliability improves much faster than the per-run rate suggests, which makes pass^k a sensitive metric for tracking progress. Even 0.43 means more than half of such tasks still fail at least once in eight runs.

What is the difference between pass@k and pass^k?

Pass@k is the chance that at least one of k trials succeeds, which rewards exploration. Pass^k is the chance that all k succeed, which rewards consistency. tau-bench proposes pass^k for settings such as customer service where every run must be right (Yao et al., 2024).

How do you evaluate agent performance?

Score the outcome against a goal state, the trajectory against a reference path or rubric, and reliability with pass^k over repeated runs, as in the four steps above. To keep the set from going stale, add real failures from production logs, move tasks the agent always passes into the regression set, where they still catch a change that breaks them, add harder tasks in their place, and re-run after every prompt, tool or model change (Anthropic Engineering, January 2026); the logging that feeds this is covered in LLM observability.

Public benchmarks such as AgentBench (eight environments), SWE-bench (repository issues), GAIA (general assistant questions) and tau-bench (tool-agent-user conversations) each test a narrow slice, so build a task set from your own use case too (Liu et al., 2023; Jimenez et al., 2023; Mialon et al., 2023).

What metrics matter (tool selection quality, action advancement, context adherence)?

Tool selection quality, action advancement and context adherence are metric names from one vendor's evaluation tool (Galileo, as of October 2026), not a shared standard. Its documentation defines tool selection quality as choosing the correct tool with the correct arguments, so it combines the tool-selection accuracy and argument validity of the worked example; action advancement as progress toward at least one user goal in a conversation; and context adherence as saying only what the given context supports. A judge model scores them, so report the rubric beside the number and pair them with outcome and pass^k rather than replacing those.

How is agent evaluation different from RAG evaluation?

RAG evaluation scores retrieval and grounded answering, while agent evaluation also scores planning, tool use and multi-step state changes. The retrieval-only metrics are in RAG evaluation and Ragas.

Sources

1. tau-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains — arXiv (Yao, Shinn, Razavi and Narasimhan), 17 Jun 2024
2. AgentBench: Evaluating LLMs as Agents — arXiv (Liu et al.), v3 revised 2025-10-04, 7 Aug 2023
3. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? — arXiv (Jimenez et al.), v3 revised 2024-11-11, 10 Oct 2023
4. GAIA: a benchmark for General AI Assistants — arXiv (Mialon et al.), 21 Nov 2023
5. Survey on Evaluation of LLM-based Agents — arXiv (Yehudai et al.), v2 revised 2026-04-23, 20 Mar 2025
6. Demystifying evals for AI agents — Anthropic Engineering, 9 Jan 2026
7. Tool Selection Quality (agentic metrics) — Galileo documentation (read 2026-10-26), 26 Oct 2026
8. Action Advancement (agentic metrics) — Galileo documentation (read 2026-10-26), 26 Oct 2026
9. Context Adherence — Galileo documentation (read 2026-10-26), 26 Oct 2026