I think we are still talking about AI memory in the wrong way. Most implementations are variations of the same pattern: store previous information,...
For further actions, you may consider blocking this person and/or reporting abuse
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 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?
Warden is the read-time filter, so your second shape is the right one. The action boundary check is a separate layer, Governor and Flow's policy enforcement, which controls what the agent can execute independent of what Warden classified. A false negative in Warden still hits the policy gate before any tool call executes. Side effect controls and approval gates operate on the action itself, not on whether the content looked suspicious.
The two layers compose: Warden catches adversarial content early and cheaply, policy enforcement at the action boundary is the guarantee that doesn't depend on the classifier being right.
Good breakdown — and it sounds like false negatives are already covered, since a missed classification still hits the policy gate before execution. The case I'd want tested separately is availability, not accuracy: what happens when Warden itself is unreachable or times out at read time? If Governor's policy enforcement doesn't depend on Warden returning any verdict, an outage in the read-time layer shouldn't change what the action boundary allows — but if Governor's default behavior differs based on whether Warden ran successfully vs. errored, that's a different failure mode than a false negative, and worth testing on its own rather than assuming it's covered by the same guarantee.
Good test to name. The policy guard doesn't take a Warden verdict as an input at all. It looks at the action itself: integration allowlist, side-effect class, destructive flag, required scopes, PII, and the arguments against policy. A forbidden write is rejected the same way whether Warden ran, errored, or was never enabled. That last case matters because Warden preflight is an explicit mode (off, log-only, advisory, enforce), not a default, and plenty of deployments run the policy guard alone.
Where an outage shows up is inside the Warden layer itself. With preflight in enforce mode, a single tier crashing forces a block and a semantic-tier timeout forces manual review, but if the whole preflight is unreachable the call proceeds to the policy gate with no verdict attached.
Warden is also callable directly as a tool, where the agent reads the verdict and decides; either way the policy gate is the guarantee and Warden is the cost saver in front of it. One clarification on my earlier wording: that boundary is the runtime policy guard rather than Governor, which handles budgets and scheduling. We'll add your outage case to the suite.
This is very close to a problem I’ve been thinking about from a slightly different direction, particularly the idea that memory belongs to the system around the model rather than to the model itself.
The part I keep getting stuck on is that the trust state eventually needs provenance too. “Reviewed” is stronger than “agent reported,” but only if we can still answer who reviewed it, what authority they had to promote it, what evidence was available at the time, and whether that authority still governs.
A memory can therefore be perfectly preserved, correctly attributed, and still stop being authoritative without becoming historically wrong. Someone leaves a role, a policy is superseded, an upstream dependency changes, or better evidence arrives. I’ve found it useful to separate supersession, correction, and invalidation for exactly that reason: “this changed,” “this was never true,” and “this may still be true but no longer governs” are different historical claims.
That also makes your point about age especially interesting. I agree that stale should not mean delete. An old record may be essential for reconstructing why the system looks the way it does, even when it no longer governs what the agent does today.
I’m increasingly convinced that persistent AI memory eventually stops being primarily a storage/retrieval problem and becomes a problem of preserving knowledge state over time: what was asserted, by whom, under what authority, what changed later, and what the system was entitled to believe at each point in that history.
Really interesting experiment. I’ll be curious to see what happens once the store has had enough time to accumulate some scars.
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.
Solid ML write-up. For production ML systems, I'd add that implementing proper experiment tracking (MLflow, Weights & Biases) from the start is invaluable — you'll thank yourself when you need to reproduce results months later.
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.
The part that bites me is stale context getting treated as ground truth. A long thread will happily reuse a constraint I already dropped two turns ago.
What helps: a 4-line brief I paste at the top of every new turn (goal, constraints, done-looks-like, out-of-scope) plus a stop line so the model cannot keep “remembering” past the job. Fresh brief beats a trusted-but-rotten history.
Good coverage of ML patterns. I'd stress that monitoring data drift and model staleness is as important as the initial training — a model that was accurate at launch can silently degrade without proper observability.
The useful distinction here is recall versus trust. A memory system should preserve provenance, freshness, and the scope in which a fact was valid; otherwise retrieval quietly becomes permission to act on stale context.
That "they know nothing about Tuesday" line really hits.
I watch this from the other side, running a directory that AI engines crawl. We've had many pages quoted in answers with zero live fetches in our logs at the time, meaning the engine was answering off an old index, not the page as it stood that day.
To publishers that's already external memory. Your content is sitting somewhere you don't control, at an age you can't see.
So the history outliving the model is already happening. What I still don't know is who's holding that copy, or how anyone would find out it went stale.
Good ML write-up. We run 12 AI tools at tools.shopveigo.com (all free to try) and model distillation has been key for keeping our costs down. The essay polisher and cover letter generator are our most popular.
The Tuesday point is the one I've been trying to explain to people for a while. We built a shared memory layer for our agents and got it working reasonably well, then changed the underlying model, and spent two days confused about why certain memories were surfacing in the wrong contexts entirely. The new model was reading our retrieval categories differently from the model that originally wrote them. We never fully solved it, we just added more verbose metadata and things got somewhat better.
The staleness section is the part I'd worry about most. Age as a confidence proxy breaks when a two-day-old memory references code that just got refactored, while a four-year-old decision record is still accurate. One cheap deterministic check that could sit in front of the trust ladder: if memories name files or symbols, the hub could flag any memory whose referenced paths changed since it was written. Not deletion, just a louder verify-first flag on read. Do your memories carry structured references to the code they describe, or is provenance only who-wrote-it-when?
the "economics of forgetting" framing is the clearest way I've seen the distinction between RAG and memory stated — RAG retrieves what already existed, memory preserves what the process produced and would otherwise lose.
what I find underexplored in most external memory implementations is write contention: when two agents update memory around the same context simultaneously and neither is aware of the other, the final write silently overwrites the rationale thread. in your HTTP hub, are writes serialized per project context, or do you rely on something like optimistic locking with a version field in the metadata? that failure mode tends to stay invisible until a long running agent starts contradicting its own earlier reasoning.
The Post-it notes analogy is the sharpest framing of RAG-as-memory I've seen. One thing I'd add from running a local-model setup at home: the "trust all of it" half is the real sleeper issue. My retrieval layer happily injected a stale note about a deprecated API endpoint for weeks — the system remembered faithfully, and faithfully wrong. Once memory moves into the system layer, you need garbage collection and provenance (who wrote this, when, was it ever verified?) more than you need bigger context windows. Otherwise you've just built a very diligent liar.
Have you found a pattern for expiring or re-validating stored memories, or does every entry effectively live forever once it's in the store?
Treating memory as a report rather than an instruction is the strongest distinction here. In practice, retrieval quality is only half the problem; the system also needs a clear way to demote a memory when its source, assumptions, or referenced code changes.
This is easily the most grounded and analytically sound deconstruction of the AI memory problem published on this platform.
The distinction between static document retrieval (traditional RAG) and decision-state preservation (why an ugly workaround exists) hits the core of organizational entropy. Furthermore, framing the economic benefit around the Exploration Tax rather than API token reduction is an exceptional systems-level insight.
Regarding the three long-term failure modes you highlighted (contradiction accumulation, scale of the index, and trust maintenance), here are three structural invariants we’ve implemented to prevent external memory stores from decaying into noise:
Instead of treating memory files as mutable documents that get overwritten or deprecated by age, we model them as an Append-Only Causal Graph (similar to Git commit trees).
When an agent or engineer records a shift in architecture, it doesn't edit the old memory; it emits a new immutable node with an explicit relation:
"SUPERSEDES: [memory_id_42]"
During retrieval, a recursive query traverses the chain and automatically suppresses superseded nodes while preserving the historical rationale of why the shift occurred.
As your memory hub scales from 50 decisions to 5,000, injecting a flat index of Markdown descriptions into the session context will eventually hit its own context-pollution ceiling.
Backing the plain-text Markdown files with an embedded, relational graph index (e.g., local SQLite tables tracking entity-relation-entity triplets) allows the agent to execute a sub-millisecond recursive traversal (CTE) to pull only the specific dependency subgraph relevant to the immediate module, keeping context overhead strictly bounded.
Treating unreviewed memories as "weak evidence" is a vital rule.
To enforce this mechanically, any tool invocation or state mutation driven by an unreviewed memory should be constrained to a capability-based sandbox, such as WebAssembly / WASI.
If a low-trust memory contains poisoned instructions or stale assumptions, the blast radius is physically trapped at the execution boundary rather than touching the host infrastructure.
Treating the LLM as replaceable, ephemeral compute and the memory substrate as durable, auditable infrastructure is the exact direction this industry needs to take.
Outstanding piece.