Idempotency & Retries
Also: idempotent operations · retry safety · exactly-once effects · idempotency key
Designing agent actions so that safely retrying a failed or duplicated call produces the same effect as running it once.
Why CCAR-P tests this
CCAR-P tests reliability design — retries and duplicate tool calls are inevitable in loops, so effects must be safe to repeat.
An operation is idempotent when performing it multiple times has the same effect as performing it once. Because agentic loops retry on transient failures and models sometimes re-issue tool calls, non-idempotent actions (charge card, create order, send email) risk duplicate side effects.
The standard fix is an idempotency key: the caller attaches a stable unique id to the request, and the downstream service records it so a repeat with the same key is deduplicated rather than re-executed. Reads are naturally idempotent; writes need this protection. Design retries with bounded attempts and backoff, and distinguish retryable errors (timeouts, 429s, 5xx) from terminal ones (validation errors) that should not be retried.
This logic lives in deterministic code, not the prompt — the model can't be trusted to remember it already sent the email. Make the tool layer safe so that whatever the loop does, effects can't be accidentally doubled.
Exam trap
Assuming a retry is always harmless — retrying a non-idempotent write (payment, order, message) without an idempotency key duplicates the side effect, and hoping the model 'won't call it twice' is not a safeguard.
Commonly confused with
Related concepts
Independent, unofficial study material from Claude Cert Prep. Not affiliated with Anthropic.