Externalized memory: the work has to remember

I sketched the whole externalized trust stack in the software factories post: memory, process, proof, coordination, execution. This is the one I want to sit with longer, because it is the layer the other four quietly lean on, and the one that does the most damage when it is wrong.

In that previous post I made the case that every fresh session starts slightly stupid: the code is there, but the path that produced it is not. I want you to take that as given here. Naturally the obvious move would be to give the agent a memory, capture the decisions, the gotchas, the scars, feed them back next time. I built Memento Vault to do exactly that, and I wrote up how retrieval works without spending tokens separately because the mechanics deserve their own post.

However, what I want to sit with instead is the part I got wrong at first, and still think most memory systems get wrong: a memory you can recall is not the same as a memory you should trust, and the gap between those is where the whole layer earns its keep.

Memory lies

A memory system that just stores facts and hands them back is not trust infrastructure. It is autocomplete with a longer reach. The agent already produces confident answers; that is its whole design. If I give it remembered notes and it treats every one as settled fact, I have not made it more trustworthy, I have given its confidence a citation. Now it can say “according to my notes here, the auth boundary lives on this part” with the same flat certainty whether that note is from last week or from a refactor we abandoned and never cleaned up.

Memory without epistemology is just a faster way for machines to hallucinate with confidence.

A fact in isolation tells you almost nothing about whether you should act on it. “We use optimistic locking on the orders table”: is that a decision someone made on purpose, or an observation the agent scraped from one file? When was it true? Is it still true? Did someone supersede it in a migration nobody captured? Who decided it, and were they sure, or were they guessing under deadline?

A note that answers none of those questions is not memory but a rumor with good formatting.

Receipts: where the hell did this come from?

The first thing a useful memory carries is its source. Not “system knows X” but “X was decided in this specific PR review,” or “inferred from reading this piece of code,” or “what they told me on Tuesday.”

This matters because the agent’s reaction to a fact should depend on where the fact came from. A constraint I stated explicitly should have more importance, break it and you break a promise I made. A pattern the consolidation agent noticed across a few notes could just be a hypothesis, worth surfacing but not to be treated as gospel. A thing the agent itself concluded last session and saved is the weakest of all, because it can quietly launder its own guess into next session’s authority: it remembers its own hunch, reads it back, and now it is “established and 100% true.”

Without provenance, all three look identical when they come back to agents, and that is how a single confident mistake becomes a permanent one.

Freshness: was this even true?

Code rots but decisions rot even faster.

A knowledge vault is most dangerous exactly when it has been most useful. A note that has been right twenty times earns trust, and then the twenty-first time the world moved and the note didn’t. Stale notes do not announce themselves, they simply wear the same typography as the fresh ones.

So every memory needs a date and, more importantly, a sense of decay. Some facts are basically permanent: why we chose this architecture, the incident that created a rule. Some have a half-life measured in weeks or shorter: which library version we’re on, which migration we’re mid-way through. A memory system that treats both the same is teaching the agent to be confidently out of date.

I do not have this fully solved, honestly. I’ve gone back and forth on whether decay should be automatic or curated, whether stale notes should expire or just get demoted. What I am sure of is that a memory with no notion of time is worse than no memory, because no memory at least makes the agent ask.

I’ve had plenty of cases where context gets poisoned by a stale note, it’s a hard problem to solve.

Certainty: you sure about this?

Not everything worth remembering is worth the same trust.

When I capture a decision, there is a difference between “we are certain this is the right boundary, we fought about it” and “we went with this for now, revisit if it becomes a problem.” Both are worth keeping, but only one should stop the agent dead in its tracks if it is about to violate it. The other is an invitation to reconsider, not a wall.

If memory flattens that context, if everything is stored at the same level of confidence, the agent loses the ability to tell a hard constraint from a soft default, and it picks wrong in both directions: treating a tentative note as immovable and refusing a good change, or treating a hard-won decision as a suggestion and steamrolling it. Certainty is the dial for how hard the agent should push back.

Scope: should this apply here?

A fact can be perfectly true and still wrong to apply.

“We don’t write integration tests for this” might be exactly right for the prototype service and exactly wrong for the billing service. A memory that drops the scope, the context the fact belongs to, turns a local rule into a global one, and the agent dutifully carries a prototype’s shortcut into the code that moves money.

This is the failure I worry about most as the vault grows, because it gets worse with success: more notes, more chances for a true-here fact to get recalled over-there. Pruning doesn’t fix it; I can have a small, immaculate vault and still misapply a note that was perfectly correct somewhere else. What fixes it is notes that know their own boundaries: this module, this era, this kind of work, so retrieval can be honest about whether a memory is actually relevant or just adjacent.

Externalized memory. Not a transcript of everything that happened, but a small set of durable claims that each know their own provenance, age, confidence, and scope.

Choosing what to keep, and what to let go

There’s an insidious temptation with memory to save everything. Every transcript is right there, capture is cheap, why not just keep it all? My thinking is that a vault that remembers everything remembers nothing useful. The more I store, the more noise sits between the agent and the five facts that would have actually changed its behavior.

So I’ve chosen to capture the durable parts and let the rest evaporate: decisions and the reasoning behind them, patterns that held up, gotchas that bit once and would bite again, constraints that aren’t obvious from the code. And the scars, the incident, the bad rollback, the boundary we drew in blood, because those never make it into the repo and never survive in anyone’s head past a few months.

The test I use is simple: would a competent person joining this work need to be told this, and would they fail to figure it out from the code alone? If the code already says it, I don’t store it. The vault is for the knowledge the code can’t hold.

How memory should feed the rest

I treat this layer as the foundation because the other four are only as honest as the memory under them.

Process decides what path the work must follow but a process that can’t remember why a step exists eventually loses the step. Proof captures evidence but evidence with no provenance or date is just more confident noise, the exact thing memory has to avoid. Coordination needs shared state that outlives any single agent, and shared state is just memory that multiple workers can trust at once. If the memory layer launders guesses into facts, every layer above it inherits the lie, faster and at scale.

A memory that knows where it came from, when it was true, how sure we were, and where it applies is a memory the agent can argue with. That is what I actually want: not an agent that remembers more, but one that can tell the difference between something it knows and something it once wrote down.