Agent traces became product data, and the write pattern now picks your storage

Two readers want opposite things from the same rows. A reviewer opens one run and needs the whole object: which files were inspected, which commands ran, what came back, in order ^[5][14]. The team shipping the agent wants thousands of those runs collapsed into whether a model or prompt change raised test success or just added tool calls and cost ^[16]. One is a point read of a wide, deep record; the other is a scan across a thin slice of a very large number of them. Engines that serve both well are not common, and the split is harder here than usual, because the aggregate people actually want includes content fields that exist only when content capture is turned on ^[11].

The write side has a shape too. Flatten the daily browser-event total Laminar reported in its case study and it lands near six events a second ^[12][1]. That figure is useless for sizing anything, because the same case study describes single sessions running past half an hour and producing hundreds of thousands of DOM diff events by themselves ^[12]. Two hundred thousand in that window is roughly 110 writes a second from one user ^[2], about nineteen times the flat daily rate ^[3]. Put two of those sessions side by side and the average stops describing the system. Bursty, fan-out driven ingest, landing somewhere that has to behave like product state.

What makes this a storage question rather than a vendor question is which cost levers survive the transition. Telemetry is affordable because you can sample it, let it expire, or throw it away ^[2]. Once a teammate can reopen a run later to see why the code changed, all three are unavailable for whatever subset the product renders ^[14][3]. That subset also inherits the application's authorization model, because prompts, retrieved documents, tool arguments and command output can carry tenant or user data ^[7], and where the record doubles as an audit trail, retention stops being an engineering preference ^[6].

The budgeting failure is the part worth planning against. Pull request counts and issue counts move with units of work at the workflow boundary ^[8]. Span counts move with what the agent did inside a unit of work ^[9], so a retry policy shipped on a Tuesday can lift stored volume with no additional completed tasks behind it ^[10]. The denominator a team forecasts that line against is not the denominator it invoices on.

The GenAI semantic conventions are still in development ^[11], which means the retained subset is not something the ecosystem hands you finished. It is a field-by-field decision about which spans are diagnostic and which are the user's record ^[4], written by someone on the team and then owned by them.