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