Memory Design Patterns

Memory systems repeatedly solve the same hard problems under different names. This library extracts those solutions from the repositories in the atlas and presents them as implementation patterns rather than product features. Not all of them are settled practice — a few rest on one or two implementations, and the section below says which.

Each pattern explains the problem it addresses, its architectural shape, why it works, where it fails, examples from the analyzed systems, and the tests needed before relying on it.

How to use the library

Patterns are not a checklist. Start with the failure you need to prevent:

• Wrong facts return after correction: use a rejected-value tombstone with a trust-state machine.
• Memory cannot be audited: use evidence before belief and an append-only memory audit.
• Retrieval is plausible but misses exact facts: use hybrid retrieval fusion.
• Memories leak across projects or users: make scope a first-class key.
• Different integrations write with different rules: add a governed write gateway.
• Private and shared memory are mixed: require an explicit write destination.
• Retrieval repeats one document: assemble source-diverse context.
• Automatic extraction loses data on failure: build recoverable background work.
• Changing facts overwrite useful history: add bi-temporal fact validity.
• Old memory overwhelms recall or popular errors self-reinforce: separate decay and reinforcement from truth.
• Model latency or outages make capture unreliable: add a zero-LLM capture path.
• Memory is a swappable backend and "forget me" has nowhere to go: fix the pluggable memory provider contract.
• Retrieval runs every turn and irrelevant memory bends the answer: gate the expensive path.
• The agent rediscovers how to do things it already solved: store skills as procedural memory behind a verified-execution gate.
• Contradictions are detected and nothing clears them: resolve, don't just detect.
• Memory has tiers and nobody can say what promotes between them: promotion between tiers.

How established is any of this?

A pattern library implies settled practice. For several of these, that would be false, and the difference matters when you are deciding what to build.

Where the atlas has an exact count — the seven mechanisms on the rubric — the spread is wide:

Read the bottom two rows as what they are. A mechanism present in two or three systems out of one hundred and twenty-nine is not a best practice. There is no consensus behind it, no library that gives it to you, no shared vocabulary, and nobody to ask when your implementation has a hole. Adopting it means building it.

And in the tombstone's case the provenance is narrower still. It was not designed by anyone: a red team walked a rejected value back to verified in three steps, and Verel's fix became the mechanism. The second system carrying it adopted it after the survey that became this atlas flagged its absence, and the third arrived at a weaker form independently, keyed on exact text rather than a normalized value — so the field has produced this idea once in the form that survives an attack. The rejected-value tombstone page traces the whole chain.

The outside view agrees, in the way that costs the atlas something to admit: the field's most comprehensive survey of itself (arXiv:2512.13564, 107 pages, 47 authors) does not contain the words tombstone, rejected or negative anywhere, while its trustworthy-memory section asks for "verifiable forgetting and auditable updates" as future work. So this is not a practice the atlas is reporting late. It is a mechanism three small repositories have and the literature has not named — which is either the atlas being early or the atlas being wrong about what matters, and one survey cannot tell you which.

So this library is doing two different jobs at once, and it is worth knowing which one you are reading:

• Reporting. Promotion between tiers, hybrid retrieval fusion, scope as a first-class key, evidence before belief, zero-LLM capture and recoverable background work describe things many systems already do. The pattern refines a practice that exists.
• Advocacy. Rejected-value tombstone, resolve, don't just detect and the negative-eval discipline inside source-diverse context rest on one or two instances. The atlas is arguing for them, not reporting them.

The advocacy patterns are the ones this atlas thinks matter most, which is exactly why they need the disclosure rather than the benefit of the doubt. A reader who assumed they were industry practice — as their author did until tracing the history — would be adopting them on the strength of an argument, not a consensus. That may still be the right call. It is a different decision.

A third case, added later and needing its own label. Retrieval hysteresis and memory as an editing surface are neither advocacy nor general reporting. They are well-established inside one category and unknown outside it. Both are mature, refined against very large user bases, and almost every instance is a roleplay or companion client — SillyTavern, RisuAI, N.E.K.O., Soul of Waifu, Z-Waif. No extraction-based system in this atlas carries per-unit activation state, and the systems that hold human_review mostly offer approval of a queue rather than an editor over the store.

That is a different epistemic situation from a mechanism three repositories invented. These are known solutions to problems the rest of the field has, sitting in codebases the rest of the field does not read — which is worth stating plainly, because it was a reader pointing out the atlas had described these mechanisms six times without ever collecting them that produced both pages.

Stacks, by what you are building

Patterns are usually read one at a time, which hides the thing that actually breaks systems: they fail at the intersections. A rejected-value tombstone is decorative if three ungoverned write paths bypass the check. Hybrid retrieval is actively dangerous without scope as a key, because better recall means a wider blast radius when the boundary is missing. An audit log is unreadable if the evidence it references was discarded.

So the useful unit is a stack rather than a pattern. Which stack depends entirely on what breaks if your memory is wrong, and that is a product question this library cannot answer for you:

The last row is the one this atlas has the most to say about, so it gets the rest of this section. Read it as one stack among several, not as a bar the others fail to clear: a fast CRUD memory for a single user genuinely does not need a tombstone, and saying otherwise would be gatekeeping.

The correctable stack

Four patterns close the three failure modes this atlas argues are the real ones, and each of the four exists to make one of the others enforceable:

Build them in that order. Each one is cheap on its own and expensive to retrofit — scope in particular, because it has to reach the schema, the indexes, the cache keys, and every background job, and adding it to a store that already has data is the hardest migration in this list.

What you can defer. Bi-temporal validity, hybrid retrieval fusion, decay and reinforcement and source-diverse context are all improvements to memory that already works. None of them prevents a silent failure; they make a functioning system better, which is a different and less urgent job.

What the four do not give you. They make memory correct and correctable. They do not make it good: nothing above decides what is worth remembering, and that judgement — see gate the expensive path and the trust-state machine — is where the quality actually comes from. Correct memory full of trivia is still a bad product.

No system in the atlas has all four. Filter the homepage by tombstone and scope to see how quickly the corpus thins out.

And be clear about what that thinning means. Four of one hundred and twenty-nine systems carry a tombstone, so this stack describes almost nobody. Two readings are available and this atlas cannot settle between them: either the field has not yet paid for a failure it will pay for later, or the cost genuinely exceeds the benefit for most products and the three holders are unusual rather than ahead. The establishment section says which patterns rest on how many instances; take the deferrals above seriously, and if none of the failure modes here is the one that would hurt you, build the smaller stack.

What the four cost together. Each page states its own cost; the compounded bill is what nobody budgets for, and it lands in two places.

Storage stops being bounded by what you believe. Evidence before belief keeps the raw event that a claim was derived from, tombstones keep values you decided were wrong, and bi-temporal validity keeps superseded versions rather than overwriting them. Together they mean the store grows with everything that ever happened, not with what is currently true, and the three retention policies are separate decisions — evidence, tombstones and history age out on different clocks, or should. A system that adopts all three and writes one TTL has not thought about it.

Writes get a hop they did not have. A governed write gateway means no path writes directly: every one proposes, gets checked against scope, dedupe, conflict and the tombstone ledger, and only then commits. That is a latency cost on the write path and a complexity cost on every integration, which is exactly why it has to be the only path — a fast bypass reintroduces the failure the gateway exists to prevent, and does it silently.

What it does not cost is context. A reasonable misreading of the tombstone pattern is that the agent must be told what not to believe, spending prompt budget on negative facts. It does not: a tombstone is consulted on the write path, before a value is allowed to become active, and is suppressed from recall entirely. If rejected values are reaching your prompt, the mechanism is misplaced. The one measured warning in this atlas about context cost points the other way — see gate the expensive path, where the expense is retrieving memory at all, not retrieving negative memory.

What is deliberately not a pattern here

Three mechanisms a reader would reasonably expect are absent, and their absence is a position rather than an oversight. Stating it, because an unexplained gap in a pattern library reads as ignorance of the field.

Summarization and compaction. The single most common answer to context overflow, and this library treats it as an antipattern rather than a pattern: see chained lossy summarization in the comparative report. The reasoning is that a summary which replaces its source has no per-fact identity, so nothing in it can be corrected, scoped or deleted — and the atlas's evidence for that is not theoretical. CowAgent rewrites its long-term file nightly from itself plus one day's notes; RisuAI summarizes its own summaries and its team replaced that design twice. Compaction is a real and necessary technique; the position here is that it belongs to the context window rather than to the memory layer, which is also why conversation-window management is outside this atlas's scope test. Evidence before belief is the pattern that makes compaction safe — summarize freely once the source survives the summary.

Working-versus-long-term as an architectural split. Nearly every system here has tiers, so a pattern saying "have tiers" would report a fact rather than a choice. Promotion between tiers exists instead, because the discriminating question is not whether the tiers exist but what moves a memory up one — and far fewer systems can answer that.

Context-window pruning and prompt-cache preservation. Genuinely important, and genuinely a prompt-assembly concern rather than a memory-lifecycle one. The atlas records the interaction where it bites — an injection that changes every turn invalidates a provider's prefix cache, which several reports note — and gate the expensive path covers the decision not to retrieve at all. A pruning pattern would be about token budgets, and this library is about what survives a session with an identity.

If you think one of these is misfiled, the disagreement is about the scope test rather than about the mechanism, and that test is stated at the top of the comparative report.

Composing them

The patterns compose. A serious memory layer normally needs several, but each additional mechanism has operational and cognitive cost. Every page now states that cost explicitly under Cost to adopt — what you must build, what it forces on the rest of the system, what it costs to keep running, and when to skip it. Add the smallest set that closes a demonstrated failure mode.

To check which systems already implement a given mechanism, see the capability index in the comparative report.