An operation is idempotent when performing it twice has the same effect as performing it once. For agents — whose retries are frequent, automatic, and sometimes invisible — idempotency is the difference between resilience and duplication.

Agents retry more than any software humans have ever built. A flaky network, a provider 429, a timeout on an operation that actually succeeded — every one triggers a re-execution of the same intent. If that intent is "create a Stripe charge" or "append a row," the retry produces a duplicate the user can see. The old distributed-systems joke lands hard here: at-least-once delivery plus at-most-once semantics equals zero guaranteed executions — unless operations are built to be safely repeated.

The toolkit is classic. Idempotency keys: the agent derives a stable key from (run_id, step_index, intent_hash) and the receiving system deduplicates on it — Stripe's API made this mainstream. Conditional writes: put-if-absent semantics so "create the deployment job" becomes a no-op when it already exists. Natural keys over counters:"set config timeout=30" instead of "increment timeout by 10." Wherever possible, prefer actions phrased as declarations of desired state over imperatives — the former are naturally idempotent, the latter inherently not.

The Audit Questions

• Which agent tools are safe to retry today — and how do you know?
• Where does the agent generate identifiers, and would a regenerated ID after a crash orphan prior work?
• Which side effects are irreversible, and are they fenced behind explicit human gates?
• Does the execution log record attempt counts, so a "successful" run that silently tried five times is visible?

None of this is glamorous, and that is precisely the point: idempotency is the pattern that makes every other pattern — retries, sagas, event-driven runs — safe to turn on. It should be a default, not a retrofit.