Add configurable retry-with-backoff for tool execution failures

Feature Area

Integration with external tools

Is your feature request related to a an existing bug? Please link it here.

NA

Describe the solution you'd like

Currently, when a tool execution fails because of a transient error such as a timeout, rate limit, or temporary network failure, the failure can propagate immediately.

I would like to propose an optional retry mechanism for tool execution with exponential backoff.

The feature could provide configuration such as:

• max_retries: maximum number of retry attempts.
• backoff_factor: controls the delay between retry attempts.

For example, with max_retries=3, a failed tool could be retried up to three times before the original exception is raised.

The default could remain 0 retries to preserve backward compatibility.

The retry behavior should be isolated and testable, and ideally should only retry appropriate transient failures rather than every possible exception.

Describe alternatives you've considered

One alternative is for individual tools or users to implement their own retry logic.

However, this can lead to duplicated retry implementations across tools and inconsistent behavior.

A centralized, optional retry mechanism would provide a consistent approach while allowing users to disable retries by keeping the default at zero.

Additional context

This feature would be particularly useful when CrewAI agents interact with external APIs and services where temporary failures are common.

Example:

Agent → Tool → External API → timeout

Instead of immediately failing, the tool execution could retry:

Attempt 1 → failure → wait → retry
Attempt 2 → failure → wait longer → retry
Attempt 3 → success

The exact API and implementation details can be discussed with the maintainers before implementation.

Willingness to Contribute

Yes, I'd be happy to submit a pull request

Start by tracing the tool execution path and reviewing how timeout, rate-limit, and network exceptions are currently propagated. Clarify the configuration API, retryable failure types, and backoff behavior with maintainers, then add focused tests showing retries, delays, default zero retries, and final exception propagation.