How do I trace what a chain of AI agents did?
Updated · DBShifts
Short answer
Give every chain of calls one ID and carry it on every hop, together with who started the chain and which agents have handled it since. Record each hop — caller, target, outcome, timing, what was masked or refused — against that ID. W3C trace context lets the same ID appear in the tracing tools you already use.
Key facts
- One user request can fan out into many agent-to-agent and agent-to-tool calls.
- A chain ID carried on every hop is what links those calls into one trace.
- The original requester has to travel with the chain, or downstream agents cannot apply that person's permissions.
- W3C trace context (the traceparent header) lets a chain ID join traces in OpenTelemetry-compatible tools.
- Trace records should describe what happened, not store the messages themselves.
In the glossary:Chain token
Why agent traces are different
In a service mesh every call is code you wrote. In an agent chain each hop is a model deciding what to do next, so the shape of the trace is not known in advance: it can branch, revisit an agent or loop. The trace has to explain decisions — refused, masked, held for approval, stopped — not just latency.
What to record on each hop
The chain ID, the caller and target, the person the chain acts for, the outcome, the time taken, which data classes were masked or blocked, whether the injection shield acted, and if the chain was stopped, the reason. That is enough to answer who asked for what and where it went, without keeping any customer data in the log.
Making the chain trustworthy
If agents pass the chain along themselves, one can drop or rewrite it. A signed chain token, issued by the broker and verified at each hop, makes the requester and the path tamper-evident.
Checklist
- 1
One chain ID created at the first hop and carried on every call
- 2
The original requester carried and verifiable at every hop
- 3
Per-hop outcome, timing, masking and refusal reason
- 4
A traceparent header so existing tracing joins up
- 5
No message content in trace storage
- 6
A way to stop a chain from its trace
Common mistakes
Logging each agent separately
Ten agents with ten logs and no shared ID cannot answer which request caused which call.
Logging prompts and responses in full
It copies customer data into a second system that was never meant to hold it. Record the outcome and the data classes, not the text.
How DBShifts does it
- DBShifts Agent Mesh gives every chain a signed ES256 token carrying who started it and every agent since; each next hop receives it in the X-Mesh-Token header.
- The chain ID is passed downstream as a W3C trace ID in traceparent, so the chain shows up in your own tracing.
- Owners see each chain as a tree of hops with masked, shield and approval marks and the reason it stopped; the audit rows hold no message content.
Questions people also ask
Can I see agent chains in OpenTelemetry?
Yes for correlation: the mesh sends a traceparent header built from the chain ID, so services that use OpenTelemetry attach their spans to the same trace.
How long does a chain stay valid?
In DBShifts each chain token is valid for 30 minutes and a chain's total lifetime is limited separately — 60 minutes by default.
Related questions
Give AI agents data access you can defend
Scoped tokens, PII masked on the server, every request audited. Free to start.
Start free28 answers in this series. See all or browse the AI agent glossary.