For AI agents: The documentation index is at https://docs.digitalocean.com/llms.txt. Markdown versions of pages use the same URL with index.html.md in place of the HTML page (for example, append index.html.md to the directory path instead of opening the HTML document).

Action Gateway applies each tool’s configured execution policy to transient provider failures. Smart retries limit which failures can be retried, how long to wait, and whether repeating the provider operation is safe. They do not make every tool call retryable.

Smart Retries

Eligible tools can retry configured failure classes, such as rate limits, upstream server errors, timeouts, or transport errors. Retry behavior is part of the tool’s catalog configuration, not a session permission rule or an instruction from the model.

Retries remain bounded by the tool’s attempt limit and the request deadline. The executor applies the configured backoff and jitter, and honors a provider’s Retry-After delay when the policy enables it. Cancellation or insufficient remaining time can stop retries before the attempt limit.

A tool without a valid retry policy makes one provider attempt. Validation errors, missing connections, and policy denials require corrective action rather than repeated calls.

Idempotency

An idempotent operation can be repeated without applying its intended effect more than once. The gateway permits automatic replay only when the tool’s configuration establishes an appropriate safety contract, such as a read-only operation or provider-supported idempotency keys.

For tools configured with a provider idempotency-key header, Action Gateway generates a key for one logical invocation and reuses it across that invocation’s automatic retries. The provider uses the key according to its own idempotency contract.

A new action_invoke request or a re-run of action_code is a new invocation. It does not automatically share the earlier invocation’s idempotency key. Do not treat a timeout as proof that a write failed: the provider may have completed the operation before the response was lost.

Recovery After Failure

Inspect each tool’s result and recovery guidance. When retries for a provider-idempotent write are exhausted, the gateway can direct you to verify the provider’s state before submitting another invocation.

For writes, check whether the intended resource or action already exists before retrying manually. For a parallel batch, retry only the appropriate failed calls rather than repeating successful ones. For a code workflow, identify which steps completed before re-running the program.

Use Action Gateway Insights to investigate failures and latency. Successful retries do not turn a multi-tool workflow into a transaction or guarantee exactly-once execution across separate requests.