A model that answers a single question correctly is not the same thing as an agent that completes a multi-step task correctly. That distinction is the entire reason agent evaluation split off from ordinary LLM benchmarking in the last two years. An agent produces a trajectory — a chain of reasoning, tool calls, and intermediate decisions — before it ever reaches a final answer, and a correct final answer reached through a policy-violating path is, in production terms, a failure (Confident AI).
Why final-answer scoring isn't enough
Traditional LLM evaluation checks output quality: is the answer right, is it well-formed, does it match a reference. Agent evaluation adds a second axis entirely — did the agent plan sensibly, select the right tools, reason correctly at each intermediate step, and complete the task efficiently (Confident AI).
The standard framing splits into three layers:
- Final-answer evaluation — score only the last message. Cheapest, least informative.
- Trajectory evaluation — score the full sequence of steps and tool calls.
- Per-turn evaluation — score the meaning of each individual turn as it happens in production.
A concrete example that keeps showing up in the 2026 literature: an agent that reaches the correct answer in 20 steps, two of which were policy-violating tool calls, is a failing trajectory even though the final answer would pass a naive eval (Confident AI). If your evaluation only checks the endpoint, you'll ship agents that are right by accident and wrong by process — and the process failures are the ones that cause real incidents (unauthorized refunds, leaked data, unsafe tool calls) even when the transcript ends correctly.
The benchmark landscape
tau-bench and tau2-bench
Sierra's tau-bench evaluates agents in realistic multi-turn conversations — retail and airline customer service domains — checking both task success and policy compliance, and it exposed reliability problems that single-turn benchmarks miss entirely (Sierra). Its successor, tau2-bench, introduced the pass^k metric, which measures whether an agent succeeds reliably across repeated attempts rather than getting credit for succeeding once (Automation Anywhere).
That reliability-over-luck framing matters more than it sounds. A benchmark score built on pass@1 (does it succeed on the first try) rewards agents that get lucky. pass^k — succeeding across k independent attempts — is a much harder bar and a much better proxy for whether you can trust the agent unattended.
SWE-bench
SWE-bench evaluates coding agents against 2,294 real GitHub issues, using execution-based testing: does the agent's patch actually make the failing test suite pass (morphllm.com). It remains the dominant benchmark for coding-agent capability, though a 2026 position paper argues that coding benchmarks like SWE-bench are increasingly misaligned with how agentic software engineering actually works in practice — real engineering involves ambiguous requirements, incomplete specs, and iterative clarification that single-PR benchmarks don't capture (arXiv 2606.17799).
The Holistic Agent Leaderboard (HAL)
HAL aggregates results across nine benchmarks spanning coding (SWE-bench Verified, CoreBench Hard, USACO, SciCode, ScienceAgentBench), web navigation (Online Mind2Web), general assistance (GAIA, AssistantBench), and customer service (TAU-bench Airline) (morphllm.com). It exists specifically because no single benchmark captures agent capability broadly enough — coding ability and customer-service policy compliance are different skills that happen to both route through "agent."
Terminal-Bench 2.0
Terminal-Bench 2.0 comprises 89 human-validated tasks in specialized domains — scientific computing, ML, systems administration — that require end-to-end workflow completion: model training, system configuration, and debugging as whole tasks rather than isolated Q&A (morphllm.com).
| Benchmark | Domain | What it measures | Key metric |
|---|---|---|---|
| tau-bench / tau2-bench | Retail, airline customer service | Multi-turn task success + policy compliance | pass@k / pass^k |
| SWE-bench | Software engineering | Real GitHub issue resolution | Test suite pass rate |
| HAL | Coding, web nav, assistance, service | Cross-domain aggregate | Composite leaderboard |
| Terminal-Bench 2.0 | Sysadmin, ML, sci-computing | End-to-end workflow completion | Task success |
| GAIA / AssistantBench | General assistant tasks | Real-world task completion | Task success |
Trace-based evaluation: scoring the spans, not just the run
Beyond published benchmarks, production teams increasingly rely on trace-based evals that score individual spans inside an agent run — tool calls, retrieval steps, reasoning spans, planner outputs, sub-agent handoffs — so a failed score can be traced back to the exact step that caused it, rather than just knowing "the run failed" (Confident AI).
Frameworks built around this in 2026 include LangSmith, Future AGI, Braintrust, DeepEval, Phoenix, and OpenAI Evals, with MLflow — at over 30 million monthly downloads — as the most widely adopted open-source AI engineering platform underpinning much of this tooling (Future AGI; MLflow).
Note
Enterprise-specific evaluation dimensions
A 2026 paper on enterprise agentic AI evaluation argues that accuracy alone is an insufficient frame for production deployment. Their proposed multi-dimensional framework adds: task completion under ambiguity, tool-use efficiency (cost and latency, not just correctness), safety/policy adherence, and robustness to adversarial or malformed inputs (arXiv 2511.14136).
This lines up with what practitioners report anecdotally: an agent that's 95% accurate but burns 3x the API budget per task, or one that's accurate but occasionally calls a destructive tool when it shouldn't, fails enterprise deployment criteria that a pure accuracy benchmark would never catch.
Where benchmarks still fall short
Efficient benchmarking research points out a structural problem: comprehensive agent benchmarks are expensive to run (many require live tool execution, sandboxed environments, and long multi-turn rollouts), which pushes teams toward smaller, cheaper proxy benchmarks that may not correlate well with full-benchmark results (arXiv 2603.23749). The practical implication: a leaderboard number from a fast, cheap eval suite should be treated as a directional signal, not a substitute for testing your actual agent on your actual task distribution.
Actionable takeaway
If you're shipping an agent into production, don't evaluate it the way you'd evaluate a chatbot. Build trace-based evaluation into your pipeline from day one so failures are attributable to a specific step, not just a failed run. Use pass^k-style repeated-attempt testing instead of single-shot success rate — an agent that works once isn't an agent you can trust unattended. And treat published benchmark scores (SWE-bench, tau-bench, HAL) as a starting filter for model selection, not a substitute for building a domain-specific eval set that reflects your actual policy constraints and tool-use costs.
Sources: Confident AI — LLM Agent Evaluation Metrics in 2026, Sierra — Benchmarking AI Agents (tau-bench), Automation Anywhere — Tau Bench: 2026 Enterprise Evaluation Guide, morphllm.com — AI Agent Evaluation 2026, Future AGI — Agent Evaluation Frameworks 2026, MLflow — Top 5 Agent Evaluation Tools 2026, arXiv 2606.17799 — Coding Benchmarks Misaligned with Agentic Software Engineering, arXiv 2511.14136 — Multi-Dimensional Framework for Enterprise Agentic AI, arXiv 2603.23749 — Efficient Benchmarking of AI Agents
Get new posts as they publish
No spam — just the next post, straight to your inbox.