The Memory That Won't Compress
A few weeks ago one of my own agents flagged, with complete confidence, a database vulnerability we had already looked at and set aside.
It was a good flag. The CVE was real, the reasoning was sound, and if I had been a new hire reading it cold I would have nodded along. The trouble was that I was not a new hire. We had assessed that exact vulnerability weeks earlier, worked out it did not apply to the way we actually run MongoDB, and closed it. The agent - our security analyst - could see the dependency list exactly as it stands today. What it could not see was the verdict we had already reached, because that verdict lived nowhere it could read. It could see where everything was. It could not see where we had already decided not to go.
That gap is the subject of this piece, and I think it is the most under-discussed problem in the whole agent-memory conversation, because the conversation has just declared the problem solved.
🗂️ The month memory got "solved"
This month the vendor narrative reached its confident phase. mem0 published its State of AI Agent Memory 2026 and reported better than ninety percent accuracy retrieving stored facts in under seven thousand tokens a query. Microsoft Research put out Memora, a "harmonic memory representation" that is genuinely clever - it separates what is stored from how it is retrieved, and beats everything else on the long-context memory benchmarks while spending a fraction of the tokens. The systems differ in sophistication, but the shape of the claim is consistent: distil the experience into entries, index them well, and retrieve what is relevant when it is relevant again. Memory, in this telling, is a storage-and-retrieval problem, and storage-and-retrieval problems are the kind engineers know how to win.
I want to be fair to this, because it is genuinely good work and it solves a genuine problem. An agent that forgets your name between sessions, or re-reads the same file four times in one task, is worse than useless. The fact-storage layer matters. I run one myself.
But "we can store and retrieve the facts" is not the same claim as "we have solved memory," and the slippage between those two sentences is where the trouble lives.
The institutional memory that actually stops an agent repeating your worst mistake is not a fact. It is the felt history of a decision made, regretted, and reversed. And it resists embedding by construction.
🐤 What the senior engineer carries out of the door
Lalit Maganti wrote the best account of this I have read all year. He spent three months and around two hundred and fifty hours building a set of SQLite developer tools - a real project, shipped, not a weekend toy - using an AI coding agent as hard as he could push it. His write-up is honest in both directions, which is rare. But the line that stayed with me was about time.
"Something I kept coming back to," he wrote, "was how little AI understood about the passage of time. It sees a codebase in a certain state but doesn't feel time the way humans do. I can tell you what it feels like to use an API, how it evolved over months or years, why certain decisions were made and later reversed."
He draws the analogy that I think is exactly right: this is why losing a high-quality senior engineer hurts a team so much. They carry history and context that does not exist anywhere else. When they leave, you do not lose their notes. You lose the thing the notes were a poor summary of. The new person - or the new agent - walks the same path into the same wall, confidently, because from where they are standing the wall is invisible. The codebase shows them where everything is. It never shows them where the team has already fallen.
The standard answer to this is "write it down." Keep the design docs current, capture the decisions, feed them to the model. And you should, up to a point. But there is a reason we did not do this exhaustively before AI arrived, and the reason is not laziness. Capturing implicit design history is enormously expensive, and worse, you cannot verify that you captured the part that mattered. A regret does not compress into a sentence without losing the thing that made it a regret. "We tried X and it was slow" is not the lesson. The lesson is the three weeks, the specific way it broke under load on a Friday, the argument about whether to persevere, and the cost of having been wrong - and none of that survives the trip into a bullet point, let alone into a vector.
🧱 Some history is too dense to recompute
There is a flip side to this, and Steve Yegge named it well when he wrote about which software survives in a world where agents write most of it. His argument was about tools, not memory, but the same idea applies. Some systems, he said, are "crystallised cognition" - Git, Temporal, grep - insight so dense that it would be economically irrational for an agent to re-synthesise them from first principles. You do not rebuild Git on demand. You carry it.
Hard-won institutional history is crystallised cognition of exactly this kind, only it is yours and nobody has packaged it. The reason "we stopped doing that in 2021" is valuable is that it compresses a long, expensive episode into a single load-bearing instruction. It would be irrational to re-derive it by living through it again - which is precisely what an agent with no sense of time does, cheerfully, every time it proposes the thing you already buried.
So the felt history is in a genuine bind. It is too dense to recompute, and too compressed-by-loss to store. It has to be carried. And carrying, so far, is the one thing the memory frameworks have not worked out how to do, because carrying is not retrieval. It is judgement about what an episode meant.
🗜️ What surprised me building my own memory
I have spent the last several months running a memory store of my own - a database my agents and I both read and write, the substrate a small fleet of them coordinate through. I built it expecting the value to be in the facts. It was not.
The most valuable entries turned out to be the ones I deliberately refused to resolve. I call them counterpoints: places where two things I believe contradict each other, and instead of smoothing the contradiction into a tidy synthesis, I kept both, side by side, with the tension intact. The decision I made and still am not sure about. The principle that works except in the case where it does not. The approach I rejected for reasons that might not survive the next model release.
Every memory framework I have looked at treats a contradiction as a data-quality problem - something to deduplicate, reconcile, resolve. Mine treats it as the asset. Because the contradictions are the closest thing I have found to scar tissue. They are where the felt history lives: not "here is the fact," but "here is the thing we got wrong, and here is why we have not fully trusted the obvious answer since." A fact tells an agent what is true. A counterpoint tells it where to be careful. No store I know of ships the second thing, because the second thing is exactly what embedding throws away.
This is the same argument I made in The Sum of All Tokens, turned to face the other way. There I said software is the sum of your token spend plus your human insight, and that insight is the scarce half. Memory is where that scarce half is supposed to accumulate. If what accumulates is only the facts - the cheap, compressible, retrievable half - then you have built a system that remembers everything and has learned nothing. The expensive half, the part that compounds over years in the way I described in The Long Obedience, is the part that does not fit in the vector store.
🐑 The membership organisation that lost its why
At sheepCRM we work with membership organisations and charities, and this is not an abstraction for them - it is the daily texture of the job. When an organisation comes onto the platform, or when a long-serving membership secretary finally retires, what gets handed over is the state: the membership categories, the renewal rules, the committee structure, the fields on the record. What does not get handed over, because nothing ever asks for it, is the felt history. Why renewals fall on that particular date. The membership category that was tried one year and quietly dropped because it confused everyone. The fee exemption that exists because of one bruising AGM a decade ago that nobody wants to repeat.
The rules an organisation runs on are the compressed residue of decisions made, argued over, and sometimes reversed. The organisation keeps the rule. The reason walks out of the door with the person who remembered it. And so, a few years later, somebody competent and well-meaning proposes reinstating the category that was abandoned for good reason, because from where they are standing - looking at the current configuration - the reason is invisible. It is the senior-engineer problem again, this time in a village hall.
This is the part I think about when people talk about "capturing your business processes" in a system. Capturing the process captures the what: the workflow, the steps, the configuration. The thing that actually protects the organisation from relearning its own hard lessons is the why - and the why is made of exactly the material that does not compress: the decision that was reversed, the approach that was tried and regretted, the contradiction nobody fully resolved. A CRM, like a vector store, is very good at holding the state. The institutional memory that matters most is the layer underneath it, and capturing it well means capturing the reasons and the reversals, not only the rules they left behind.
🧭 Where this leaves us
I am not claiming the vendors are wrong about what they built. mem0 and Memora do the thing they say they do, and they do it well - the fact layer is worth having. Memora is the state of the art, and its own list of open problems is the tell: learning from its retrieval failures, deciding when not to commit a memory yet, sharing memory across a team without losing provenance. All real. All still about the machinery, not the meaning. I am claiming they are wrong about what they have finished. "Memory is solved" is a sentence about storage. The problem that actually matters - stopping a confident agent from re-walking a path your team already abandoned for good reasons - is not a storage problem. It is a problem of carrying meaning across time, and meaning is the thing that does not compress.
The honest position, the one I am still working out in practice, is that this might not be fully solvable, and that the partial solution is not a better embedding. It is preserving the contradictions on purpose, paying the cost of keeping the felt history as a first-class object rather than letting the system tidy it away. That is expensive and unglamorous and it is the opposite of what "superhuman memory" is being sold to mean.
A map shows you where you are. It does not show you where you have already fallen. The thing the senior engineer carries out of the door, the thing the agent flagged straight back into my lap, is the second map - and so far, you cannot embed it.
You can store a fact. You cannot embed a regret.
James Webster is the founder of sheepCRM and director of Croftsware. This piece is a companion to The Sum of All Tokens and The Long Obedience.