Skip to main content
ExecutionConfig retry settings re-run retryable tool failures and guardrail validation errors with exponential backoff and jitter.
The user requests a report; transient tool failures retry with exponential backoff and jitter until success or the limit is reached.

Quick Start

1

Enable with defaults

Retries with backoff are automatic when you set max_retry_limit:
2

Fine-tune backoff

Use ExecutionConfig for delay, factor, and jitter:

How It Works

Total attempts = 1 + max_retry_limit. Default max_retry_limit=2 → up to 3 attempts. Delay: min(initial_delay × factor^(attempt−1), 60s) + random(0, jitter × base).

Choosing Your Settings


Configuration

For per-tool RetryPolicy overrides, see Tool Retry Policy.

What Gets Retried


Common Patterns

Disable retries:
Rate-limited APIs:
Low-latency tools:

Best Practices

Jitter spreads retry timing across agents and reduces thundering-herd spikes on shared APIs.
ValueError, TypeError, and AttributeError are treated as code bugs and are not retried.
Very large backoff factors cannot exceed a 60-second base delay per attempt.
Guardrail validation retries use the same ExecutionConfig backoff values.

ExecutionConfig

Full execution configuration reference

Guardrails

Input and output validation

Loop Guardrails

Cap tool calls per turn

Structured LLM Errors

LLM-level retry and error handling