On this page
The short answer
Treat a tool timeout as missing confirmation, not proof that the tool did nothing. Evaluate recovery against the tool’s operation ledger, retry contract, and remaining task deadline. The agent should distinguish a safe read retry, an uncertain write, and an expired task rather than applying the same fallback to every timeout.
What to take away
- Separate read timeouts from uncertain writes.
- Reserve time for reconciliation within the task deadline.
- Keep late completions visible in the evidence.
Sources checked . Research synthesis and Rubrex recommendations. Examples and local experiments are labeled; they are not client results.
Classify the boundary that timed out
LiteLLM documents retries and fallback groups as separate mechanisms. For an agent’s business tools, Rubrex recommends a more specific question: did the timeout happen before admission, while processing, or after commit but before acknowledgment? The workflow often cannot infer that distinction from the exception name alone.
Use a synthetic inventory assistant with two tools: read stock and reserve stock. A read can usually be repeated under its access and work limits. A reservation may require checking a stable operation identifier before another attempt. State these recovery contracts in the adapter rather than asking the model to invent them.
Evidence: LiteLLM: Life of a Request [1]
Create delayed responses with different actual outcomes
Run a stock read that returns late, a reservation that never enters the ledger, and a reservation that commits before the response is delayed. Keep the same visible timeout for the last two cases. This forces the evaluator to inspect authoritative state rather than rewarding an answer that merely sounds confident.
Add a task deadline shorter than the slow service response. When the deadline expires, record whether new work stops and how the agent communicates remaining uncertainty. A fallback that starts another reservation after the caller has abandoned the task can increase ambiguity instead of recovering the intended outcome.
Check the reconciliation path and remaining budget
For each uncertain write, inspect the receipt lookup or operator handoff used to resolve it. Record the number of provider and tool attempts, remaining deadline, committed reservation, and final message. Include a failed reconciliation service so the application must preserve an unknown state rather than manufacture a success or a clean failure.
Report recovery outcomes by operation type. Successful read retries should not conceal duplicated reservations. Count late commits even if the agent already returned a timeout response, because those commits still affect the user’s workflow and may require a follow-up correction.
| Case | Evidence to retain | Acceptance condition |
|---|---|---|
| Read delayed | Attempt history | Bounded repeat or useful timeout |
| Write committed, reply lost | Reservation receipt | Reconcile before repeat |
| Reconciliation unavailable | Unknown-state record | No invented final outcome |
Choose retries according to operation semantics
Accept the reservation path only when the tested ambiguous outcomes are reconciled or explicitly handed off before another conflicting write. For the read path, bounded retries may be appropriate if they preserve access rules and fit the remaining deadline. Stop when another attempt cannot plausibly meet the task contract.
Retain a recovery record containing the task, operation identifier, confirmed facts, unresolved state, and owner. Tune timeouts using observed service behavior after correctness is established. Increasing a timeout can reduce one symptom while leaving an unsafe duplicate-write path intact; the acceptance decision should address both timing and state.
Limits of the evidence
The inventory examples and recovery checks are proposed, not measured results. Actual adapters expose different status and cancellation mechanisms. This article does not prescribe provider-specific retry syntax or establish that a timed-out external operation can be reversed.
Common questions
Is every timeout retryable?
No. Retryability depends on operation semantics, deduplication, access, and remaining time.
Can the agent say the action failed?
Only when the system can establish failure; otherwise explain that completion is unconfirmed.
Sources & further reading
Primary sources behind this briefing. A source’s findings apply to its own study conditions; publication on arXiv does not establish peer review.
- LiteLLM: Life of a Request LiteLLM · Living reference · Maintained documentationReviewed: documented gateway request lifecycle and retry-versus-fallback distinction. Accessed October 16, 2026.
Questions or corrections? Write to Rubrex. Read our editorial approach.