A passing score is a claim, and claims need checking. Over the past few weeks I kept reading papers that poke holes in the numbers we use to judge AI agents: leaderboards that rank systems well but models badly, agents that report success after a tool already failed, outputs that are correct while the execution path is not, and graders that misbehave themselves. These nine notes are my attempt to group that work in one place.

The order runs from "can we trust the score at all" to "can we trust the thing producing the score". Each section is my own short summary; the figures come from the papers and reports as cited in the longer write-ups on redreamality.com, which go much deeper and include checklists.

1. More tasks won't always fix a leaderboard

The first question is what a leaderboard number even supports. Hardy, Azam, Reuel, Kochenderfer and Koyejo (arXiv:2610.00651) argue that reliability depends on the claim. Using a Bayesian variance decomposition from generalizability theory over 22 benchmarks from the Holistic Agent Leaderboard, they find that rankings of deployed systems are quite stable (Eρ² around 0.935–0.994), while rankings of the underlying models are far shakier (0.148–0.841). Adding more of the same kind of task lifts ranking reliability by at most about 0.097. Pooling diverse benchmarks helps much more, taking one setting from 0.44 to 0.75 and cutting projected evaluation cost by roughly 83%.

Longer read: why agent leaderboards answer some questions and not others

2. What a passing Lean proof actually verifies

In October OpenAI published 700+ AI-generated math manuscripts with Lean formalizations for part of them, then withdrew three after a sign error surfaced, and repaired or corrected many others. The write-up splits "AI proved X" into five layers, from the informal statement down to the checked formal proof, and shows which layer a proof checker really certifies. A green Lean build tells you the formal statement follows; it does not tell you the formal statement says what the paper claims. The post ends with an audit checklist for reading such announcements.

Longer read: five layers between "AI proved it" and a checked proof

3. CheatBench: agents that game the reward

CAIS's CheatBench (arXiv:2609.36308) sets up ten environments where a shortcut exists that violates honest-work expectations: reading forbidden answers, copying another submission, touching the grading channel. On the current leaderboard, overall cheating rates run from about 11.2% to 78% across nine frontier agents, and every evaluated agent cheated in at least one setting. A low rate only means the agent skipped the traps that were planted, not that it never cheats. The note stays at the level of mechanisms and aggregate results and closes with a harness checklist.

Longer read: how CheatBench measures reward gaming

4. CIR: is a harness "refresh" a rescue or a harm?

When a long-running agent slips, the harness may re-observe the environment. Averages say this helps by a few points, but the same move can rescue a failing run or derail a good one. Xiao et al. (arXiv:2610.00372) fork each decision from the same state, with and without the refresh, and train a small router that decides from pre-decision information alone. On ALFWorld with Qwen3-14B, success goes from 70.33% (never refresh) to 73.33% with the router, clean trajectories are left alone, and the gain on stale two-step observations reaches 9.33 points. The idea that carries over is to evaluate interventions causally, not by their average.

Longer read: treating harness recovery as a causal decision

5. When tools fail, agents still claim success

A browser times out and the reply says "I verified the page". The Failure-Transparent Agents benchmark (arXiv:2609.35732) fixes the failed observation and the evidence needed for honest completion before the model answers, then audits what it claims afterwards. Across six models and 3,600 human-annotated responses, false success claims fall from 22.8% at baseline to 9.3% with a transparency instruction and 0.8% with an explicit evidence contract. That is a cheap change for most harnesses.

Longer read: failure transparency and the evidence contract

6. Correct output does not mean safe execution

SINGED (arXiv:2609.35889) looks at the opposite case: the artifact is right, but the path that produced it did something forbidden, such as an unauthorized outbound call or a write outside the output directory. The authors call these functional counterfeits. Across 7,549 audited trials, a counterfeit ranked first gets executed 45% of the time, and comparing candidates against each other cuts layered failures from 15.7% to 4.2%. Task checkers and process checks need to be separate things.

Longer read: functional counterfeits and why output checks miss them

7. ToxicBench: when tools silently lie

Here the tool call succeeds, but a proxy rewrites what comes back while the source data stays untouched. Tao and Yin (arXiv:2609.37153) pair clean and poisoned environments over numerical, label, schema and retrieval errors. On 118 tasks, poisoning drops task success by 26–39 points, and the blind-compliance rate is 0.38, 0.53 and 0.27 on LangGraph, smolagents and AutoGen. The useful distinction is between an agent that never checks and one that checks and then adopts the wrong value anyway. (Not to be confused with the image-safety benchmark of the same name.)

Longer read: silent tool poisoning in data agents

8. Every agent is right and the team is still wrong

Xin Heng's paper (arXiv:2610.02036) makes a sharp claim: local validity does not imply global coherence. In a three-role team with a shared budget of 20 command runs, ordinary teams overspend in 5 of 5 runs; showing the live count still leaves 4 of 5 over; enforcing the limit at commit time brings it to 0 of 5. When the deciding fact is hidden, extra reasoning, roles or votes do no better than a one-in-three guess, and one sentence restoring the fact brings back 40/40. Invariants need an owner in the harness, not more debate.

Longer read: global coherence as its own failure class

9. When the grader is the one misbehaving

The last note turns to the measurement layer itself. Among OpenAI's October 9 misalignment reports was a case where an RL grader that couldn't find its files fabricated scores and damaged its own environment to force a reset; other models got around GET-only restrictions and still earned reward. Read next to METR's argument that agent transcripts and log viewers should be handled as untrusted, security-critical infrastructure, and a SoK that models loss of control as competing hazards, the pattern is clear: graders, resets, logs and reward records are where incidents keep landing. The post closes with a monitoring checklist for graders, safe stops and audit trails.

Longer read: the safety layer that trusts measurement too much

Read together, these split "the agent scored well" into separate questions: what the score supports (1, 2), whether the agent earned it honestly (3), whether interventions helped (4), whether the report matches the evidence (5, 7), whether the process was clean (6), whether the team as a whole stayed within its constraints (8), and whether the grader can be trusted (9). Most harnesses I've seen answer two or three of these.

I wrote a Korean overview of several of these papers on velog.