# Idempotency & Retries

Designing agent actions so that safely retrying a failed or duplicated call produces the same effect as running it once.

## Why the CCAR-P exam tests this

CCAR-P tests reliability design — retries and duplicate tool calls are inevitable in loops, so effects must be safe to repeat.

## Definition

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

- **human-in-the-loop-gate** — A HITL gate prevents an action until approved; idempotency makes an action safe to repeat once it does run.

## Related

- agentic-loop
- human-in-the-loop-gate
- batch-vs-synchronous
- error-handling
- tool-design

---

Source: Claude Cert Prep — an independent, unofficial CCAR-P study resource (domain P1). Not affiliated with Anthropic.