Why architecture matters here
The architecture matters because in a graph of delegating agents, latency and failure compose, and an unbounded wait turns one slow node into a system-wide stall. Consider a planner agent that fans out to three sub-agents and waits for all three; if one of them calls a tool that hangs, the planner waits forever, holding whatever resources the task occupies, and its own caller waits on the planner. In a busy system, more requests pile up behind the stalled chain, connection pools exhaust, and a single unresponsive peer cascades into a broad outage. A deadline on every call is the circuit that stops this: the caller gives up after a bounded time, frees its resources, and returns a timeout error its own caller can handle, containing the blast radius to the affected branch instead of the whole graph.
The second forcing function is that timeouts must compose down a chain, which is what deadline propagation solves. If the top-level request has a 30-second budget and has already spent 10 seconds, the sub-call it makes should be given at most the remaining 20 — not a fresh 30 — because there is no point in a downstream agent working for 30 seconds on a request whose caller will give up in 20. Propagating a shrinking deadline down the chain ensures every agent knows the real remaining budget and does not do work whose result will arrive too late to matter. Without propagation, each layer sets its own independent timeout, deadlines stack instead of sharing, and the effective end-to-end bound balloons far beyond what any single layer intended.
The third reason is that a fired timeout without cancellation is a resource leak with correctness risk. When the caller abandons a wait, the remote agent, unaware, keeps working — an orphaned task consuming CPU, memory, and possibly making external calls. Worse, if that orphaned task completes a side effect (charges a card, sends a message, writes a record) after the caller has already retried, the effect happens twice. So timeout handling must include a cancellation signal that tells the peer to stop, and retries must be guarded by idempotency (keyed on the task id) so a re-sent task that the original is still processing does not double-execute. The timer, the cancellation, and the idempotency guard are a single system, not three separate features.
A fourth reason is that streaming and long-running agent tasks break the simple 'total time' timeout entirely. Many A2A interactions are not a quick request-response but a stream of partial results, or a long task that legitimately takes minutes. A fixed total-duration timeout would either kill valid long work or fail to detect a stream that has silently stalled. The right bound for these is a no-progress timeout: the caller expects a heartbeat or a token of progress within some interval, and the timeout fires only when progress stops, not when total time is long. Distinguishing 'taking a while but still working' from 'stuck' is essential for any agent system that does real, variable-duration work, and it is the reason a mature timeout architecture has more than one kind of deadline.
The architecture: every piece explained
Top row: setting and tracking the bound. The caller agent initiates a task and attaches a deadline — an absolute time by which it needs a result. The deadline budget is that bound expressed as remaining time: the total allowance minus what has already elapsed up the chain, so it shrinks as the request travels. The remote agent is the peer doing the work, which may be fast, legitimately slow, or stuck. The timer / watchdog on the caller side is what actually enforces the bound — a timer armed to the deadline that fires if no response arrives in time, independent of whether the remote agent ever acknowledges it.
Middle row: what happens when the bound lapses. Timeout fires means the caller stops waiting and treats the call as failed for now — it will not block any longer. Cancellation is the crucial follow-up: the caller signals the remote agent (via the protocol's cancel mechanism, keyed on the task id) to stop the abandoned work, so it does not run orphaned. Retry / fallback is the recovery policy — retry with backoff if the failure looks transient, or fall back to a degraded result, a cached answer, or a different agent if not. The idempotency guard makes retries safe: because the task carries a stable id, re-sending it lets the receiver deduplicate rather than execute twice, so a retry after a timeout cannot double-apply a side effect.
Bottom row: propagation and streaming. Deadline propagation is the discipline of passing the shrinking budget down every delegated call, so a sub-agent works only within the time its caller actually has left, and deadlines share rather than stack. Streaming vs unary is the mode distinction: a unary call uses a total-time deadline, while a streaming or long-running call uses a no-progress / heartbeat timeout that fires only when expected progress stops arriving, so legitimate long work is not killed. The ops strip names the signals that tune the whole system: timeout rate, p99 latency, retry-storm indicators, and counts of orphaned or duplicated work.
End-to-end flow
Trace a delegated call with a healthy timeout path. A top-level request arrives at a planner agent with a 30-second budget. The planner spends a couple of seconds reasoning, then delegates a research task to a sub-agent, propagating the remaining ~28 seconds as the sub-agent's deadline. The sub-agent, in turn, calls a tool agent, passing along the ~26 seconds it has left. Each layer arms a watchdog to its own deadline. The tool agent returns in three seconds, the sub-agent finishes and returns to the planner, and the planner assembles the answer well inside its budget. No timeout fires; the deadline propagation simply ensured every layer knew the shared budget and would have bailed out in time if anything had stalled.
Now the stalled case. The tool agent this time calls an external API that hangs. The tool agent's own watchdog — armed to the propagated deadline — fires first: it abandons the external call, signals cancellation to the API layer, and returns a timeout error up to the sub-agent. The sub-agent receives a clean, prompt failure rather than hanging until its own deadline, and it can decide whether to retry the tool call (with backoff), try a different tool, or return a partial result to the planner. Because the deadline shrank down the chain, the failure surfaced quickly at the layer closest to the problem, instead of every layer independently waiting out a long fixed timeout and the total blowing past 30 seconds.
Consider the side-effect hazard. Suppose the delegated task was 'submit an order', and the caller's timeout fires while the remote agent is midway through submitting. The caller cancels and retries against a possibly-different instance. Without an idempotency guard, the order could be submitted twice — once by the orphaned original that completed just after cancellation, once by the retry. With the guard, both attempts carry the same task id; the order service (or the agent) deduplicates on that id, so whichever arrives first wins and the second is recognized as a duplicate and ignored. The timeout-and-retry loop stays safe precisely because cancellation plus idempotency together ensure at-most-once effect even though the network delivered the request more than once.
Finally a streaming task. An agent requests a long analysis that streams partial results, expecting a progress heartbeat at least every few seconds. For the first minute, heartbeats arrive steadily and the no-progress watchdog keeps resetting — the task is legitimately long but clearly alive, so it is not killed. Then the remote agent's process wedges and the heartbeats stop. Within the no-progress interval, the watchdog fires: even though a total-time timeout might not have expired, the absence of progress is the signal that the stream is dead. The caller cancels, discards the partial stream, and retries or falls back. This is the case a single total-duration timeout cannot handle — it would either have killed the healthy long task early or waited far too long on the wedged one — and it is why the architecture carries both kinds of deadline.
One more scenario ties the pieces together: a partial failure across a fan-out. The planner delegated to three sub-agents in parallel, sharing the remaining budget across all three. Two return promptly; the third stalls and its watchdog fires. Because the planner set per-branch deadlines from the shared budget, it does not wait out the full window on the stalled branch — it collects the two successful results, marks the third as timed-out (and cancels it), and decides with the information it has: proceed with a partial answer, retry just the failed branch within whatever budget remains, or fail fast if the missing branch was essential. The key is that the timeout on one branch neither blocks the others nor silently drops from view; it surfaces as an explicit per-branch outcome the planner reasons about, which is exactly the containment that a shared, propagated deadline plus per-call cancellation is designed to provide.