What Does an Agent Evaluation Actually Support?

A benchmark result is an observation. A deployment decision is an action. Between them are several inferences that are often left implicit. For example:

System A achieved 74% on benchmark B under configuration C.

This may be an accurate statement of the evaluation result. It does not establish that System A is reliable enough for workflow X, or that it should be deployed there. Those stronger claims require additional evidence: that the evaluation scored the intended outcome correctly, that the sampled tasks and runs support a statement about the evaluation domain, that the evaluation setting corresponds to the target workflow, and that the measured outcome is relevant to the decision being made. Argument-based validity separates the scoring, generalization, extrapolation, and decision inferences in this chain [1,2].

Observed runs
    │  scoring
    ▼
Evaluation result
    │  generalization
    ▼
Performance in the evaluation domain
    │  extrapolation
    ▼
Expected performance in the target setting
    │  decision
    ▼
Supported action or conclusion

Scoring: did the evaluation measure what happened?

The first question is whether the evaluation mechanism correctly identified success, failure, or quality. For agents, this can fail at several points. Tests may check only part of the intended state. A task may be solvable without the capability it was designed to require. Environment state may leak between runs. A parser or grader may inspect the wrong artifact. Recent work on agentic benchmark construction shows that implementation and reward-design problems can materially distort measured performance [3]. Protocol-validity work also shows why some failures have to be examined at the trajectory level: an agent may reach the rewarded state through a shortcut that the benchmark did not intend to permit [10].

Generalization: do these runs support a domain-level claim?

Agent evaluations usually sample several things at once: tasks, repeated runs, prompts or scaffolds, and execution conditions such as seed, ordering, and tool state. These sources of variation matter because occasional success and reliable success are different claims. τ-bench introduced pass^k to report repeated-attempt reliability [4]. Prompt choice can also change measured performance and model rankings [5]. Recent work on agent reliability separates consistency, robustness, predictability, and safety instead of reducing reliability to one success rate [6]. A point estimate alone does not establish stability across the domain. The amount of repetition, uncertainty analysis, or robustness testing needed depends on the claim and the evaluation design.

Extrapolation: does the test setting support the target-setting claim?

A benchmark can support a statement about performance in its own setting without establishing performance in the setting where the result will be used. The relevant comparison includes the task distribution, users, tools, permissions, system configuration, workflow state, resource constraints, oversight, and consequences of failure. A benchmark label does not establish those correspondences. Prior work has argued that benchmark performance is often overinterpreted as broad capability [7] and shown that systems with similar held-out performance can behave differently under deployment-relevant conditions [8]. For an evidence review, the question is:

Which correspondences between the evaluation setting and the target workflow have actually been demonstrated?

The rest remain assumptions.

Decision: is the evidence enough for the action?

Even when the previous links are supported, a deployment or procurement choice can depend on failure costs, alternatives, latency, resource use, safety requirements, acceptable error thresholds, or the distribution of failures. A higher benchmark score is therefore not automatically a better decision. Work on agent benchmarking has already shown that cost can change which system is preferable even when accuracy improves [9]. The decision link has to be evaluated against the consequence and threshold that actually determine the action.

Three agent-specific complications

The evaluated system includes the scaffold and environment

An agent result depends on more than the base model. The scaffold, prompts, tools, permissions, environment, and evaluation protocol can all change measured performance. The evidence package should identify the evaluated system and evaluation configuration explicitly.

Protocol validity can depend on the trajectory

Agents can act on the environment used to evaluate them. They may exploit evaluation artifacts, infer task structure, use unintended feedback channels, or reach a rewarded state without performing the intended task [10]. When this is plausible, benchmark validity cannot always be assumed from benchmark design alone.

Reliability information should survive aggregation

Two agents can have the same average success rate while behaving very differently. One may fail consistently on the same subset of tasks. Another may succeed or fail unpredictably across repeated attempts. For deployment decisions, this difference can matter more than the mean.

Claim ceiling

We use claim ceiling as a reporting convention:

The claim ceiling is the strongest conclusion for which the available evidence supports the required inference chain.

For example:

Claim: "A is ready for workflow X"

Observed runs                     ✓
Scoring                           ✓
Evaluation-domain generalization ✓
Target-setting extrapolation      ?
Decision support                  ✕

CLAIM CEILING:
Performance in the defined evaluation domain
under the evaluated configuration.

The review can identify the unsupported transition and what would be needed to support it.

A compact reconstruction worksheet

The worksheet is meant to be filled against a specific claim, not used as a general score for a benchmark.

References

1. Kane MT. Validating the Interpretations and Uses of Test Scores. Journal of Educational Measurement. 2013;50(1):1–73.
2. Cook DA, Brydges R, Ginsburg S, Hatala R. A contemporary approach to validity arguments: a practical guide to Kane's framework. Medical Education. 2015;49(6):560–575.
3. Zhu Y, Jin T, Pruksachatkun Y, et al. Establishing Best Practices for Building Rigorous Agentic Benchmarks. NeurIPS. 2025.
4. Yao S, Shinn N, Razavi P, Narasimhan K. τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. ICLR. 2025.
5. Mizrahi M, Kaplan G, Malkin D, et al. State of What Art? A Call for Multi-Prompt LLM Evaluation. Transactions of the Association for Computational Linguistics. 2024;12:933–949.
6. Rabanser S, Kapoor S, Kirgis P, et al. Towards a Science of AI Agent Reliability. ICML. 2026.
7. Raji ID, Bender EM, Paullada A, Denton E, Hanna A. AI and the Everything in the Whole Wide World Benchmark. NeurIPS Datasets and Benchmarks. 2021.
8. D'Amour A, Heller K, Moldovan D, et al. Underspecification Presents Challenges for Credibility in Modern Machine Learning. Journal of Machine Learning Research. 2022;23(226):1–61.
9. Kapoor S, Stroebl B, Siegel ZS, Nadgir N, Narayanan A. AI Agents That Matter. Transactions on Machine Learning Research. 2025.
10. Shao J, Chen H, Zhang W, Pan M, Luo B. Do Agent Benchmarks Measure Capability? Protocol Validity in the Age of Agentic AI. arXiv:2607.22368. 2026.