When AI agent traces become application data

When a coding agent assists developers, it traces the activity leading up to a patch. It records the files it edits, commands it executes, their outputs, and the resulting code changes. Developers review this activity before accepting the patch. Teammates can revisit the same run to understand why the code evolved. The engineering team aggregates execution data across runs, as the agent's behavior can be unpredictable and evolve over time.

This trace data becomes application data with telemetry characteristics. Not all agent traces are application data; diagnostic traces, meant for internal use and potentially discarded, remain telemetry. The distinction between the two occurs when the trace must be retrieved, displayed, or retained. A developer might need to see which files the agent inspected, or a reviewer might want to check which commands ran and if the tests passed.

This record enables users to verify the outcome and gauge their trust in it. In certain workflows, it can also serve as an audit record, affecting access and retention requirements. Even though the record originates from the same run, internal diagnostic fields do not automatically belong in the product view without explicit authorization.

The increasing complexity of agent runs, due to factors like multiple model calls, file reads, searches, command executions, retries, and branches, leads to a surge in data volume. For example, a single pull request can trigger numerous model calls and file operations, resulting in thousands of spans or events. These spans carry information such as model identifiers, token usage, and opt-in inputs and outputs.

As more tools, retry policies, and branches are added, the data volume grows, even if the number of completed tasks remains unchanged. This phenomenon of data expansion applies not only to coding agents but also to browser agents, which can generate hundreds of thousands of DOM diff events during a 30-minute session. Regardless of the application, the trace data serves two purposes: point retrieval for understanding a single run and cohort analysis for pattern identification by engineering teams.

Most records in an agent trace are written once and describe events that have already occurred. These records carry high-cardinality dimensions, such as model version, prompt template, tool name, session ID, user ID, and outcome, which become meaningful when analyzed in context. The data can be consumed in different ways, such as point lookup for developers or reviewers, cohort scans for evaluation pipelines, and time-window aggregation for platforms.

As the data scales, it may outgrow the primary database, requiring a decision on when to extract it from the primary database and store it elsewhere.