{"slug": "what-we-learned-from-our-traces", "title": "What we learned from our traces", "summary": "Traces analyzed its own stored coding-agent sessions and found that roughly 30% of questions were answered from the `traces_search` result list alone, without opening a single session, while about one in ten questions proved expensive because the agent had to open many sessions. The company said every trace-tool call fell into one of six task categories, with one intention typically chaining two to four tasks, and that chain length rather than the motive mostly drives cost. Traces argued that without a product storing agent sessions and making them cheap to find and read, leveraging that history is prohibitively expensive.", "body_md": "Most teams running coding agents are losing the record of that work. Every session is a log of what was tried, what broke, what was decided and why, and that context disappears the moment the terminal closes.\n\nSome teams have noticed and started saving those sessions. That's better, but a folder of transcripts is where most of them stop. The history is *stored*, but it isn't *used*.\n\nFor the team at Traces, every session we run is stored, and we search and lean on that history every day. This context is one of the most valuable datasets we have, and we took the time to analyze it.\n\nHere's what we learned.\n\nWe began by organizing our analysis into three questions:\n\nOur queries broadly fell into three groups.\n\nTypical prompts:\n\nWhat did I leave unfinished three days ago?\n\nWrite a handoff so another agent can continue these two PRs.\n\nWhy did we pick this retry limit?\n\nWhat did the backend team ship this week?\n\nWe wanted to pick up a piece of work with the context and decisions needed to keep moving.\n\nTypical prompts:\n\nHas anyone hit this error before?\n\nWhich of these \"in progress\" tasks are already merged, and which are truly open?\n\nWe wanted to use the record of work as evidence.\n\nTypical prompts:\n\nTurn our past incident investigations into a reusable skill.\n\nWhat are our most-used skills this month?\n\nWhen do I reject the agent's output, and what's the pattern?\n\nWe wanted to turn past work into better skills, habits, and plans.\n\nWith a clear understanding of why we're searching our traces, we then explored how our agent was going about addressing our requests. Across the sessions we studied, every trace-tool call fell into one of six task categories.\n\nOne intention usually chains two to four of these tasks, and the same task (discovery, almost always) shows up under most intentions. The length of the chain, not the motive, is what mostly drives cost.\n\nHere's what Recover forgotten work looks like as an actual tool sequence through the Traces MCP:\n\nRecover interrupted work starts the same way but ends in reconstruction instead of a single read:\n\nWe counted how many trace-tool calls the agent made and how many tokens those calls returned. Half of the questions are cheap, most of the rest are moderate, and about one in ten is expensive.\n\nWhat separates the tiers isn't how hard the question sounds. It's how many sessions the agent has to open to answer it. Traces helps us manage these costs in two key ways.\n\nFinding a session is one call. `traces_search` returns the title, summary, author, and date of every matching session in one shot. Nearly 30% of the questions in our sample were answered from that list alone, without opening a single session.\n\nReading a session is a window, not a whole file. A raw session is mostly tool results: file dumps, command results, diffs. `traces_read` skips the tool output and returns a bounded slice.\n\nWithout Traces, checking a session means opening a raw file. An agent can grep it or read the last few hundred lines, but it can't know which slice matters until it has looked, and nothing tells it which sessions to open in the first place. So in practice it reads whole files, and the sessions worth reading are often the long ones. Without a product that stores agent sessions and makes them cheap to find and read, leveraging that data is prohibitively expensive.\n\nA few sessions from our own history to close this out.\n\nRecovering lost working state. After a chunk of a home directory was deleted, shell configuration and dotfiles were rebuilt from commands preserved in earlier sessions. The agent's history *was* the backup.\n\nA missing SQL file was reconstructed the same way, from the trace events that originally wrote it plus the current schema.\n\nDiagnosing production from traces. When a wave of fake users showed up, our agent searched session history for API calls, environment variables, and request sequences to find the strongest lead and separate local test runs from real production traffic.\n\nExtracting skills. Production investigations became a production investigation skill. A pile of TUI prompts became design and diagnostic guidance. Given-When-Then sessions became an acceptance skill.\n\nLearning from a teammate's prompting. The agent studies one engineer's real prompts and corrections to explain their quality bar, how they control scope, the hidden failure modes they check for, and how they manage long context windows.\n\nAll of these use cases were sitting in history we already had, waiting to be leveraged.\n\nTwo things have to be true for any of this to happen. Agent sessions have to be stored, and, once stored, they have to be cheap to find and cheap to read. Most teams are missing the first. Many of the teams that have solved storage are missing the second.\n\nWithout the first, the record is simply gone. The reasoning behind a design decision, the command that fixed the outage, the three approaches that failed before the one that shipped. None of that context exists anywhere except a terminal that's already closed.\n\nWithout the second, the record exists but it's unusable. A folder of transcripts is a stack of very large files with no way in. No one reads them, and no agent can afford to. The answers are all in there. They're just too expensive to reach.\n\nOur queryable agent history has turned our session context into incident response, recoverable working state, reusable operating knowledge, and a way for us to learn how work actually happened.\n\nYour agents are generating the same dataset right now. Don't let it close with the terminal: store every session, and then make that context actionable and compounding.", "url": "https://wpnews.pro/news/what-we-learned-from-our-traces", "canonical_source": "https://traces.com/blog/agent-sessions-are-a-dataset", "published_at": "2026-09-16 22:11:33+00:00", "updated_at": "2026-09-16 22:24:48.691681+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-products"], "entities": ["Traces", "Traces MCP", "traces_search", "traces_read"], "alternates": {"html": "https://wpnews.pro/news/what-we-learned-from-our-traces", "markdown": "https://wpnews.pro/news/what-we-learned-from-our-traces.md", "text": "https://wpnews.pro/news/what-we-learned-from-our-traces.txt", "jsonld": "https://wpnews.pro/news/what-we-learned-from-our-traces.jsonld"}}