Memorizing Session Transcripts Isn't Useful

theahura, writing at 12gramsofcarbon on 2 July 2026, reports a negative result from his own company: across many months of testing with and without the feature, agents that could search their previous session transcripts performed no better on software engineering tasks than agents that could not, provided the agents had other forms of context available. If anything the search access made the models slightly worse. He is not a disinterested party — his company built a product on the premise that session transcripts were "the new oil," more valuable than the code itself, and this post is him retracting that.

The architecture he is arguing against is the common one. Store every transcript across an organization in a database, put vector search or Elasticsearch or SQL in front of it (ambitious teams do all three, sometimes with a graph), and expose it to the agent through MCP or a CLI wrapped in a skill. Claude Code's own session memory is in this family.

Why the value isn't there

The explanation turns on where the useful information already went. His team writes almost no code by hand, so they invest in commit messages, PR descriptions, and documentation, and every change ships with that metadata committed alongside it. Agents are instructed to read the docs and the previous PRs before working on a piece of code. The agent, in other words, has already distilled the durable part of each transcript and written it where it will be found.

What is left in the raw transcript is the residue: the things the agent decided not to write down. Searching it means spending tokens re-reading what the agent already knows, while picking up abandoned approaches, dead ends, and scratch-pad reasoning that were correctly discarded the first time. Occasionally there is a real nugget. Most of the time it is a pseudo-nonsensical scratch pad charged at full token price.

Intent drift

The second argument is structural and harder to design around. Agents are terrible at removing context, which he calls the critical capability for long-term memory. He has never once seen it happen across literal thousands of sessions.

He argues this is not a prompt-engineering problem. Agents have no state, so everything in the input context window has to be treated as ground truth, and every token in it reads as an expression of intent — including code or memory produced by a random decision in some earlier session that no human ever reviewed. He calls the compounding version intent drift: the more the agent autonomously builds up its own memory base, the more of its context is unreviewed machine output that the next agent will treat as deliberate.

The supporting observation is sharp. No coding benchmark he knows of assumes the input data is corrupt, and models are actively penalized for assuming their input is wrong. There is also an alignment tension underneath, with no clean way to separate "don't delete the codebase" from "do delete some of your input context."

What he still does

The conclusion is not that agents can't accumulate context over time — it is that they can't do it unsupervised. His team runs internal bots that review the week's PRs, Slack, and Drive, then propose changes to the team's skill files and tag humans in Slack. Every proposal is default-rejected. Accepting one means reading the diff and confirming it matches intent. They accept fewer than 20%, which means 80% of those changes would have made the system worse if they had been applied automatically. At a few-hundred-person org saving updates continuously, that ratio is the whole argument.

Transcripts may still be worth keeping for team observability. They just won't make the agents better.

Where this cuts against the vault

This page disagrees with a good part of the memory cluster here, and it is worth naming rather than smoothing over.

The vault carries several agent-memory products built on exactly the pipeline he says doesn't pay: agentmemory, hippo-memory, mempalace (which keeps conversations verbatim in a vector store), stash, and ctx. engrim stores curated typed records rather than transcripts, which is the distill-at-write side of this argument, but lets agents write those records with no review step. agent-memory-components describes the extractor/store/retriever pipeline as a design space with real tradeoffs at each layer; theahura's claim is that for coding agents with good artifact hygiene, the whole pipeline nets to zero or negative regardless of how you resolve those tradeoffs. Neither position has enough public measurement behind it to settle the question, and measuring-ai-coding-productivity is the reason to be suspicious of both — his result is one team's internal A/B over one workload, reported without numbers.

Two existing pages agree with him more than they conflict. agent-memory-decay exists precisely because unpruned memory accumulates into noise, which is the mechanical answer to "agents never remove context" — decay does the removal the model won't. And agent-memory-anatomy's complaint, that these systems ship autobiographical semantic memory while claiming more, is the same observation about the same object from a different angle.

The pattern he endorses is the one this vault runs on. Distill the durable claims into a legible, greppable artifact at write time, keep it where the reader will look, and put a human on the accept path — that is llm-wiki-as-agent-memory and human-in-the-loop, not transcript search. The related workflow argument, that reading the diff is where the understanding comes from, is short-leash-ai-method. a-voice-from-nowhere supplies the reason someone would want the transcripts in the first place — the prompt is the artefact carrying the path — and this negative result is the answer: by the time you go looking, the durable part has already been distilled into commits and docs. For the opposite bet on the raw record, see log-is-the-agent: it also keeps everything, but as a causal event log built for replay and lineage rather than as text to be searched.