Agentic AI
Why AI Agent Traces Need Application Data Storage, Not Just Telemetry
As AI agents leave behind durable execution records that users and teams both need to inspect and analyze, treating their traces as mere diagnostic telemetry becomes architecturally insufficient.
The New Stack
When a coding agent fixes a test failure, it leaves behind a record of every file it touched, command it ran, validation it checked, and change it made. That record becomes important data that developers and teams rely on—not just for reviewing a single fix, but for comparing thousands of runs to spot regressions and measure improvement. At that point, the trace stops being telemetry and becomes part of your product itself.
The boundary between telemetry and product data#
Not all traces are created equal. A diagnostic trace used internally for debugging—one that can be sampled, expired, or thrown away—remains telemetry. But the moment a user needs to see which files an agent read, what commands it executed, or whether tests passed, that trace has crossed into product territory.
This shift doesn't require exposing raw model reasoning. Instead, the product can show a projection of observable execution: the model invocations, tool calls, file reads, command results, errors, timing, and state transitions. That's enough for users to verify results and decide whether to trust them. It also becomes an audit trail in many workflows, which means it carries new requirements for retention and access control.
The critical insight: internal diagnostic fields don't automatically belong in the user-facing product view just because they came from the same trace. Once the execution record becomes application state, it must follow your application's authorization model. Code, prompts, documents, tool arguments, and output may contain sensitive data, so the same access boundaries that protect your primary database must protect this data too.
Why agent runs generate data at scale#
A single development task can explode into many traces. One request to fix a failing test might trigger multiple model calls, file reads, searches, command executions, test retries, and branching decisions before the agent proposes a patch. Each step produces its own span or event.
The fan-out effect scales with what you build. Add a new tool, introduce retry logic, or branch on conditions—and the data volume grows even though the number of completed tasks stays flat. The emerging OpenTelemetry GenAI semantic conventions (still in development) define span types for model inference, tool execution, and retrieval, each capturing different metadata depending on content policies.
Browser-based agents show the same pattern. Laminar reported more than 500,000 browser events per day, with single agent sessions running 30+ minutes and generating hundreds of thousands of DOM diff events—all needed to reconstruct a video-like replay of the agent's actions.

