Key facts.
- Agent traces are heavy by construction: each step records prompts, tool inputs and outputs, and intermediate reasoning, so one multi-step run can produce orders of magnitude more data than a single API log line.source
- Anthropic reported its multi-agent research system used roughly 15x the tokens of single-agent chat, a useful proxy for how fast per-run data volume grows once agents fan out (reported).source
- Agent context cost grows approximately quadratically in the number of steps, because each step re-sends the accumulated context, so trace and inference cost both scale with depth, not just request count (blog.exe.dev, reported).source
- A 2025 enterprise survey found teams plan to invest more in observability than almost anything else, which means the data volume problem is about to get bigger, not smaller.source
- Each step carries full prompt and reasoning, so trace volume grows quadratically (blog.exe.dev); the data platform, not the model, is the bill an upgrade won't move. (source)
Why does trace data grow faster than request volume?
A traditional service logs a request and a response. An agent logs a chain. Every reasoning step, every tool call, and every tool result is a record, and the records are large because they carry full context, not a status code. Long-context tasks make each record bigger. Multi-agent setups multiply the number of records, because every inter-agent message is its own event. So a 2x rise in user traffic can mean a 10x or 20x rise in trace volume, and the data platform scales on the second number, not the first.
The wrong response is to capture less and hope. That trades a known cost for an unknown one, because the run you stopped tracing is the run that fails. The right response is to decide, up front, which traces are worth keeping in full, which can be sampled, and how long each tier lives.
What does value-based retention look like?
Three tiers cover most needs. Keep full-fidelity traces for runs that touch money, change state, or hit an error, because those are the ones a regulator, an auditor, or an incident review will ask for. Sample the routine successful runs, because their value is statistical, not forensic, so a representative slice is enough to spot drift. And set retention by obligation: keep the high-stakes traces as long as your compliance window requires, and expire the rest fast. The result is a bill driven by value, not by raw volume.
| Trace class | Capture | Retention |
|---|---|---|
| State-changing / financial / errored | Full fidelity | Long, to compliance window |
| Routine successful run | Sampled | Short |
| High-volume read-only | Aggregate metrics + thin sample | Shortest |
The Pattern Intelligence Layer treats retention as part of the pattern, not a switch someone flips during a cost review. Which traces are kept in full, which are sampled, and how long each lives are properties enforced on every run, so the observability you need for debugging and audit stays affordable as volume grows. Reliability at the pattern level includes the reliability of being able to pay for your own visibility.
Frequently asked questions
Should we just sample everything uniformly to cut cost?
No. Uniform sampling drops the exact runs you need for incidents and audits. Sample the routine, keep the consequential in full.
Why not capture less detail per step?
Detail is what makes a trace debuggable. Cut fidelity on low-value runs, not on the runs that touch money or fail.
How do we know which traces are high value before the run?
Tier by the tools the run can call: anything that changes state or moves money is high value by default.