A low eval score usually gets read as "the agent failed." Anthropic reports a case where that read was wrong: Opus 4.5's CORE-Bench score rose from 42% to 95% once the team fixed grading bugs, ambiguous task specs, and stochastic tasks in the eval. The agent never changed. Before you spend a cycle improving an agent that scored badly, spend an hour checking whether the eval is what's broken.
"},{"heading":"Short answer","html":"An agent eval is an input plus grading logic, and the grading logic is usually the weak link. Three grader types trade cost against accuracy: code-based graders are cheap and objective but only check what you encoded; model-based graders handle nuance but are non-deterministic and expensive; human graders set the bar but don't scale.
\nBecause agents vary run to run, one pass/fail number isn't enough. pass@k asks whether the agent can solve the task at all; pass^k asks whether it solves it every time. And a bad score on either can mean the eval, not the agent, is broken.
"},{"heading":"Builder model","html":"Treat an eval as software with the usual failure surface: bugs, ambiguous specs, and flaky behavior. All three produce the same symptom as a real agent failure — a low score.
\nStart from real failures. Anthropic recommends 20-50 tasks drawn from cases that actually went wrong. Each needs an unambiguous spec and a reference solution; ambiguity produced the 42%-to-95% CORE-Bench jump. Include negative cases where the right behavior is to refuse or say it doesn't know; solvable-only suites cannot detect overconfidence.
\nKeep the environment stable and grade outcomes. A flaky sandbox produces noise indistinguishable from a regression. Exact step matching penalizes a correct result reached by a different path, so grade the outcome and, separately, the trajectory.
\nGrade the artifact each agent type produces.
\nMeasure the configuration, repeatedly. In an 18,000-trajectory study of coding agents, 54% of outcome variance was run-to-run noise within identical configurations, and task information moved results more than time budget or model size. A verification tool changed behavior where a verification prompt barely did. TRACE found identical reruns flip 15-36% of task outcomes.
\nTest the scorer when a score moves. A score change can come from the scoring rule, not the agent. TRACE rescored unchanged trajectories after renaming tools: restoring the names at scoring time erased a 0.250 drop in a scripted agent.
\nAudit the simulated tools. Benchmarks grade what a simulated tool reports having done. An audit of 34 mutating tools in four benchmarks confirmed seven tool defects; in one clinical benchmark the tool claimed writes it never made, and the grader scored that claim as success. A defect like this is present on every rerun, so repeated runs never expose it.
\nWatch for saturation. Once scores plateau near the ceiling, the eval stops separating good from great, and further optimization tunes to its blind spots — the dynamic covered in does a high benchmark score predict production reliability?.
"},{"heading":"How to apply","html":"See agent evaluation, agent benchmarks for where public benchmarks diverge from your own eval, can you trust an LLM-as-judge score? for model-based grader failures, and does a high benchmark score predict production reliability? for reading a score as a production claim.
"}],"evidence":[{"id":"arxiv-2609-37315-executable-contract-audit","kind":"benchmark-result","tier":"benchmark/result-backed","title":"Do Agent Benchmarks Do What They Say? An Executable-Contract Audit of Tool-Using Agent Environments","note":"Checks each simulated tool against its advertised interface across 34 mutating tools in four benchmarks and confirms seven tool defects plus one evaluator property. On AgentDojo, at least 5 of 25 mutating tools diverge from their contract. On tau2-bench, the evaluator rewards a refuel of a suspended line and fails the repaired tool. A clinical benchmark's tool reports writes it never made, and its grader counts that message as success.","added":"2026-10-14","url":"https://arxiv.org/abs/2609.37315","sid":"ec84f4f58551c9cf"},{"id":"arxiv-2610-11678-trace-verifier-brittleness","kind":"benchmark-result","tier":"benchmark/result-backed","title":"TRACE: Diagnosing Verifier Brittleness in Agentic Evaluation","note":"Protocol that mutates one part of an eval, compares paired runs, and rescores unchanged trajectories. Renaming tools cut a scripted agent's score by 0.250 with identical operations; restoring names at scoring time closed the gap. On tau2-bench (88 tasks), misleading tool names lowered every agent's reward 0.20-0.44, while identical reruns flipped 15-36% of outcomes. Two frontier judges disagreed on 57% of records.","added":"2026-10-09","url":"http://arxiv.org/abs/2610.11678v1","sid":"10abc73be739f08b"},{"id":"arxiv-2610-01618-agents-are-systems","kind":"benchmark-result","tier":"benchmark/result-backed","title":"Agents Are Systems, Not Models: Rethinking Agentic Evaluation","note":"Runs a coding agent on four scientific tasks that require operating specialist models, across more than 18,000 trajectories varying task information, reasoning approach, self-verification, time budget, and backbone model. 54% of outcome variance came from run-to-run variability within identical configurations. Task information had the largest effect, above time budget or model size; extra time helped only with enough information or a capable model. Verification tools changed behavior substantially; verification prompts had minimal effect.","added":"2026-10-02","url":"http://arxiv.org/abs/2610.01618v1","sid":"068e3817b6d56fbd"},{"id":"anthropic-2026-demystifying-agent-evals","kind":"primary-doc","tier":"primary-doc-backed","title":"Demystifying evals for AI agents","note":"Anthropic's guide to building agent evals. Names three grader types: code-based (fast, cheap, objective), model-based (flexible, non-deterministic, expensive), and human (best quality, slowest). Recommends starting from 20-50 real-failure tasks with unambiguous specs and reference solutions, positive and negative cases, isolated environments, and outcome grading over step matching. Defines pass@k and pass^k. Reports Opus 4.5's CORE-Bench score rising from 42% to 95% after fixing grading bugs, ambiguous specs, and stochastic tasks in the eval.","added":"2026-09-02","url":"https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents","sid":"6c790a16de0afd2b"},{"id":"agent-eval-design-editorial-synthesis","kind":"editorial-inference","tier":"editorial inference","title":"LLM Digest synthesis","note":"A low eval score is a claim about two things at once: the agent's behavior and the eval's own correctness. Builders default to debugging the first without checking the second. Treat the eval as software that needs its own bug-fixing pass before trusting what it reports about the agent.","added":"2026-09-02"}],"related_topics":[{"slug":"agent-evaluation","title":"Measuring whether an agent actually worked is hard"},{"slug":"agent-benchmarks","title":"Agent benchmarks: fixed tasks that exercise real tool use"}],"related_playbook_cards":[],"related_storylines":[]}