# Agent Tool Retry and Idempotency
Status: public
Confidence: medium (0.725) (verified)
Last verified: 2026-06-02
Generation: ai_structured


## TL;DR

Agent tool retry and idempotency define how an agent repeats failed external calls without duplicating payments, writes, tickets, messages, or other side effects.

## Core Explanation

Retries are necessary because network calls, APIs, and long-running jobs fail transiently. Idempotency is necessary because an agent may not know whether the previous call failed before or after the server performed the action.

Reliable agent runtimes classify errors, retry only safe operations, use idempotency keys for writes, cap attempts with backoff, and expose retry history in traces. Tool schemas should document whether a call is read-only, idempotent, or side-effecting so the model cannot turn every failure into an unsafe loop.

## Source-Mapped Facts

- Stripe idempotent requests documentation says idempotency keys let clients safely retry creating or updating objects without accidentally performing the operation twice. ([source](https://docs.stripe.com/api/idempotent_requests))
- Temporal retry policy documentation says a retry policy is a collection of settings that tells Temporal how and when to try again after a workflow or activity failure. ([source](https://docs.temporal.io/encyclopedia/retry-policies))
- AWS Step Functions documentation describes Retry and Catch fields for handling errors in workflow states. ([source](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html))

## Further Reading

- [Stripe idempotent requests](https://docs.stripe.com/api/idempotent_requests)
- [Temporal retry policies](https://docs.temporal.io/encyclopedia/retry-policies)
- [AWS Step Functions error handling](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html)