A steady stream of agent memory tools has appeared over the last few months. Different authors, different languages, no shared vocabulary, and a strikingly consistent shape: capture what happened in a session, embed it, store it, retrieve it later by similarity.
They are all solving a real problem. Agents forget between sessions, and rebuilding context by hand is the most tedious part of running one. But almost all of them are built on an assumption I think is wrong, and the assumption is doing damage that will not be visible for another six months.
The assumption is that memory is a storage problem.
Storage is the wrong shape
When you model memory as storage, certain decisions follow automatically. You design a schema for what a memory is. You worry about deduplication, because storing the same fact twice is waste. You build update paths, because facts change and stale records are dangerous. You end up with migrations, because your idea of what a memory should contain will change.
Every one of those is the correct instinct for a database and the wrong instinct here.
The tell is what happens when you improve your retrieval. Say you decide summaries should be shorter, or that you want to extract decisions separately from observations, or that your embedding model has been replaced by a better one. In a storage model, that is a migration. You have to transform records you already wrote into a new shape, and you cannot, because the original material was discarded at write time. You kept the summary and threw away the session.
So you either live with the old shape forever or you start over and lose your history. I have watched myself do both.
You already have the log
The harness is already writing an append-only, ordered, immutable record of everything that happened: the session transcript. Every prompt, every tool call, every result, in sequence, never edited after the fact.
That is an event store. Not something like one. That is the actual thing, with the actual properties: append-only, ordered, immutable, complete.
Nobody built it deliberately as one. It exists because logging sessions was obviously useful and nobody thought hard about what they had. But once you notice it, the architecture reorganizes itself, because event sourcing is a mature pattern with about twenty years of accumulated discipline attached, and all of that discipline transfers.
In an event-sourced system, the log is the truth. Everything else is a projection: a read model built from the log, optimized for one query pattern, and considered disposable. You do not migrate a projection. You delete it and rebuild it from the log.
Which means your memory tool is not a database. It is a projection. And the correct response to "I want shorter summaries now" is not a migration. It is: delete the summaries, rebuild them from the transcripts, go get coffee.
What changes when you accept this
Projections are disposable, so build them cheaply. If rebuilding is easy, you stop treating your memory schema as a decision you have to get right. Try an extraction strategy. If it is bad, throw it away. This is the freedom that makes iteration possible, and the storage model denies it to you.
Multiple projections, not one. Once projections are cheap, there is no reason to have a single memory store trying to serve every query. Build one for architectural decisions, one for failure modes, one for the shape of the codebase. Each answers one question well. They can disagree and it does not matter, because none of them is the truth.
Retention policy moves to the log. The interesting question stops being what to remember and becomes how long to keep raw transcripts. That is a much easier question, with a much clearer cost basis, and it is answered in gigabytes rather than in philosophy.
The vendor's transcript retention becomes an architectural concern. This is the part that worries me most. If the log is the truth and the log lives in a vendor's system under a retention policy you do not control and did not read, then your source of truth is on loan. I now archive transcripts to storage I own on the day they are produced. It is not a lot of data and the alternative is discovering the policy the day you need something from March.
What this predicts
If the projection framing is right, the current memory tool cohort mostly consolidates rather than matures. Tools that own the storage layer and treat extraction as their product are in a weak position, because extraction is the disposable half. The durable position is at the log: capture, retention, and a clean interface to build projections against.
I would expect the harness vendors to absorb this, since they already hold the log, and the standalone tools to end up as projection recipes rather than as products. I could be wrong about the timing. I am fairly confident about the direction.
Where this argument is weak
Rebuild cost is not free, and I have been glib about it. Reprocessing a year of transcripts through a model to regenerate summaries costs real money, and it scales with history in a way that a migration does not. There is a size past which "just rebuild it" stops being a shrug. I have not hit it. Somebody will, and the answer will probably be incremental rebuilds with checkpointing, which is a well-understood pattern that will nonetheless surprise people who thought they had escaped migrations.
Second, transcripts are a lossy record of a session in one specific way: they capture what the agent did, not what you were thinking when you redirected it. The most valuable memory in my own work is often why I stopped an agent, and that intent is nowhere in the log. Event sourcing does not fix a missing event. If the important thing was never emitted, no projection will recover it, and I do not have a good answer beyond writing the reason down at the time, which I mostly fail to do.
Third, a reasonable person could say this is a distinction without a difference, since you can rebuild a database from source material too if you kept it. True. The difference is what the framing makes you do by default. A storage framing makes you discard the source and defend the record. An event-sourcing framing makes you defend the source and discard the record. Same components, opposite instincts under pressure.
What this changes in my factory
Transcripts are archived to my own storage on the day they are written, before anything else touches them. This is the only step I would call non-negotiable.
Every memory artifact I generate is treated as regenerable, and I test that claim by actually deleting and rebuilding one on a schedule. A projection you have never rebuilt is a projection you cannot rebuild, and you find out at the worst moment.
I keep several small extractions rather than one general memory store. When one is not earning its retrieval cost, I delete it without ceremony, because deleting it costs nothing.
I stopped writing migrations for memory data. If I catch myself designing one, it means I have started treating a projection as a source of truth, and the fix is upstream.
What to ask of a memory tool
- If I change my mind about the extraction format, does this tool make me migrate or rebuild?
- Does it keep the raw material, or only its interpretation of the material?
- Where does the underlying transcript live, who controls its retention, and have I read that policy?
- Can I run two different extractions over the same history at once, or does it assume one canonical memory?
- If I deleted everything this tool has stored, could I reconstruct it? How long would that take, and what would it cost?
- What did I know during that session that never made it into the log at all?
Agent memory is not hard because storage is hard. It is hard because the field is building read models and defending them as though they were the source of truth, while the actual source of truth sits in a log nobody claimed, on a retention policy nobody read.