LLM Digest
Subscribe

Agent Know-How

Agent engineering · know-how

Agent benchmarks: fixed tasks that exercise real tool use

🛠️ Solution·active·51 entries·51 sources·updated 2026-10-06

Pin down a fixed set of tasks with known good outcomes and run agents against them repeatedly. Unlike model benchmarks, agent benchmarks have to exercise tool use and multi-step trajectories (booking, querying, fixing, coordinating), so they double as integration tests for the whole agent, not just the model.

Latest updates
State of the art

Agent benchmarks now score the trajectory, not only the final answer: which tools were called, whether the task was really done, and whether each intermediate step was right.

Public scores transfer poorly. Agents that top familiar leaderboards degrade sharply in unfamiliar environments, so the strongest signal comes from suites built on your own tools and real sessions. Authoring them is getting cheaper through small CLIs, standing workbenches, and automated task curation.

The harness is part of what you measure. A deliberately simple loop reaches SOTA across 21 models, and the same model can gain inside one commercial harness and lose inside another. Run-to-run noise compounds this: one practitioner measured a model's own variance as larger than the best-to-worst model gap. Credible results now come with fixed environments (signed bundles, full replays), cost per solved task, repeated runs, and checks against harness gaming.

Suites are fragmenting by domain and failure mode. Each new suite targets one job and keeps finding domain-specific failures, often in validation rather than code generation. Adversarial suites test the failure path: unreliable tools, poisoned business data, malicious issues. Cost-optimized models fail these far more often than frontier ones.

Long horizons expose what short tasks hide. Over hundreds of turns, agents skip checks they planned themselves; on long multimodal research chains the best system reaches 43.1% accuracy. Subsystem benchmarks (memory, knowledge conflicts, root-cause reasoning) localize the part that broke.

The open problem is validity. A score is a claim about one task set, harness, and protocol, and protocol artifacts can masquerade as capability. Elastic's production harness shows what trusting a benchmark costs: paired trials, significance tests against a measured noise floor, guard workloads, and human approval gates.

Trade-offs

A fixed benchmark is reproducible and cheap to re-run, but it is a static target: agents over-fit to it, it goes stale as tools change, and "passing" can mean "memorized the distribution."

A benchmark built on your own tooling is more predictive but is real work to author and maintain. Small task sets have high variance: swapping a few tasks out of a ~100-task set can flip which model ranks first, so a single number is a claim about that task set, not a general fact about the model.

Best as a regression gate that catches known failures. Complement it with LLM-as-judge on live traces for the open-ended cases a fixed suite can't enumerate.

Why it matters for platform engineers

Agent benchmarks are the CI gate of the agent stack: a fixed suite you run on every prompt, model, harness, or tool change to catch regressions before users do.

The leverage is building it from your environment and tools, because public leaderboards systematically overstate how an agent will do on your workload. Budget the upkeep and repeated runs too: a benchmark is only useful while it still resembles production and its noise is smaller than the change you are trying to detect.

Developments 51

What a score measures: model, harness, or noise

12 entries · latest Sep 18, 2026

Harness choice, protocol artifacts, and run-to-run noise can outweigh model differences; fixed environments, replays, counterfactual checks, and paired statistical trials are how scores earn trust.

ReFigBench: the same model gains in one harness and loses in another

ReFigBench has coding agents reconstruct 1,000 real arXiv overview figures as editable PowerPoint slides. It runs the strongest model inside two commercial harnesses under two workflows (direct code generation and a specialized PPTX pipeline), ten configurations in all.

The same model gains from the specialized workflow in one harness and loses in the other, and harness choice shifts scores even under an identical prompt. It is a measured instance of the protocol-validity critique: score differences reflect the harness, not only the model.

Elastic's code-optimization agent is gated by paired trials, significance tests, and human approval

Elastic's harness lets an agent propose Elasticsearch performance optimizations through exploration, exploitation, and validation phases. Trust comes from statistics, not one before/after run:

  • Paired stash-flip trials cancel thermal drift.
  • A Mann-Whitney U test plus seeded bootstrap CI, with the fork as the statistical unit.
  • An accept bar set by each benchmark-machine pair's A/A noise floor.
  • Guard workloads, an allocation check against wins bought with ~15% extra garbage, and add-only tests.

Humans approve benchmark registration, promotion, and publication.

CHASE flags harness gains that come from benchmark shortcuts instead of capability

Automatic harness optimization can produce a "cheating harness" whose gain on a released benchmark depends on a benchmark-wide shortcut. Counterfactual Harness Search and Evolution (CHASE) searches for protocol changes that would destroy a claimed gain while preserving task semantics, keeping a validity firewall and an archive of confirmed counterfactuals.

On OfficeQA it retains most genuine gains while substantially reducing gains a counterfactual protocol change would erase. The benchmark itself starts resisting harness gaming.

Show 9 earlier entries

Agent benchmark scores may reflect protocol artifacts, not capability

A protocol-validity analysis argues that many agent benchmarks conflate task difficulty with scaffolding and protocol artifacts. Two agents can score differently because of how their harness interacts with the benchmark's protocol, not because one is more capable.

This turns "the harness is part of what you benchmark" into a challenge to the benchmark's validity as a measuring instrument, not only its reproducibility.

Favur Evals pairs every harness score with a full replay of the run

Favur is a 14-agent harness (planner, architect, coder, tester, reviewer, builder) coordinated by code, not an LLM. Favur Evals scores its runs across models from the same standardized statement of work, using composite engineering subjects computed from each run's own artifacts: lint, test results, tool telemetry.

Every run is captured end to end and can be replayed. Reproducibility becomes a feature of the benchmark rather than a property to demand of it.

Run-to-run noise can exceed the gap between the best and worst model

Dan Luu's notes on agentic coding measure benchmark variance directly: one model's run-to-run standard deviation (7.5% on a coding task) exceeded the best-to-worst-model gap, and swapping a few tasks out of a ~100-task set flipped which model ranked first. Two models can each look cheaper or more expensive than the other depending on the task set.

A leaderboard number is a claim about that task set, not a general fact about the model. Report variance across repeated runs.

GitHub scores its Copilot agent harness on results and token efficiency across 20+ models

GitHub evaluated its Copilot agentic harness across more than 20 models and multiple benchmarks, reporting results and token efficiency together.

Treating the scaffold as a benchmark variable and cost per solved task as a first-class metric is the comparison builders need when choosing a model inside a fixed harness. The results are GitHub's own.

A deliberately simple agent loop reaches SOTA across 21 models

Strands Labs' benchmark-harnesses repo reports a deliberately simple agent loop reaching state-of-the-art results across 21 models on SWE-bench Pro, Terminal-Bench 2, and SWE-bench Verified.

Elaborate scaffolding often adds cost and variance without adding capability. Hold the harness fixed when benchmarking and make extra complexity earn its place.

Benchmarking on your own tools and real work

10 entries · latest Aug 1, 2026

Public leaderboards overstate out-of-distribution performance; suites built from your own tools, real sessions, and held-out environments predict production better, and authoring them is getting cheaper.

Supabase's open-source Evals scores Claude Code, Codex, and OpenCode on real Supabase tasks

Supabase released Evals, an open-source benchmark that scores Claude Code, Codex, and OpenCode on real Supabase tasks rather than a generic coding benchmark.

A platform vendor measuring coding agents on its own APIs is the "benchmark on your own tooling" recommendation in practice, and a template other platform teams can copy.

smevals turns building a small eval suite into a CLI command

Simon Willison and Jesse Vincent's Prime Radiant lab built smevals, a tool for running small eval suites across model configurations and grading results. uvx smevals run/grade/serve builds, runs, and grades a directory of YAML eval files, and a coding agent can author the suite from uvx smevals docs.

It drops the cost of "benchmark on your own tooling" from a bespoke harness to a reusable command.

Show 7 earlier entries

AeroScore finds none of six aerospace documentation portals ready for AI agents

AeroScore scores how well documentation portals support AI agents, using the open AFDocs checklist (llms.txt presence, robots.txt, and more) plus a PDF-heaviness extension. None of the six aerospace portals in its first batch scored as sufficiently prepared.

It evaluates the environment an agent has to operate in, not the agent itself: a precondition check that sits upstream of any task benchmark.

EnterpriseClawBench builds 852 tasks from real workplace agent sessions

EnterpriseClawBench mines 852 reproducible tasks from an archive of real enterprise agent sessions where agents read heterogeneous files, call tools, and deliver business artifacts. Each task pairs recovered fixtures with rewritten prompts, role classes, hard rules, and semantic rubrics.

The benchmark inherits the messiness of production instead of approximating it. The catch: the sessions contain internal content, so the data is not released.

Agents that top familiar benchmarks degrade sharply in unfamiliar environments

"Running the Gauntlet" introduces GauntletBench, a web-based benchmark for agent generalization in challenging scenarios. It argues current benchmarks are built on popular applications with simple tasks, so modern agents saturate them without exposing their limits.

Agents that score well on familiar leaderboards degrade sharply outside familiar environments. A high public score is weak evidence for how an agent will do on your workload.

Domain-specific suites mined from real work

14 entries · latest Sep 11, 2026

New suites target one job at a time (Java migration, Stripe integrations, AWS operations, Rails, code review, scientific imaging) and keep finding domain-specific failures, often in validation rather than code generation.

AWS-Bench grades coding agents on real AWS infrastructure tasks, verified against account state

AWS-Bench scores coding agents on real AWS work, split into read-only introspection (diagnosing a live misconfiguration) and mutation (provisioning or modifying resources, checked programmatically against the resulting account state). Curated sets run from a 9-task quickstart to 78 "basic" and 47 "advanced" tasks, with reference pairings including Claude Sonnet 5.

A fuller reference-results report is still to come.

The Rails Foundation benchmarks coding agents on Ruby on Rails across 8 models

The Rails Foundation commissioned the first systematic Ruby on Rails benchmark for coding agents, scoring accuracy, speed, token consumption, and cost across 8 frontier and open-weight models on self-contained tasks. It checks whether agents use current Rails APIs rather than stale training data.

A harder multi-step Stage 2 and an open-sourced Ruby harness are planned.

TREK requires every leg of a trip plan to be correct and bookable at once

TREK stress-tests trip-planning agents on a property single-answer benchmarks skip: every flight, hotel, and attraction must exist and be bookable, the days must be traversable, and the total must clear a budget, all at once. One wrong leg fails the whole plan.

It replaces soft or LLM-judged rubrics with checks that certify a plan is executable, reproducible, and auditable.

Show 11 earlier entries

ExtractBench scores enterprise extraction on accuracy, completeness, grounding, and cost together

ExtractBench evaluates schema-guided extraction: given a document and a user-defined schema, produce correct output with source evidence. It spans 4,869 pages across 370 enterprise documents, 8 business domains, and 67 document types, and is the first to score value accuracy, record completeness, grounding, and measured cost together.

A bare accuracy number hides whether an extraction can be traced to its source and what it cost.

HalluTruthQA grades span-level hallucination detection in Arabic question answering

HalluTruthQA has 2,400 expert-curated Arabic QA examples across four domains (Islamic knowledge, history, science, geography). Each answer has a verified reference and six verification candidates; hallucinated answers carry character-level error spans and human-written explanations.

Zero-shot, no open-source model tops every sub-task. Grading is moving past English-centric, response-level hallucination labels toward non-English, finer-grained ones.

Stripe's benchmark finds agents build integrations but fail at validation

Stripe's 11-environment benchmark scores agents on real Stripe integrations: checkout migration, billing API work, and full-stack browser checkout. The best runs needed roughly 63 interaction turns.

The two leading models (92% vs 73%) failed the identical validation step rather than differing on raw coding ability. Validation, not code generation, is where integration agents break.

Imaging-101 finds coding agents fail on domain conventions in scientific imaging

Imaging-101 scores coding agents on 57 expert-verified computational-imaging tasks across six scientific domains, each grounded in a peer-reviewed paper and canonicalized into a four-stage pipeline. Three tracks cover planning, unit tests, and end-to-end reconstruction.

Failures are domain-specific, such as physical-convention handling and pipeline integration, beyond generic coding skill.

GameEngineBench scores coding agents inside real Unreal Engine C++ runtimes

GameEngineBench evaluates coding agents on scoped C++ implementation tasks inside Unreal Engine, where code must work in a stateful, interactive system with real-time simulation, rendering, and physics.

Those runtime constraints, relevant to robotics, healthcare, and manufacturing 3D applications too, aren't exercised by a generic coding benchmark.

TestEvo-Bench checks whether agents update tests along with the code they change

TestEvo-Bench is an executable, live benchmark of test-and-code co-evolution tasks mined from real repositories. Unlike benchmarks that isolate the test from the code change or rely on static metadata, it verifies that generated tests run and are semantically tied to the change.

It isolates a habit coding agents need in production: keeping the test suite in sync with what they modify.

MirrorCode benchmarks agents rebuilding entire programs from behavior alone

MirrorCode is a long-horizon coding benchmark where agents reimplement entire software projects by replicating an existing program's functionality. It targets the gap between short-task benchmarks and one-off demos (such as an AI-built C compiler) that are hard to compare because they involve human guidance and aren't repeated across models.

It moves the frontier from "modify existing code" to "reconstruct it from how it behaves."

Adversarial tools, poisoned inputs, and security

6 entries · latest Sep 16, 2026

Benchmarks now test the failure path (unreliable tools, poisoned business data, malicious issues) and score defenses on precision and recall together; cost-optimized models fail these far more often.

VLoc Bench: the best agent reaches 0.229 File F1 localizing vulnerabilities in unfamiliar repos

VLoc Bench gives an agent a CWE description and read-only terminal access and asks which files implement the weakness: 500 real vulnerabilities across 290 repositories, six ecosystems, and 147 CWE categories, with pre-fix and post-fix snapshots.

Across 27 models and four static-analysis tools, the best reaches only 0.229 File F1, and 38.4% of tasks get no correct localization from any system. Systems that find vulnerable files still flag locations on already-patched snapshots, so localization skill doesn't transfer to remediation-awareness.

An open agent-security benchmark scores defenses on 497 attacks and 1,172 benign samples

An open, tool-agnostic security benchmark tests any HTTP-addressable classifier against 497 attacks in 13 categories (direct and indirect injection, credential exfiltration, tool abuse, system-prompt extraction, memory poisoning, supply-chain manipulation) plus 1,172 benign samples. The author publishes the attacks their own defense fails to catch.

Scoring F1, precision, and recall together means a defense that blocks everything doesn't look artificially strong. See prompt injection.

Show 3 earlier entries

Cost-optimized models act on poisoned business data far more often than frontier models

ActionRail's benchmark tests whether an agent executes corrupted-but-plausible business data, such as an altered payment account or a fake refund address, buried in an otherwise legitimate document.

Across 8 models from 4 providers on 10 consequential workflows, cost-optimized models failed 48.3-63.3% of the time versus 1.7-21.7% for frontier models. A guard layer blocked all 480 protected attack cases with zero false positives. This failure mode needs a dedicated defense, not just a stronger model. The guard layer and results are ActionRail's own.

ToolBench-X scores agents when tools time out, error, or return malformed results

"Beyond Function Calling" introduces ToolBench-X, which tests agents under recoverable reliability hazards: tools that time out, error, or return malformed results, across sequential, parallel, and mixed workflows with deterministic tools.

It exposes agents that pass clean tool suites but cannot recover when the environment misbehaves. The benchmark targets the failure-recovery path, not the happy path.

Long horizons and subsystem diagnostics

9 entries · latest Sep 16, 2026

Long-horizon suites show final-answer scores overstate success, while subsystem benchmarks (memory, knowledge conflicts, root-cause reasoning, coordination) grade the inner process so a regression can be localized.

Mr.LHDR: the best deep-research agent reaches 43.1% on long multimodal evidence chains

Mr.LHDR builds each question from a hidden node-relation graph requiring an average of 12.1 intermediate conclusions at dependency depth 10.4, with at least one image, map, PDF, chart, table, or video frame that changes the reasoning.

It scores both the final answer and intermediate conclusions. The strongest system reaches 43.1% Overall and 34.3% Strict Accuracy, so final-answer accuracy overstates research success. Removing images cuts the dependency-aware score by 12.6 points.

KC-Bench: no model reliably reconciles user, parametric, and tool knowledge conflicts

KC-Bench isolates how agents reconcile conflicts between user instructions, parametric knowledge, and tool observations. Its 238 multi-turn tasks, screened from over 1,000 candidates, combine a user simulator, stateful tools, deterministic assertions, and human trajectory verification.

Across nine models, including DeepSeek-V4-Flash, GLM-5.2, and MiniMax-M3, none reliably handles factual correction, identity consistency, and temporal conflicts in every setting. A missed conflict can propagate straight into a tool call.

CivBench catches agents skipping state checks they planned across 300+ turns of Civilization VI

CivBench runs 300+-turn episodes across 76 MCP tools in Civilization VI, grading sustained planning and state monitoring under partial observability. Its pilot (23 runs, four model families) says aggregate scores don't yet discriminate models.

Two interface-level metrics did catch failures: Proactive Monitoring Rate and RAG@10 (whether a commitment in the agent's own plan executes within ten turns). Agents told to check victory progress every 20 turns did so only every 30-75, and missed the check before 7 of 20 detectable defeats.

Show 6 earlier entries

AgentOps benchmark grades failure-diagnosis reasoning over multimodal observability data

Two datasets (AIOps2025 and RCA100) evaluate LLM agents on microservice failure diagnosis over multimodal observability data. Grading covers the reasoning process along three dimensions, starting with localization (where the fault is) and identification (what type), rather than only the final answer.

It brings process-over-outcome grading to ops agents and pulls benchmarking toward observability.

OpenRCA 2.0 grades root-cause analysis on the causal path, not just the answer

OpenRCA 2.0 argues that labeling only the root cause reduces RCA to pattern matching. Its PAVE protocol uses known fault-injection interventions to reconstruct the causal propagation path from root cause to symptom, and grades agents step by step.

Grading the reasoning trajectory localizes a regression to the step that broke, instead of inferring it from a fallen aggregate score.

Evidence · 51 sources
All sources behind this page