Spot the idempotency violation in this agent retry logic

The bug is that the retry loop calls `tool.execute(args)` again and again whenever the result does not say success, without ever asking whether running the tool twice is safe. For a read-only tool that is fine. Fetching a web page or reading a row twice changes nothing. The property that makes this safe is called **idempotency**: doing the action more than once has the same effect as doing it once. The trap is tools that are not idempotent. A `charge_payment` tool moves real money. A `send_email` tool sends a real message. If the first attempt actually succeeded but the response got lost on the network, the result will not show success, so the loop retries. Now the customer is charged twice or gets two emails. The real danger is that a failed-looking result does not prove the action failed. A timeout often means the work happened and only the reply was lost. Blindly retrying turns one lost reply into a second real side effect. The fix is to send a unique idempotency key with each request. The server records that key, and if a retry arrives with the same key, it returns the original outcome instead of charging again.

The defect is a missing **idempotency** check before retry. The loop reruns `tool.execute(args)` on any non-success result, with no regard for whether the tool has side effects. For pure reads this is harmless. For state-changing tools it is dangerous. A charge, an email, or a record insert is a real-world effect. A timeout or dropped response makes a succeeded call look failed, so the loop fires the effect a second time. The result is double charges and duplicate messages. The correct design separates two questions. First, was the failure transient or permanent? Only transient failures should retry, with backoff. Second, is the operation safe to repeat? Naturally idempotent tools can retry freely. Non-idempotent tools need an idempotency key. The caller generates a stable key, attaches it to every attempt of the same logical request, and the server deduplicates. A repeat with a seen key returns the original outcome rather than re-executing. This gives at most once side effects on top of at least once delivery.