Every eval is a test your agent has already seen

Most agents don't fail loudly. They say done.

That's not my opinion, it's the finding of the largest study I've seen on it. Laksh Advani looked at 9,876 tau2-bench runs across eight model families and 1,879 AppWorld runs across four, and put it plainly: "LLM agents can fail silently by asserting task completion when the environment state shows otherwise." How often? "45–48% of failures in single-control tau2-bench domains, 3% in dual-control telecom, and 75.8% among AppWorld self-assessing coding-agent trajectories." [1]

Three quarters of the failures in the coding runs were the agent grading itself and passing.

Why your own tests don't catch it

The obvious fix is to write evals. I did. I used the big models to help me write tests for my own PA agent, and it got very good at passing my tests, which turned out to be the whole problem.

A test the agent has seen is a test it can pass without being good. Every eval framework I know of, and I've used most of them, is a test you run on yourself, with cases you wrote, on a schedule you chose, graded by a judge you configured. That's fine for catching a regression you already know about. It tells you nothing about whether the thing is actually reliable, because the thing has been optimised, by you, against exactly that test.

Nate B. Jones wrote up his own version of this: "the agent never verified anything, but it sounded like it did." His conclusion is the right one. "We've been treating 'done' as a conversational cue when it should be a contract." [2]

The judge can't save you either

The next idea is to have a model grade the run. Advani tested that too, five judges, five prompting strategies, full task specs. "No configuration across 5 judges, 5 prompt strategies, and full task specifications exceeds AUROC 0.65 on tau2-bench, and the same judges reach only 0.54 AUROC on AppWorld." [1] That's barely better than a coin flip, and the reason is the judge reads the same confident closing language the agent produced.

Tessl put the wider point well: "If you are publishing or trusting eval numbers from a single LLM judge, you are partly benchmarking judge preference rather than model capability." [3]

Capability is not reliability

Even when the agent can do the thing, it often doesn't do it twice. Princeton's HAL group measured the gap: "Agents that can solve a task often fail to do so consistently. The gap between capability (pass@k) and reliability (pass^k) is substantial across all models." And it isn't going away with bigger models: "Despite 24 months of model development, overall reliability shows only small improvements over time while accuracy steadily climbs." [4]

Kanishk Patel called the shift in one line: the conversation "quietly flipped from 'look what an agent can do' to 'can we trust it to do it twice.'" [5]

And the public numbers are self-reported anyway

If you've been trusting leaderboards instead, that's worse. When Quesma independently re-ran one SWE-Bench Pro submission they had to note that "All SWE-Bench Pro Public scores are self-reported." [6] Cursor's own engineers found that "63% of successful Opus 4.8 Max resolutions retrieved the fix rather than derived it." [7] Daniel Kang's summary of the benchmark literature: "many current AI agent benchmarks are far from reliable." [8] Berkeley's RDI group, after exploiting eight major benchmarks to near-perfect scores, said what I'd put on the wall: "Don't trust the number. Trust the methodology." [9]

Ben Dickson's line explains why it happens: "AI agents can overfit to the benchmark in ways that don't translate to the messy reality of the real world." [10]

What actually changes it

Four things, and they have to come together.

The test has to be one the agent hasn't seen. Not a fixed suite it can be tuned against, a fresh draw every time, so the only way to score well is to be good.

It has to be sat again and again, unannounced. An agent that knows it's being tested can hold together for the window. One that gets hit at random on a Tuesday afternoon has to actually work. That's the reliability number, not the capability number.

It has to be graded on what happened, not what was said. Where a task has a checkable outcome, check the outcome. A payment either landed or it didn't. A file exists or it doesn't. A claim with no evidence behind it scores zero. That is the only grading that Advani's finding leaves standing, and it's how the harness-lift shows up too. Cameron Wolfe's framing is the right one: "we are evaluating the ability of the model and scaffold to work together." [11]

And it has to be someone else's test. Not because your tests are bad, but because a test the builder wrote and the builder runs is, structurally, self-report with extra steps.

This is what Verigent is. Your agent connects over MCP, pulls a probe it hasn't seen, and is scored on what it did. Several pulls a day, unannounced, every dimension in the battery re-sat each week, claims scoring zero, and a dated record on a public blockchain that anyone can check without trusting us. The mechanics are on the methodology page. The first run is free.

What it doesn't do

A score is a dated snapshot. It says what the agent could do, under that rubric, on that day, and it says nothing about what it will do with a malicious operator behind it. Receipts for what an agent actually did are a different layer, and people like VR.dev are building it, from the same starting point: "agents report success but system state tells a different story. The database row is still active." [12] You'll want both.

I'd still rather have a number somebody else measured than a green tick my own agent gave itself.

Sources

1. Advani, L. From Confident Closing to Silent Failure: Characterizing False Success in LLM Agents. arXiv:2606.09863. arxiv.org/abs/2606.09863
2. Jones, N. B. My honest field notes on the verification gap. natesnewsletter.substack.com
3. Tessl. Your benchmarks are lying to you and your judge is to blame. dev.to/tessl-io
4. Rabanser et al., Princeton HAL. Reliability findings. hal.cs.princeton.edu/reliability/findings
5. Patel, K. The Agent Hype Just Broke. The Reliability Reckoning Is Here. learnagentic.substack.com
6. Quesma. Verifying Blitzy's SWE-Bench Pro run. quesma.com
7. Jain, N., Cursor. Reward hacking is swamping model intelligence gains. cursor.com/blog
8. Kang, D. AI Agent Benchmarks are Broken. ddkang.substack.com
9. UC Berkeley RDI. Trustworthy benchmarks. rdi.berkeley.edu
10. Dickson, B. Why AI agent benchmarks are flawed. bdtechtalks.substack.com
11. Wolfe, C. R. Agent Evaluation: A Detailed Guide. cameronrwolfe.substack.com
12. VR.dev, Show HN. news.ycombinator.com/item?id=47322919