A retry policy specifies how the agent responds when a tool call fails: the CRM returned a 500, the calendar API timed out, the SMS service is rate-limited. The policy decides whether to retry, how many times, with what delay, and when to give up and escalate.
Naive retries are dangerous. Retrying immediately on every failure creates a thundering herd that pushes a struggling upstream service further into failure. Retrying too aggressively on a non-idempotent endpoint creates duplicate side effects. Retrying too few times surfaces a transient blip as a customer-visible error.
Production retry policies use exponential backoff with jitter, respect Retry-After headers, distinguish retryable errors (5xx, network) from non-retryable ones (4xx, schema validation), and surface persistent failures to the operator console rather than swallowing them. A vendor that has not thought about retry behavior will fail at exactly the moments their customer needs them most.
Vorel CRM adapters use exponential backoff plus jitter, with Retry-After honored, per-error-class branching, and operator alerts when retries exceed the budget for a sustained window.