Principle
Retry after a state change; replan after the same failure
A retry is justified by changed conditions; otherwise it is often just repetition.
When it fits
- A tool call or action fails and the default response is to immediately repeat it.
When to avoid it
- Some failures are probabilistic even with unchanged visible state; use bounded retries informed by service behavior.
Why it matters
After failure, identify whether the environment changed: transient service error, refreshed credentials, corrected parameters or new input. If yes, retry within a bounded policy. If the same deterministic failure remains, change the plan or tool choice instead of spending another attempt on the same path.
An example
Retry a rate-limited API after backoff; do not resend the same invalid schema payload five times.
Check your result
Retries have a reason tied to changed state rather than hope.
Keep this limit in mind
- Some failures are probabilistic even with unchanged visible state; use bounded retries informed by service behavior.
Connected ideas
Useful withRetry slower, with randomness, and stop
Evidence and sources
Supports
Long-running agent guidance emphasizes bounded loops and actionable tool errors that steer agents toward corrected inputs rather than opaque repetition.
Some failures are probabilistic even with unchanged visible state; use bounded retries informed by service behavior.
Writing effective tools for AI agents—using AI agents · See source record