I think we are still talking about AI memory in the wrong way. Most implementations are variations of the same pattern: store previous information, retrieve it later, inject it into the prompt, and call the result memory. That is useful, but architecturally it is not very different from leaving Post-it notes around your apartment and deciding the apartment now remembers things. The more I work with AI systems, the more I think memory should not belong to the model at all. It should belong to the system around the model.
The model should be able to disappear tomorrow while the history survives. Claude should be able to write something today, GPT should be able to read it tomorrow, a local model should be able to challenge it next week, and whatever model we use six months from now should still be able to understand why a stupid-looking workaround exists. That is the experiment I have been building: not “long-term memory” as another assistant feature, but a shared external memory layer for AI agents. The more I work on it, the more I suspect that the interesting problem is not memory itself. It is the economics of forgetting.
Models know a lot. They know absolutely nothing about Tuesday.
A modern model knows more programming languages than I ever will. It knows distributed systems, databases, React, Python, Rust, Kubernetes, obscure RFCs, and probably fifteen different ways to explain why my architecture is unnecessarily complicated. What it does not know is what happened in my project last Tuesday. It does not know that we already tried the obvious solution and it failed, that an ugly interface exists because three repositories still depend on it, or that a seemingly arbitrary convention is the result of a two-hour discussion nobody wants to repeat.
That distinction matters because this information cannot reasonably live in model weights. It is not general knowledge. It is history, or more precisely, state generated by work. This is also where I think the difference between RAG and memory becomes clearer. RAG usually retrieves information that already exists somewhere: documentation, code, tickets, policies, articles, database records. Memory should preserve information created by the process itself: why we chose A instead of B, why C failed, why we tolerate D, what changed after E, which assumption was temporary, and what the team learned after getting something wrong.
Those things are not always documents. In many cases they are exactly the information that should have become documentation but never did. A fresh AI session therefore pays for that missing history by rediscovering it from scratch. That is the part I want to attack.
So I moved memory outside the agent
The prototype is intentionally boring, and I mean that as a compliment. There is a small HTTP memory hub shared by a team. Memories are plain Markdown files with structured metadata, split between general knowledge and project-specific knowledge. Every AI session gets access through its own MCP server and a very small tool surface: list what exists, pull what is relevant, and push something new.
The important part is not the MCP plumbing. It is the boundary. The model is not the memory store, the client is not the memory store, and the MCP server is not the memory store. Memory exists independently of all of them. When a session starts, it receives a small index so it knows what memories are available, but the full content enters context only when the agent deliberately asks for it.
That distinction matters because a bad memory architecture can easily become a very expensive way of shouting your entire company history into every prompt. That is not memory. That is context pollution with good branding. I want the agent to know that the past exists without forcing the entire past into every interaction. It might see that there is a memory about a failed migration, a client-specific constraint, or the reason an API looks strange, and then decide whether any of those facts matter for the task in front of it.
This creates what I think of as a retrieval economy for memory. The index is cheap and the details cost context, but there is an ugly assumption hidden inside that sentence: the agent has to pull the right memory. Today the prototype mostly delegates that choice to the model using the descriptions in the index. That is not a solved retrieval system. It is a deliberately primitive baseline. A memory that exists but is never retrieved is functionally forgotten, while pulling irrelevant memories is just context pollution with extra steps. Retrieval precision and recall therefore have to become part of the evaluation, not something I quietly smuggle into the phrase “the agent decides.”
None of this makes external memory a new idea. MemGPT already framed long-running agents around hierarchical memory and virtual context management, Letta has pushed that line into a stateful-agent platform, and the official MCP examples include a persistent knowledge-graph memory server. The interesting question for me is narrower: what changes when the memory is team-scoped rather than assistant-scoped, plain-text and portable across clients, and every memory carries an explicit trust state instead of being treated as automatically authoritative? I am not trying to invent memory. I am trying to find the organizational boundary where it becomes useful infrastructure rather than another assistant feature.
Memory without provenance is just a hallucination with a pension plan
Once agents can write persistent memory, another problem appears immediately: why should the next agent trust what the previous one wrote? Imagine an agent stores the sentence “Always use Redis for this component.” Was that an explicit team decision, something inferred from the current code, a temporary workaround, or a confidently wrong conclusion that happened to survive the session? Persistent memory without provenance is dangerous precisely because bad information does not disappear with the conversation. It gets to retire inside your infrastructure and mislead future agents indefinitely.
So in this system a memory is a report, not an instruction. An unreviewed memory effectively means, “Agent X said this was true at time Y.” It can be useful, but it is weak evidence and should be checked against code, plans, or the user before it drives a consequential decision. A reviewed memory carries stronger authority, and if an AI changes it the review state disappears unless a human reaffirms it. The model cannot silently rewrite approved history and keep the approval badge.
There is an obvious trap here: if every memory needs a human to approve it, I have simply rebuilt the documentation bottleneck one layer later. That would completely undermine the write-side economics I am arguing for. So review cannot be the write path. It has to be a promotion mechanism. Agents should be able to create low-trust memories cheaply; only the smaller subset that becomes stable project guidance should consume human review. Whether that trust ladder scales is still unproven, but at least the economics are coherent: humans curate authority rather than manually authoring the historical trace.
This sounds administrative until you think about what persistent AI memory means. Once information survives across sessions, trust has to survive with it. A useful memory needs authorship, age, context, a reason for existing, and some relationship to a source of truth. It also needs to remain challengeable. Otherwise we are not building organizational knowledge. We are building a database of confident sentences, and the internet has already demonstrated that this is not automatically the same thing.
The annoying thing about memory is that it gets old
Most AI memory demos look excellent because they last fifteen minutes. You store something, retrieve it, the model remembers, and everybody goes home happy. Leave the same system running for six months and the experiment becomes less photogenic. Projects change, APIs move, people reverse decisions, and a memory can remain perfectly retrievable while becoming completely false.
For that reason, the hub tracks age and flags old memories as stale. If a memory makes claims about code, the agent is explicitly reminded to verify those claims against the current implementation. I deliberately do not auto-delete old memories because age is not truth. A four-year-old architectural decision may still explain why half the system looks the way it does, while a memory created this morning may already be nonsense. Age should affect confidence, not existence.
This pushes the design away from the usual cache mentality. A cache asks whether a value can still be reused. Memory asks a harder question: how much should I believe this now? That distinction becomes important once the store contains months of decisions made by different agents under different assumptions.
The organizational value is obvious. The economics are not.
The attractive pitch is easy to see. Imagine joining a project and asking an AI agent, “Why does this system look like this?” Today it can inspect the repository and explain what exists. With memory, it could potentially explain why it exists: why a provider was rejected, why a migration failed, or why a “temporary” compatibility layer is now entering its third year of life.
The real architecture of a system is only partially visible in the code. The rest is distributed across Slack threads, meetings, abandoned branches, and one engineer saying, “Do not touch that. There was a reason.” Unfortunately, we have been selling the cure for this for twenty years. Wikis, Confluence, ADRs, internal portals. Each generation was definitely going to save us this time.
They all run into the same economic problem: the person writing the documentation pays the cost while somebody in the future receives the benefit. AI agents may change that because the agent is already present when the work happens. It saw the files, the failed approach, the correction, and the reason the decision changed, so producing a compact memory has almost zero marginal cost.
That is much more interesting than saying AI can read documentation. The possibility is that AI creates a historical trace as a by-product of doing the work instead of requiring humans to document everything afterwards. If that holds, agents change the write-side economics that killed many previous knowledge-management systems. But “if” is doing serious work in that sentence. I have not proved it.
What the prototype proves, and what it absolutely does not
The prototype works end to end. External text memory can live independently of the model. Different clients can use the same store. Memories can be selectively injected into fresh sessions. Writes can be structurally validated, provenance can be enforced by infrastructure, and stale information can be surfaced instead of silently trusted. That proves the substrate is viable.
It does not prove the substrate is useful. Those are very different claims, and AI engineering has suffered enough from building a demo on Tuesday and announcing a new form of intelligence on Wednesday. A working memory API proves that an agent can retrieve previous state. The claim that actually matters is whether the agent produces better work because that state exists.
Memory has costs. It consumes context, retrieval adds latency, weak memories can bias reasoning, and stale memories can push an agent toward obsolete assumptions. A perfectly functioning memory layer can therefore become an efficient system for importing yesterday's mistakes into today's session. The architecture only creates value if the exploration and correction it avoids are more expensive than the memory overhead it introduces.
This is where my own hypothesis changed. I initially thought the obvious win would be cheaper sessions. A memory-enabled coding agent should need fewer tokens because it would not have to rediscover the repository every time. Nice theory. Then I thought about it for more than five minutes, which unfortunately ruined it.
The real cost may be the exploration tax
A memory-enabled session may actually use more tokens. It receives an index, pulls memories, interprets provenance, verifies stale claims, and may still inspect the same source files afterwards. If I measure only API spend, I can easily imagine the result being neutral or even slightly worse. But API spend may be the wrong place to look for the economic benefit.
Every fresh coding agent enters a repository with a mild form of professional amnesia. It searches the code, reconstructs the architecture, discovers conventions, tries something, finds out why it does not work, and then another session arrives tomorrow and repeats a smaller version of the same archaeological expedition. The expensive part is not always the tokens consumed during that exploration. The expensive part is having a human explain the same thing again: we cannot change that response format, we already tried that migration, this service behaves differently because of a client constraint, yes I know this looks wrong, no please stop refactoring it.
At some point you realize that the organization is continuously paying to rediscover information it already paid to discover. That is the exploration tax. Memory does not need to eliminate it completely to be valuable. It only needs to reduce enough repeated investigation, wrong turns, and human correction to justify its own overhead.
That also changes what the experiment should measure. The comparison I care about now is the same repository, the same model, and matched tasks under two conditions: memory hub enabled and memory hub disabled. Then I want to measure token usage, yes, but also wall-clock time to an acceptable result, the number of human corrections required, the number of repeated wrong paths, and how often the agent violates known team decisions.
My current prediction is slightly inconvenient for my original argument. Token usage may be roughly neutral, or even a little worse, while human corrections and repeated architectural mistakes decrease. If that happens, the memory system is economically useful even if the API bill barely moves. An engineer-hour is still considerably more expensive than asking a model to read another thousand tokens.
The strongest pitch may therefore not be “AI sessions become cheaper.” It may be something much less futuristic and much more useful: AI sessions stop relitigating settled decisions.
The experiment I cannot speed up
There is one evaluation I cannot fake very convincingly: time. Right now the store is young and relatively clean. The interesting failure modes appear when contradictions accumulate, two agents describe the same event differently, the project evolves faster than the store, and one bad assumption survives long enough for five later memories to depend on it.
At that point the system stops being merely a retrieval layer and becomes a knowledge-maintenance problem. Provenance, staleness, consolidation, contradiction handling, and eventually forgetting all start to matter. Unfortunately there is no credible benchmark switch called --simulate-six-months-of-organizational-chaos. The system has to get old enough to become annoying before I can learn whether it survives real use.
Why plain text may be the most important boring decision
The part I still find most interesting is portability. These memories are plain text. They are not model-specific hidden states, not vectors that only make sense inside one embedding space, and not some proprietary “persistent cognitive representation.” Text is aggressively boring, which is exactly why I like it.
Claude can create a memory and GPT can read it. A local model can disagree with it. A model that does not exist yet can inherit the same project history. This does not make models interchangeable. Different models will interpret the same memory differently, notice different things, reason differently, and make different mistakes. The weights still matter enormously. But the history no longer disappears when the model changes.
That creates a separation I think will become increasingly important. Models can become replaceable compute while memory becomes persistent organizational state. Companies are already moving between providers, mixing local and hosted models, and allowing multiple agents to work on the same systems. We usually talk about interoperability in terms of tools and protocols. Shared memory may turn out to be another part of that layer.
Maybe this is not really an AI memory problem
I started this experiment thinking about how to give AI better memory. I am becoming less convinced that AI is the interesting part. Software teams forget why decisions were taken, why approaches failed, and which apparently stupid implementation exists because the cleaner version already exploded once. Six months later, someone “fixes” it and rediscovers the same problem in production.
Humans compensate with documentation, experience, and the one engineer who remembers where all the bodies are buried. Every fresh AI session arrives without that accumulated history, but agents are also present while the work happens and can leave a structured trace for whoever comes next. If that trace remains retrievable, auditable, portable, and resistant to stale nonsense, memory stops being an assistant feature and starts looking like infrastructure.
I have proved that the infrastructure can exist. I have not proved that retrieval will stay reliable, that the trust model will scale, or that the organizational savings will exceed the overhead. That part needs data, model swaps, real use, and probably six months of my own system finding increasingly creative ways to prove me wrong.
