← All guides · Agent reliability in production

How to Set Timeouts for AI Agent Tool Calls

Part 9 of Agent reliability in production · 1,434 words · ~7 min read · published 2026-08-30 · updated 2026-08-30 · Markdown variant

A deep-dive on timeout and deadline design for AI agents: sizing LLM-call, tool-call, and sub-agent-hop timeouts differently, allocating a wall-clock budget across a multi-step chain, and propagating a remaining-deadline value from parent to child calls.

Part of the Agent Guardrails and the AI Agent Reliability Playbook guide.

The agent reliability in production pillar states in one paragraph that every agent step needs an explicit timeout and that the total retry-plus-timeout budget has to fit inside whatever SLA the caller imposes. What that paragraph has no room for is the mechanics: sizing a timeout per step type, splitting a wall-clock budget across a chain of steps, and passing that budget from a parent call down to its children — the three gaps this piece fills.

Why doesn't one global timeout work for an agent chain?

One global timeout fails an agent chain because its steps do fundamentally different kinds of work: a value sized for the slowest step wastes time everywhere else, and a value sized for the fastest step kills the slowest ones outright. A typical run mixes LLM calls, tool calls, and sub-agent hops, each with its own latency profile — treating them as interchangeable either lets a stuck LLM call stall the whole run or cancels a legitimately slow tool call at a ceiling meant for a fast one. Size each step type from its own worst case, not one number copied down the codebase.

Sizing an LLM-call timeout

An LLM-call timeout should account for model inference being an I/O-bound network call with genuinely variable latency, not a fixed-cost operation — a well-behaved agent tracks its remaining RPM/TPM headroom from the provider's rate-limit response headers and self-throttles before sending a call, so a legitimately slow inference isn't confused with a self-inflicted wait for capacity, per handling rate limits and retries. Calling a model through a gateway adds a further hop — typically under 10 milliseconds under normal load, more under heavy load, per AI gateways and LLM routing — and the gateway itself fails an unresponsive provider over to a secondary one on a timeout, so a missed deadline there should often trigger a failover, not a full escalation.

Sizing a tool-call timeout

A tool-call timeout has to be set per tool, because tools span compute-bound work (a local schema check, milliseconds) through I/O-bound calls (an external API, seconds) to inherently slow batch operations (a multi-file conversion job, a long-running web crawl). There is no shared worst case across a toolset the way there roughly is for LLM calls against one provider — size each tool's ceiling from that tool's own observed latency, not a value borrowed from a neighbor.

Sizing a sub-agent-hop timeout

A sub-agent-hop timeout has to cover more than the round trip to reach it — it's the sum of whatever LLM and tool calls the sub-agent runs internally, plus the hand-off itself. Multi-agent orchestration patterns documents that message passing "increases latency per hop" versus shared-state designs, and that coordination overhead grows with depth in a hierarchical manager-of-managers pattern — a hop's timeout in a multi-tier system has to budget for everything nested underneath it, not just the network round trip.

How do you allocate a wall-clock deadline budget across a multi-step chain?

Allocating a wall-clock deadline budget means splitting a chain's total SLA into per-step reservations and decrementing what's left as each step completes, rather than letting every step draw against the full original total independently. Treat the budget as one pool: step one draws its reservation, and whatever remains — not the original total — is what every later step actually has to work with. A step that overruns eats into everything after it, which is the point: it forces the chain to fail fast rather than silently exceeding the caller's SLA.

Two reservations are easy to skip:

• Reserve retry time inside each step's slice, not on top of it. The backoff schedule in handling rate limits and retries can consume a real share of a step's budget across several attempts before it ever returns; shipping AI agents to production makes the same point structurally — a max retry count paired with a circuit breaker is what stops a degraded dependency from eating a reservation and then some.
• Exclude durable pauses entirely. Corpus guidance, current as of August 2026, implements a human-approval gate as a durable pause rather than a timeout (shipping AI agents to production) — an indefinite wait for a person to act, which should sit outside the clock rather than count against it, resuming the countdown only once the workflow picks back up.

A per-session token budget — the corpus's standard cost control against runaway spend — is the nearest analogue: a wall-clock budget applies that same reserve-and-decrement discipline to time instead of tokens.

How do you propagate a deadline from a parent call to a child call?

Deadline propagation carries a remaining-budget or absolute-deadline value from a parent call into every child call it spawns, so the child starts with what's genuinely left instead of a fresh full-length timeout of its own. Skip it, and a multi-hop chain where each hop applies its own maximum timeout can silently total far more wall-clock time than the caller's SLA allowed, because no hop knows how much the hops before it already spent. The carrier for that value already exists in the corpus for a related purpose: multi-agent orchestration patterns calls for propagating a shared trace_id across every subagent call so cross-agent debugging is possible at all. The same call that carries that trace ID to every child hop is the natural place to carry a remaining-budget value beside it, computed once at the top and decremented by each hop's own elapsed time rather than recomputed independently at every level.

Why a durable workflow can't just read the clock to check its deadline

A durable execution workflow can't check its remaining deadline by calling the wall clock directly, because durable execution for long-running agents requires replaying a workflow from its stored history to reschedule the identical steps every time, given the identical recorded inputs. A raw clock read breaks that: it returns a new value on every replay, so a workflow checking the clock for a deadline could reschedule differently on the same logical run purely depending on when the replay executed. The fix is the one already applied to every other non-deterministic operation here — push the clock read into a separately recorded activity or step, capture its result once, and let every later replay reuse that stored value rather than asking the clock again. The recorded-activity pattern itself, and how each engine implements it, gets its full treatment in when do AI agents need durable execution.

A three-hop budget allocation example

Treat every number below as an illustrative, tunable starting point, not a prescription. A chain with a 30-second total SLA might reserve 10 seconds for an LLM planning call, 15 for a tool call to an external API, and hold 5 as shared contingency rather than a fixed reservation for the final step. A planning call that finishes in 6 seconds folds its unused 4 into the contingency pool instead of losing it. A tool call that retries and burns 18 of its 15 seconds spends that contingency instead, leaving the final step a near-zero budget — the correct outcome: a fast, deliberate failure rather than quietly running past what the caller agreed to wait.

Common timeout-design mistakes in agent chains

Four mistakes recur across agent chains that get timeout design wrong, and each one traces back to skipping the sizing, allocation, or propagation mechanics above rather than to a single bad timeout value.

• Copying a single timeout across every step type, regardless of that step's own latency profile.
• Giving every hop a fresh full timeout instead of a propagated remaining budget, so total chain latency loses any relationship to the stated SLA.
• Counting a durable human-approval pause as ordinary step latency instead of carving it outside the clock entirely.
• Ignoring a gateway hop's own overhead when sizing the downstream provider timeout that sits behind it.

Where this leaves you

Size an LLM-call, a tool-call, and a sub-agent-hop timeout from that step's own I/O-versus-compute profile, reserve and decrement a wall-clock budget across the chain instead of letting every step draw against the full SLA, and propagate the remaining budget from parent to child alongside the trace ID the run already carries — excluding durable human-approval pauses from that budget entirely. For the other eleven reliability disciplines this sits inside, see agent reliability in production; for what to do once a timeout leaves a call's outcome genuinely unknown, see how to make AI agent retries idempotent; for the checkpoint mechanics a durable workflow's crash recovery depends on, see when do AI agents need durable execution.

#agents #reliability #timeouts #deadlines #multi-agent #production