VerifierBench Tests Whether AI Agents Can Build Reliable Verifiers

Introduction

For an LLM agent that uses tools, changes an environment, or edits code, completing a task is only part of the problem. A separate verifier must determine whether the result satisfies the instruction. That judgment may control rewards, synthetic-data filtering, or whether an agent is allowed to proceed. When the verifier is also written by a model, however, the evaluation problem moves one level up.

VerifierBench studies this setting directly. The agent receives the task instruction and environment available during problem solving, then writes an executable verifier. The verifier is evaluated on hidden cases designed to test both sides of the decision: accepting valid solutions and rejecting invalid ones.

Key findings

• The benchmark contains 222 tasks spanning tool-call, environment-state, and code-change verification, drawn from several agent benchmarks.
• Its 4,993 hidden cases include alternative valid solutions, common mistakes, and attacks against the verifier.
• Nineteen models evaluated in a common agent harness achieve normalized balanced accuracy between 10.6 and 62.1.
• Generated verifiers are generally better at rejecting invalid outputs than accepting every valid one. Some reject all tested solutions, making excessive strictness look like strong error detection.
• Common failures include assuming a particular answer format, restricting how tools must be used, or requiring code changes to follow an unsupported pattern.

Why it matters

A verifier that catches errors but rejects legitimate solutions is not reliable. It can deny rewards to successful agents, discard useful synthetic data, and encourage models to optimize for accidental evaluator rules instead of the task itself. The problem is especially difficult because self-testing can reinforce the same mistake: an agent may test only solutions that already match its verifier’s assumptions, or submit a verifier without checking that any correct solution passes.

VerifierBench therefore argues for two complementary checks. Evaluation should ask whether at least one correct solution is accepted, but also whether other solutions permitted by the task can pass. This shifts attention from matching a single reference answer to recognizing the task’s actual set of valid outcomes.

The accompanying Gavel harness aims to improve verifier generation with an evidence header, a domain rule library, and authoring principles. According to the supplied project material, a GPT-6-astra configuration using Gavel reaches 68.3 on VerifierBench. That result represents a tool-assisted configuration and should be distinguished from the 10.6–62.1 range reported for the 19-model baseline comparison.

The broader lesson is that agent evaluation must include the evaluator itself. As agents become more autonomous, a verifier is not merely a utility script; it becomes part of the system’s reward and safety boundary. Its ability to handle alternative valid solutions deserves measurement alongside task success.

Source: Hugging Face Daily Papers