LIMBO: frontier agents duplicate writes in 56-74% of episodes when the request was already in flight

arXiv 2609.29095 is the most useful agent paper I've read this month, and its usefulness comes from the variance decomposition, not the headline number.

The setup: 25,930 episodes, nine models, three production agent harnesses, twelve injected fault modes. Every episode graded against a ledger of committed side effects, so "did the payment actually go through twice" is a fact, not a judge's opinion.

Two regimes fall out. When the agent is told to act exactly once and an immediate read-back can reveal what happened, frontier models almost never duplicate a lost-ack write. 0.5%. And the model choice explains 53% of the remaining variance. Pick a better model, get a better outcome. Fine.

When the request is still in flight, or the transport delivers it twice, the same models duplicate in 56% and 74% of episodes. And the model explains almost nothing. The tool contract explains 81%.

Then the authors do the thing that makes this a design rule instead of a benchmark: they prove no verify-only policy is exactly-once under late commits. Not "performs poorly." Cannot be correct. If your only defense is the agent checking whether the write happened before retrying, there exists a commit timing that defeats it, and at scale you will hit that timing.

I've written the naive version of this. A tool that POSTs to an endpoint, gets a timeout, and the prompt says "if you're unsure whether it succeeded, check first." That's the policy this paper proves is unsound. The fix is boring and lives in the tool contract, not the prompt: every side-effecting tool takes an idempotency key the caller generates before the first attempt, and the server deduplicates on it. Stripe has done this since 2015. Agent tool authors mostly haven't.

Put this next to the trace-deletion paper and you get one lesson from two directions. The agent's report about what it did is not the record of what it did. Once you accept that, a lot of agent architecture decisions resolve themselves: the ledger is external, the trace sink is external, and the guarantee lives in the contract the agent calls, not in the language you use to ask.

One more from the same family. arXiv 2609.29921 built SpecHarness over 509 source-grounded requirements from SkillsBench. Seven models satisfied 79.6 to 86.4% of the requirements. Their completion-claim rates exceeded official pass rates by 28.7 to 37.9 percentage points. The design response is sharp: the agent can request completion but cannot declare it, and only admissible evidence from a qualified provider marks an obligation satisfied. If you have an agent closing tickets or merging PRs on its own signal, that gap is your false-completion rate.