When a tool call times out, did it happen?
A timed-out tool call may still have completed, so retrying safely needs the familiar distributed-systems tools: idempotency keys, durable state and verification.
The idea in brief
When an agent's tool call times out, the action may have succeeded without the response arriving. A blind retry could create a second ticket or repeat a payment. This is a long-standing distributed-systems problem, and the established answers apply to agents too.
Idempotency keys
AWS's Builders' Library article "Making retries safe with idempotent APIs" (2021) describes the approach used across many AWS APIs:
- The caller sends a unique client request identifier, such as
ClientTokenin EC2, and reuses it on every retry. - The service records that identifier atomically with the change it makes.
- A retry with the same identifier gets a response equivalent to the original, instead of a second action.
- Reusing an identifier with different parameters is rejected as a validation error.
For agents, the identifier needs to be created by the workflow before the tool call, not by the model, so a retry carries the same key.
Durable execution
In The AI Kubernetes Show episode on durable execution, Mark Fussell, creator of Dapr, describes runtimes that save state at each step so a crashed process can resume from its last completed step. He suggests keeping workflows deterministic where possible and using the model only for the decisions that need it.
Check before retrying
Emerson Braun's Conf42 Observability 2026 talk makes a related point: treat failures as states, classify them (a timeout is not the same as an invalid result), verify what actually happened, and only then retry, reroute, compensate or escalate. The talk's demo used a status check after a timeout to confirm that a refund had already gone through.
Matching autonomy to risk
The same talk suggests bounding how much an agent may do on its own by the risk of the action:
| Kind of action | Suggested handling | Example |
|---|---|---|
| Low-risk read | Run automatically | Look up an order |
| Reversible change | Run with limits | Draft a ticket |
| High-impact action | Ask a human, with context | Issue a refund |
Limitations
Not every tool supports idempotency.
Wrapping a tool that can't deduplicate may need a separate record of what was attempted.
Keys need a retention window.
AWS ties retention to the resource lifetime plus a buffer; too short and late retries slip through.
Durable runtimes add moving parts.
They help with recovery but bring their own operational overhead.
Sources
Cite this post
Adam, Ammar. (Sep 2026). When a tool call times out, did it happen? www.ammaradam.dev. https://www.ammaradam.dev/posts/tool-call-timeouts/.
BibTeX
@article{adam2026toolcalltimeouts,
title = {When a tool call times out, did it happen?},
author = {Adam, Ammar},
journal = {www.ammaradam.dev},
year = {2026},
month = {Sep},
url = {https://www.ammaradam.dev/posts/tool-call-timeouts/}
}
Comments
Sign in with GitHub to like this post or join the discussion.