Your Agent Sessions Are an Invaluable Dataset. Here's What We Learned From Ours.

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.

Some 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.

For 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.

Here's what we learned.

Organizing our analysis

We began by organizing our analysis into three questions:

• Intention. Why did we reach for traces? What need sent us there?
• Task. What work does the agent and its tools have to perform to satisfy that intention?
• Cost. How much retrieval, context, time, and money does that work take with the current toolchain?

Why we use our traces

Our queries broadly fell into three groups.

Remember and continue

Typical prompts:

What did I leave unfinished three days ago?

Write a handoff so another agent can continue these two PRs.

Why did we pick this retry limit?

What did the backend team ship this week?

We wanted to pick up a piece of work with the context and decisions needed to keep moving.

1. Recover forgotten work. The user remembers a person, a rough date, a branch, but not where the session happened.
2. Recover interrupted work. Finding a session is step one. The next part is surfacing what was tried, what worked, and what the next safe action is.
3. Catch up on someone else's work. An asynchronous account of a teammate's progress and decisions. We found this usually occurred before reviewing a teammate's branch or PR.
4. Recover missing rationale. The code shows the output, but the conversation that produced it explains why, and which alternatives were rejected.
5. Transfer context. Get another person or agent to the same working state.

Figure out what happened

Typical prompts:

Has anyone hit this error before?

Which of these "in progress" tasks are already merged, and which are truly open?

We wanted to use the record of work as evidence.

1. Find a precedent for a current problem. Prior incidents surface known edge cases, earlier diagnoses, failed approaches.
2. Establish evidence. The user wants a claim verified against primary sources, with traces triangulated against code, git history, logs, and telemetry.
3. Reconcile history with current reality. Trace status and conversation endings go stale. The answer has to compare them with branches, CI, and deployments.
4. Restore exact artifacts and working state. Get back to a specific thing that was lost. A config file, script, command, set of .env variables.

Learn and improve

Typical prompts:

Turn our past incident investigations into a reusable skill.

What are our most-used skills this month?

When do I reject the agent's output, and what's the pattern?

We wanted to turn past work into better skills, habits, and plans.

1. Codify reusable knowledge and skills. Separate stable patterns from one-off instructions and distill them.
2. Learn and improve human-agent working methods. Leverage trace history to expose the correction, pivots, and habits that are hidden in the final artifacts.
3. Measure adoption, efficiency, and resource use.
4. Retrospect on collective work and plan improvement. Longitudinal lessons, recurring friction, and informed next steps.

What the agent does next

With 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.

One 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.

Here's what Recover forgotten work looks like as an actual tool sequence through the Traces MCP:

Recover interrupted work starts the same way but ends in reconstruction instead of a single read:

How much it costs

We 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.

What 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.

Finding 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.

Reading 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.

Without 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.

Some real examples

A few sessions from our own history to close this out.

Recovering 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.

A missing SQL file was reconstructed the same way, from the trace events that originally wrote it plus the current schema.

Diagnosing 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.

Extracting 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.

Learning 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.

All of these use cases were sitting in history we already had, waiting to be leveraged.

More than memory

Two 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.

Without 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.

Without 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.

Our 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.

Your 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.