A timeout does not always mean an operation failed. The remote system may have completed a write before the connection disappeared. Reliable agent retries therefore start by distinguishing a safe repeated read from an ambiguous write. A retry policy should specify a total deadline and a way to reconcile uncertainty.
The contract to define first
Give each logical action a stable identity where the provider supports it. Persist enough status to distinguish requested, pending, confirmed and failed work. Use bounded retries with delay and jitter for transient failures; avoid asking a model to improvise the policy on each turn. Stop when the task budget is exhausted and surface a recoverable state to the user.
A worked scenario
A proposed meal-log tool loses its response after submission. Retrying with a new action identity can produce two entries. Reusing the logical identity, or querying the provider for the original result, lets the workflow recover without pretending the first request never happened.
An implementation and review sequence
- Classify tools by side-effect and replay behavior
- Persist one identity per logical action
- Set a total deadline and a reconciliation path
Failure cases worth testing
| Condition or input | Expected behavior |
|---|---|
| Read returns a transient error | Retry within the remaining budget |
| Write response is lost | Check original status before replay |
| All retries expire | Show an unresolved state and support reference |
Download the illustrative acceptance checklist (JSON)
Tradeoffs and limits
Some providers cannot deduplicate or reconcile writes. In that case, uncertainty should trigger review rather than automatic replay. A clear pending state is safer than a confident duplicate.
Use the result to make a decision
The practical output is straightforward: specify retry budgets for read and write tools with duplicate-action tests. Keep the assumptions with the artifact so a product owner, implementer or prospective partner can review the same decision. A useful handoff states the supported scope, the evidence collected and the remaining dependency instead of treating a successful demonstration as proof of every operating condition.
Continue with related implementation detail
Related guide: Evaluate the tool action, not just the answer.
LLM fallback routing for production apps
Prompt injection through tool results
References and current platform requirements
MCP specification and tool contracts
Google Cloud: AI security and safety for MCP
Platform capabilities, programme terms and access conditions can change. Check the linked primary references against the version and account you actually use; the patterns above do not establish a provider approval, certification or universal compatibility guarantee.
Discuss the workflow
Bring one workflow, its systems, and the actions requiring human approval.
Explore the relevant AptixLabs service
When is retrying an agent action unsafe?
A timeout does not always mean an operation failed. Some providers cannot deduplicate or reconcile writes.
Which failure cases should be included in the review?
Include these explicit cases: Read returns a transient error: retry within the remaining budget; Write response is lost: check original status before replay; All retries expire: show an unresolved state and support reference.