Skip to content
ammaradam

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.

Agent workflowToolcreate ticket, key K1ticket created✕response losttimeoutretry, same key K1K1 seen: no new ticketoriginal result
With an idempotency key, a retry after a lost response returns the original result instead of repeating the action.

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 ClientToken in 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 actionSuggested handlingExample
Low-risk readRun automaticallyLook up an order
Reversible changeRun with limitsDraft a ticket
High-impact actionAsk a human, with contextIssue 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/}
}
Share

Comments

Sign in with GitHub to like this post or join the discussion.

Read next