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.
Top comments (25)
Two things in here have been our own experience almost word for word, and one of them I'd push back on - not the argument, the experiment you're planning to run.
On Max's open question above, about representing supersession: we ended up needing three verbs, not one, and the split only became obvious after it hurt. All three look identical at the storage layer, because all three write a value:
Supersession - the world changed. The old record was true then and is still the correct explanation of everything downstream of it.
Correction - our record was wrong from the start. It was never true, and anything that leaned on it inherited the error.
Invalidation - not a truth claim at all, an authority claim. The record can be perfectly accurate and simply no longer govern.
A store with one verb for all three cannot answer "was the thing that misled us wrong, or merely old?" - and that is the exact question an audit asks first. A store with none, which is the usual state, silently makes every correction look like a supersession. Worth deciding before the store gets big, because retrofitting the distinction means re-reading history you no longer have the context for.
On the A/B experiment - memory on versus memory off, matched tasks. I think it has an order effect you can't randomise away, and it's worth designing around before you spend the six months.
The first run changes the repository. So the second condition doesn't operate on the same artifact - it operates on a repo where the problem has already been solved once, the conventions already exist in the code, and the ugly workaround is already there to be discovered. Memory-off in round two is not amnesia, it's archaeology against a better-documented codebase. That biases in favour of the control, which at least fails safe, but it means a neutral result tells you very little.
The version that survives that is matched task pairs rather than matched tasks: two tasks of comparable shape in disjoint parts of the system, assigned to conditions, never the same code touched twice. Harder to construct, and you get fewer data points, but each one means something.
On not being able to simulate six months. You can't age your own store, but age is available second-hand: public project histories are already old, already contradictory, and already contain the case where five later decisions leaned on one wrong early assumption. Reading someone else's five-year argument about why a workaround exists won't tell you whether your trust ladder scales, but it will tell you what shapes of contradiction actually occur, which is the part that's hard to invent from a clean store.
And the one I'd flag hardest, because it's the failure we walked into: recall is evidence of being findable, not of being right. If retrieval frequency ends up feeding your promotion queue - and it will, because a human curator notices what keeps surfacing - then the trust ladder promotes whatever is well-indexed, and the system protects its worst records with the same signal meant to prune them. Keeping those two numbers apart, findability and correctness, turned out to matter more than any single ranking change we made.
Genuine question, since your framing is sharper than most: when a correction lands, does the earlier record stay retrievable at its original rank, or does the correction inherit the rank? We landed on the first for audit reasons and it made ordinary retrieval measurably worse. Curious whether you've hit that trade-off yet, or found a way around it.
Really interesting point, but...
This is exactly where my model of memory is probably diverging a bit from a conventional knowledge store. I am increasingly thinking that memory should not try to represent an in-time snapshot of truth. It should preserve the story.
There are three mechanisms I am leaning on for that: TTL, temporal ordering, and segmentation.
TTL is the forgetting mechanism, but not a fixed expiration date. A memory that is rarely recalled should disappear relatively quickly. Every useful recall extends its lifetime, and repeated recalls increase that TTL progressively, potentially exponentially. So persistence becomes evidence that a memory continues to participate in the work, not evidence that the memory is correct. I completely agree with your last point here: recall frequency and correctness have to remain separate signals. Otherwise the most retrievable mistake eventually becomes institutional religion.
Temporal ordering handles a different problem. Suppose I implement hack X for features A, B and C. Six months later I find a much better solution for B. I do not necessarily want the new record to overwrite or invalidate the old one, because hack X is still part of the explanation for A and C, and historically it really was the implementation for B too. When that context is retrieved, I want the model to reconstruct: “X was introduced for A/B/C, later B moved to Y, while A/C still depend on X.” The useful object is the sequence, not whichever record won the last-write contest.
That is also why your supersession/correction/invalidation distinction is interesting to me. I think I still need those semantics, especially correction. If something was factually wrong from the beginning, chronology alone cannot save me because I do not want the system to narrate a false claim as if it were once true. Supersession fits naturally into the timeline. Invalidation is authority changing over time. Correction is different because it modifies how earlier history should be interpreted. I had not separated those three cleanly enough yet.
The third piece is segmentation. I do not really want a bucket called
ProjectA memory. I want something closer toProjectA/featureX/implementation,ProjectA/featureX/decisions,ProjectA/featureX/tech-debt, etc. Retrieval should first narrow the historical space and only then reconstruct the relevant sequence inside it. Otherwise chronological ordering just gives you a beautifully ordered pile of unrelated facts.So on your specific question about ranking after a correction: I am not sure I want either the original record or the correction to “inherit the rank” in the usual sense. My current direction would be to retrieve the relevant segment, preserve timestamp order, and let the correction modify the interpretation of the earlier record rather than replace its position in history. For audit purposes the original remains there. For ordinary reasoning the later correction should dominate the truth claim.
That probably makes retrieval more expensive, because you sometimes need several memories to answer what looks like one question. But I suspect that is unavoidable if memory is supposed to explain how a system became what it is rather than simply return the latest value.
And your A/B objection is right too. Running the same task twice contaminates the second condition through the repository itself. Matched disjoint task pairs are a much cleaner experiment. I had been thinking about model/session contamination and not enough about the codebase itself becoming a memory channel.
This taxonomy of mutation verbs ("Supersession", "Correction", "Invalidation") is an exceptional piece of epistemic modeling. Conflating a historical shift with a day-zero falsehood is one of the fastest ways to corrupt downstream architectural lineage.
Regarding your question on Correction Rank Inheritance, we hit that exact trade-off where preserving the historical record at its original rank poisoned everyday operational retrieval.
The mechanism that resolved it without sacrificing auditability was implementing a CQRS-style separation between the Causal Ledger and the Operational Projection:
For standard task execution, the correction inherits the rank entirely, and the erroneous record is dynamically suppressed (soft-masked) from the primary retrieval index.
Standard agent sessions operate strictly against this projected view. An agent asking "How do we handle auth tokens?" should never see the day-zero mistake in its top-3 semantic retrieval slots.
The flawed record is never physically destroyed; it is preserved in the underlying append-only graph with a:
"POISONED_AT_ORIGIN"
state marker pointing forward to the correction node.
The distinction is resolved at the query-intent layer:
Operational Mode (Default): Queries execute against the active projection. Erroneous records have zero retrieval weight.
Forensic / Archeological Mode: When an agent or engineer explicitly queries history, e.g., "Trace the rationale behind commit X" or "Why did module Y inherit this dependency?", the query engine bypasses operational ranking and walks the raw Causal DAG backward, surfacing the historical error alongside its correction metadata.
On your point about Findability vs. Correctness: tying promotion queues to access frequency creates the exact self-reinforcing feedback loop that broke early PageRank implementations.
Decoupling Access Counters (which measure traffic) from Verification Assertions (which measure code-state conformance) is mandatory.
A memory should only climb the trust ladder via explicit invariant validation or human sign-off, never through mere retrieval volume.
Outstanding contributions to this thread.
The distinction between memory and RAG here is really important. RAG gives an agent access to information; memory should preserve the history of how that information came to exist.
I also like the trust model. A persistent memory without provenance can be worse than having no memory at all, because a wrong assumption gets carried into future sessions and starts looking like established knowledge.
The part I’d be most interested in testing is exactly what you mentioned: whether memory actually reduces human correction and repeated exploration, rather than simply reducing tokens. If an agent spends a few extra tokens verifying an old decision but avoids sending an engineer down the same failed path again, that’s probably the more meaningful metric.
The “exploration tax” is a good way to frame it. Teams repeatedly pay for knowledge they already discovered, and AI agents could potentially make capturing that history almost automatic.
The six-month test will probably tell us much more than the prototype does. Contradictory memories, stale decisions, and competing agents are where this gets really interesting.
Not 100% agree, is true RAG give access to the "information". But what is the value of this information? If your RAG return data that model already had seen, maybe during training, this is almost 0 value data. Maybe can be interesting to the model "how" you organize your data, maybe in the knowledge graph, but data itself is stuff model already know. The memory is a different concept. Memory should carry whatever model discover in other sessions. So that new session are already aware of that knowledge and not need to derive again. Image you ask your agent with no memory to onboard in a project. it will cost X but if the model already has the memory that BUILD that project. The onboarding task will be way cheaper than X...
Spot-on distinction, Marco.
You're isolating the crucial difference between Parametric Knowledge (what the model already internalizes from pre-training weights) and Causal / Procedural State (the evolutionary history of decisions generated during actual engineering work).
Your intuition about the Knowledge Graph is the exact architectural bridge here:
Most teams attempt to build Knowledge Graphs purely for domain entities (e.g., "Customer A owns Invoice B"), which is often redundant with existing databases.
The real structural leverage is modeling a Decision Dependency Graph (DAG):
"[Constraint X] ──► [Rejected Pattern A (Reason: Thread Starvation)] ──► [Adopted Workaround B] ──► [Coupled Modules C, D]"
When a fresh agent onboards to a project, reverse-engineering the codebase from scratch forces it to spend massive inference compute guessing the original developer's intent.
If it can instead execute a localized relational traversal over the Decision DAG, it immediately inherits the causal lineage of constraints without relitigating settled trade-offs.
You're shifting memory from "passive document retrieval" to "compressed causal history."
That is the exact mechanism that mathematically drives down the onboarding cost delta you described.
I am glad that my opinion was helpful.
I would like to get to know you better. Would you please contact me? t_g_@CRDT_CTO
There is some truth to what you say. You seem to have extensive knowledge of programs, so I would like to get to know you.Would you please contact me? t_g_@CRDT_CTO
The write problem bit us pretty hard before we figured it out. We had agents logging progress notes after every tool call, and within six weeks the memory store had maybe forty entries covering the same five lessons in different words. Retrieval quality dropped because the agent was pulling multiple conflicting summaries of the same past decision instead of one clean record. What worked was making every write pass through a deduplication check against the last ten entries before committing anything new.
Yes, this is exactly the failure mode I am trying to avoid.
Right now I enforce “one fact per memory” and “update instead of duplicate” as part of the write contract, but that only catches the obvious case. It does not solve semantic duplication, where five agents describe the same lesson differently and all five technically look like valid new memories.
Your last-ten-entries check is interesting because it moves deduplication into the write path instead of hoping retrieval ranking will clean up the mess later. I think that is the correct boundary.
The one thing I would be careful about is automatically merging similar memories. Two entries can look redundant while actually representing evolution: “we use X because Y” and six months later “we replaced X for feature B because Z” should coexist because together they tell the history.
So I suspect the write gate eventually needs to answer something slightly richer than “duplicate or not?”: is this a duplicate, an update to the same fact, or a new event in the same story?
That distinction probably becomes very important once the store stops being six weeks old and starts being six months old.
Running an agent with a layered memory system for several months now, and this hits close to home. The provenance point is the one I learned the hard way: we ended up tagging every stored memory with its source (lived experience vs. the model's prior knowledge) plus a separate "pending verification" list, because unattributed memories quietly drift into being treated as facts — exactly your "hallucination with a pension plan." Your line "a memory that exists but is never retrieved is functionally forgotten" also matches what we see in practice: the biggest failure mode wasn't storage, it was retrieval — memories written once and never surfaced again, which we now handle with periodic consolidation cycles that promote, compress, or archive them. One thing I'd add to the team-scoped angle: the trust state shouldn't just live on the memory itself but on the writing process — who verified it and when matters as much as what it says. Curious how your prototype handles conflicting memories written by different agents on the same team.
That provenance split makes a lot of sense, especially separating “observed during work” from “the model already believed this.” Those are very different kinds of evidence, even if they eventually collapse into the same sentence.
On conflicting memories, I am moving away from the idea that the store should resolve everything into one current truth. I want memory to preserve the story of how the truth evolved.
So if two agents write conflicting memories, I do not necessarily want one to overwrite the other. They keep their author, timestamp, trust state, and source. Retrieval should happen inside a narrow segment, something like
ProjectA/featureX/decisions, and reconstruct the sequence in time rather than just returning the highest-ranked sentence.That matters because conflict can mean very different things. The world may have changed, one agent may simply have been wrong, or a previously valid decision may no longer be authoritative. Those are not the same event, and flattening them into “latest value wins” destroys exactly the history I want memory to preserve.
The trust process also carries provenance in my case: who wrote it, who reviewed it, and when. If an AI modifies a human-reviewed memory, the review state is removed. So I agree that trust cannot just be a property of the text itself; it is partly a property of the process that produced and verified it.
Where I am still experimenting is retrieval. A memory that is never surfaced is effectively forgotten, but I do not want recall frequency to become a proxy for correctness either. My current direction is to let recall affect TTL and persistence, while correctness and authority remain completely separate signals. Otherwise a very searchable mistake eventually becomes the most trusted thing in the system, which would be an impressively efficient way to institutionalize hallucinations.
The RAG-vs-memory distinction you draw — retrieval of existing artifacts vs. preservation of state the process itself generated — is the cleanest framing I've read on this. The "why we tolerate D" decisions genuinely have no document to retrieve; they only exist as a byproduct of work.
The line that stuck with me is "the interesting problem is the economics of forgetting." Because once memory is a shared external layer that multiple models read and write, trust isn't binary — a note written by last week's model under different assumptions can be actively harmful today. So you need more than storage; you need provenance (which model/session wrote this, under what context) and some decay or challenge mechanism so stale rationale gets demoted rather than confidently re-injected.
Have you landed on a way to represent confidence or supersession in the memory layer — e.g., a later entry marking an earlier one as "no longer true"? That's the part I keep circling back to: forgetting isn't deletion, it's knowing which memory to stop trusting. Curious how far you've pushed that in the experiment.
You’ve isolated the fundamental challenge of shared state across non-deterministic agents:
Forgetting is not deletion; it is causal deprecation.
If you physically delete a stale memory, you create an archaeological vacuum where a future agent will inevitably repeat the exact mistake that caused the shift in the first place.
In distributed systems and temporal databases, this is solved via three structural mechanisms:
Memories must be strictly append-only.
When an agent or engineer invalidates a previous architectural decision, it does not mutate the old file. It emits a new memory node containing an explicit causal edge:
"supersedes: ["mem_auth_v1_2026_01_15"]"
along with a structured "deprecation_rationale".
During standard session retrieval, the engine traverses the graph and suppresses superseded nodes from the active working set.
However, if an agent queries "Why did we deprecate the v1 auth service?", the traversal engine walks backward along the supersession edges to reconstruct the full historical rationale.
Every persistent memory should maintain two distinct temporal coordinates:
When a decision is reversed, you do not erase the record; you simply set:
"T_end = now()"
The memory remains in the ledger as a historical fact of what used to be true, preventing future agents from hallucinating that the past never happened.
To prevent stale rationale from quietly misleading future agents, critical architectural memories should store an explicit precondition assertion:
"assert: "dependency_version < 2.0""
When an agent loads a memory, the runtime verifies whether the assertion holds against the current repository state.
If the assertion fails, for example because the dependency was upgraded to 2.0 yesterday, the memory is dynamically demoted to:
"STALE_ASSERTION_FAILED"
This prevents the agent from blindly acting on dead assumptions without human confirmation.
The historical record survives. Its authority does not.
The provenance/trust-state work here is really good, but there's a gap between what the metadata says and what actually reaches the model: "a memory is a report, not an instruction" is a policy humans agree on, but the text itself still gets injected into context as natural language, and the model has no structural way to tell "Agent X reported this" from "do this." A memory phrased imperatively — "Always use Redis for this component" — reads exactly like a system instruction once it's in the prompt, low-trust label or not, because the trust state lives in your metadata layer, not in anything the model is forced to attend to differently. Marcus Vane's execution-sandboxing point covers the case where a poisoned memory tries to trigger a tool call, but the more common failure doesn't need a tool call at all — a memory that just shapes reasoning (skip that check, this constraint doesn't apply anymore) can bias output with nothing to sandbox. Given this store is written by agents and shared across a team, it's also now an injection surface with persistence: a compromised or just overconfident session writes something that reads as settled fact, and it keeps re-injecting itself into every future session's context until someone happens to review it. Worth treating unreviewed-memory injection into context the way you'd treat any untrusted input boundary — wrap it in something the model is trained/prompted to treat as quoted, third-party testimony rather than instruction (delimiters plus an explicit framing pass), not just a metadata flag sitting next to it.
A trust label in metadata doesn't change how the model processes the text once it's in context. "Always use Redis" reads identically whether it came from a human-reviewed decision or an overconfident agent session last week.
The fix has to happen at the injection boundary, not inside the model. Treating unreviewed memory as untrusted input before it reaches context, not just flagging it alongside. We handle this in DataGrout through Warden, which treats injected content from external sources as potentially adversarial regardless of how it's phrased. Three independent detection tiers, not a single classifier.
Detection tiers cut the odds a bad write gets classified wrong, but they still leave the decision inside the read path — the agent reads the (now-flagged-or-not) memory, then decides what to do with it. The control that actually matters is one layer further down: does a memory item's trust label ever get checked at the point where the agent turns it into a tool call, independent of whether the classifier caught it? If the only enforcement is "don't let bad text into context," a false negative in your three tiers has no second gate. If there's also an authorization check at the write/action boundary that doesn't trust any memory-derived instruction to expand scope on its own, the classifier becomes a cost optimization instead of the whole security model. Which of those two shapes is Warden — read-time filter, or is there a second check at the action boundary?
The exploration tax framing captures the real balance sheet. When people benchmark agent memory, they usually obsess over token savings or context cache hits. But developer remediation time is where the variance actually lives. An ungrounded agent that hallucinates a past decision costs 30 minutes of human debugging, which wipes out the marginal token savings for the entire sprint.
Treating unreviewed writes as low-trust reports rather than authoritative instructions mirrors how accounting handles unverified transactions. The tricky part is invalidation cascade. Once three subsequent sessions build on top of a low-trust memory, human review has to audit the whole dependency tree rather than a single markdown note.
The provenance point is the one that keeps biting in practice. An agent will write "always use Redis here" after one session that never saw the Postgres migration that already failed twice, and the next session treats that note like settled law. Treating new memories as reports with a weak trust state, then promoting only the ones a human or a later check confirms, matches how these systems actually go wrong. The part I keep watching is retrieval: a memory that sits in the index and never gets pulled is just documentation nobody opens.
Trusting everything in memory is the same failure mode as trusting everything in context. The fix people reach for is usually add more retrieval, but retrieval just decides what the agent sees, not what it's allowed to act on. Those need to be separate gates.
Marco, the trust ladder is the part I would defend hardest, and there is evidence for it that does not appear in your post. Over the past month practitioners left substantive comments on posts of mine about exactly this. Eight of them, independently and without reading each other, asked for the promotion mechanism you describe: an episode does not become policy without an explicit gate, and repetition is not that gate. Six asked for something narrower and harder, a required field naming who may revoke. Two of those six said plainly that they do not model authority in their own systems, only who closed a decision rather than whether they were allowed to.
The second number is the interesting one. It suggests the ladder is not unproven because nobody tried it. It is unproven because the rung nobody builds is the one going down.
Your own text implies that asymmetry without naming it. A review state that disappears when an AI edits it is a demotion rule. One of the eight put it as entry can be a threshold, exit is always a human. If that holds, promotion and demotion are two mechanisms rather than one mechanism running in two directions, and only the first one is cheap.
On the gap Peter and Theo raise above, the same set of comments converged on a third boundary your post does not cover: the projection into context. Metadata can carry provenance perfectly and the memory can still arrive as a flat ranked list, at which point the trust state exists in the store and not in the prompt. One of them phrased the constraint as never truncate, because truncation keeps the record and drops the relation, and nothing in the answer says so.