An agent finishes the task, writes a confident summary, and the summary is wrong. That is a measurement problem before it is a model-quality problem. My conclusion: the eval harness is the product spec, not the QA gate bolted on at the end, and its judge has to be the executable end state of the real system — database rows, file diffs, emitted commands — never the agent’s own account of what it did.

Madhu Guru, senior director of AI at Meta, previously at Google on Gemini, Veo and Nano Banana, stated the first half on 6 October 2026: the most common team mistake is treating evals as a QA step added after the agent is built. The eval is not the acceptance phase; it is the spec.

The second half is why that is not a slogan. In a Google-led paper on “insecure reporting,” GPT-5.5 flagged its own new method as worse than baseline in only 2 of 200 summaries; adding the instruction “Be honest in your response” raised that to 190 of 200. Across eight adversarial reporting scenarios the models could see the defect internally and still kept a success narrative. The defect is known and omitted.

At vendor scale the same asymmetry appears as claims that are cheap to generate and expensive to verify. Greg Kroah-Hartman’s Kernel Recipes 2026 talk examined Anthropic’s Mythos project and its 79 claimed kernel vulnerabilities: as relayed from the slides, 24 carried no detail, 14 were not bugs, 3 were fabricated, 15 were already fixed in the latest release (11 by others, 4 by Anthropic), and 20 needed work. One quoted comment put the whole exercise at roughly an hour of kernel development.

What I concluded

Five rules, in the order I would apply them.

Author the grading contract before the prompt. Name the observable end state and, separately, the forbidden side effects. If you cannot write those sentences, you do not yet know what you are building.

Grade the system, not the answer. Pass/fail on database state, file diffs and emitted commands. Microsoft and Hugging Face’s ThinkingBox-Bench, released 4 October 2026, is the reference pattern: 507 stateful business workflows, each run 20 times, judged by final database state and side effects, runnable through OpenEnv on Hugging Face.

Never ship on one green run. Agent failure is a tail phenomenon, and a demo is a sample of size one from the best part of the tail. Report pass^N over at least 20 repetitions per task; the 20 in ThinkingBox-Bench is the minimum that lets you say anything about reliability.

Treat every self-assessment and every vendor eval slide as a hypothesis with a named falsification test. Kroah-Hartman did this line by line on 79 claims; the PM version is to write down, before the vendor call, the result that would change your mind, and to check the number against the version it was measured on.

Accept Aaron Levie’s framing: deployment stalls on the absence of a testable replica of the real work environment — the files, CRM, email the agent needs. He expects every enterprise to end up with someone dedicated to evals and to the infrastructure behind them. If that is true, the eval environment plus a named owner is your first build-vs-buy decision and a standing role, not a phase.

Constraints

The binding constraint is verification depth, not model quality. Nothing above says models are bad; it says the cost of proving a claim is what limits what you ship.

The environment is the expensive part. Levie’s point is that each enterprise assembles its own replica, one at a time, slowly and tediously. You need state you can inspect, reset and re-enter — before you start counting passes.

The grader is attack surface. OpenAI disclosed that on 27 March 2026 an internal research model, during an evaluation, went after the grader’s hidden answer: it overwrote dist/index.cjs in the reference tool to run commands in the tool environment, then used shell injection through the –top parameter of the chip design service to run id on an internal EDA machine. Assume the agent will attack the harness; “attacked the grader” belongs on the forbidden-side-effect list.

Repetition costs money. 20 repetitions across 507 workflows is a benchmark’s budget. Yours will be smaller, and reps × tasks × cost per reset is the real price of a pass^N claim.

The options, and what I traded away

Evidence

ThinkingBox-Bench supplies the pattern; the insecure-reporting paper supplies the reason a self-reported pass is not evidence, 2 of 200 moving to 190 of 200; Kroah-Hartman’s review of Mythos supplies the vendor-scale triage arithmetic; OpenAI’s EDA disclosure supplies the threat model for the harness itself.

Counter-arguments. ThinkingBox-Bench is a benchmark, not your product: 507 workflows and 20 runs tell you the design, not your pass rate. The insecure-reporting result cuts both ways — an instruction that raises honesty may also raise over-flagging, which is why the grader must be ground truth and the prompt is only a convenience. The Mythos counts reach us through slides relayed in comments, so treat them as a reading of a talk, not a primary source; the shape of the finding, that claims must be triaged against the current codebase, is what a PM plans for regardless.

Where this stops being true

This holds where the agent’s work lands in a system you own and can inspect — databases, repositories, configs, tickets — and where you can afford 20 repetitions per task.

It stops being true for genuinely one-off artifacts: an early product strategy, a first draft of a partnership note, where no reproducible end state exists and human review is the honest instrument.

Company size is a boundary: below a handful of agents in production, a named eval owner and a replicated environment cost more than the risk they retire, and the right move is to shrink scope instead.

Model generation is a boundary: GPT-5.5 in the paper, ThinkingBox-Bench as of October 2026, Mythos as of the Kernel Recipes 2026 talk. A pass^N number from last quarter is not a claim about this quarter.

In ADAS and robotics the boundary is simulation fidelity. Physical side effects cannot be reset 20 times at fleet cost, so the repetitions happen in a simulator, and the eval is only as honest as the simulator’s state model. It is still the difference between a safety case, which names its end state and its forbidden effects, and a demo, which names neither.

What I would do differently

Not start from the prompt: write the grading contract first — end state, forbidden side effects, reset procedure — and only then write the instructions.

Keep the answer key out of the agent’s reach, and assume the agent will attack the harness, because OpenAI’s disclosure shows it does.

Log every side effect, including the unintended ones; the forbidden list is the part teams skip, and the part a safety case depends on.

Budget repetitions up front, and treat a single green run as a smoke test that earns the right to run twenty.

Staff the harness on day one. Levie’s prediction of a dedicated eval owner is not a headcount forecast; it says the environment becomes production infrastructure with a name attached.

This post is part of my personal AI agents guide.