Key facts.
- Agent traces carry full context per step, so naive full-fidelity capture on every run scales overhead with both step count and context length. source
- tau-bench shows failure is unpredictable run to run, so you cannot decide in advance which specific run to trace by guessing it will succeed. source
- Anthropic reported multi-agent runs using roughly 15x the tokens of chat, a reminder that overhead compounds fast once agents fan out (reported). source
- OpenTelemetry sampling is a first-class concept, so tiered capture is a configuration, not a custom build. source
What overhead does tracing actually add?
Three kinds. Compute, because serializing and shipping large trace records costs cycles. Latency, if the trace write sits on the critical path of the response. And storage, the data bill that grows faster than traffic. None of these is a reason to stop tracing. They are reasons to be deliberate about which runs get the full treatment and to keep the trace write off the hot path so it never delays a user.
The decision rule that works is consequence-based. If a run can move money, change state, or has already errored, trace it fully, because that is the run an incident review or an auditor will demand. If a run is a routine read-only success, a sampled trace plus aggregate metrics is enough to detect drift. You are not trading away safety. You are spending fidelity where it buys you something.
How do you keep the trace off the critical path?
Emit trace events asynchronously, so the agent responds and the trace is written in parallel rather than before the response returns. Buffer and batch the writes. And tier the sampling at the edge, so low-value runs are thinned before they ever hit storage. Done this way, the user never waits on your observability, and the bill reflects value rather than raw volume. The overhead becomes a rounding error on the runs that do not matter and full coverage on the runs that do.
| Run type | Fidelity | On critical path? |
|---|---|---|
| State-changing / financial / errored | Full | No (async write) |
| Routine successful | Sampled | No |
| High-volume read-only | Metrics + thin sample | No |
The Pattern Intelligence Layer makes the fidelity decision a property of the pattern, not a per-team guess made under cost pressure. Which runs are fully traced, which are sampled, and how the write stays off the hot path are enforced the same way on every run, so you keep both speed and the visibility you need. Reliability at the pattern level means you never have to choose between a fast agent and a debuggable one.
Frequently asked questions
Can a stronger model let us trace less and still debug?
Tracing less blinds the runs you needed; a frontier model won't say which fails, as tau-bench shows agents inconsistent across repeats. (arXiv:2406.12045)
Does tracing always add latency?
Only if the write is on the critical path. Emit asynchronously and batch, and the user never waits on it.
Can we just trace 10% of everything?
Uniform sampling drops consequential runs. Tier by consequence: full on state-changing and errored runs, sampled on routine ones.
Is light tracing on routine runs safe?
Yes, because their value is statistical. A representative sample plus aggregate metrics catches drift without full-fidelity cost.