What Should Memory Keep?
Chapter 14 ended with an unexpectedly useful result. Once the candidate set was already good, elaborate assembly did not uncover a large reservoir of duplicate text waiting to be removed. Extractive deduplication saved only eighteen of 1,174 counted tokens on the frozen C5 bundles. The larger problem was competition: many individually defensible memories still occupied the same scarce working context, and the system had to decide what should continue to matter for the present task.
Chapter 12 made the cost of getting that wrong behavioural rather than theoretical. On matched tasks, a system given the full history scored 0.048 — below the 0.226 of a system given no memory at all, and well below the 0.393 of ordinary retrieval. More of the past, supplied indiscriminately, was worse than none of it. That is the result this chapter exists to answer: growth is not a storage problem that becomes a retrieval problem. It is a competition problem that shows up directly in behaviour.
That observation changes the next question. The problem is no longer three separate topics called consolidation, compression, and forgetting. It is one long-term problem:
As history accumulates, what should remain able to compete for present behaviour?
A memory system can preserve years of history without making every part of that history equally available on every task. It can keep raw evidence while deriving cheaper representations. It can archive a superseded belief without erasing the period in which it was true. It can stop an echo from competing as if it were independent evidence. It can retain a failure for the one future task where that old failure suddenly matters again.
The important distinction is therefore not keep versus delete. It is a four-stage distinction:
preserve
↓
represent
↓
make available
↓
admit to the present context
A raw artifact may survive forever while its derived representation changes, its retrieval availability falls, and its chance of entering a particular ContextBundle approaches zero. Those are different operations with different failure modes. Treating all of them as “forgetting” hides the engineering problem rather than solving it.
The store is not the context
Chapter 8 showed that historical truth and current truth must coexist. “The service used SQLite in March” remains true after PostgreSQL becomes current. Deleting the SQLite history to protect current answers would improve one query by corrupting another.
Chapter 14 showed the complementary point: preserving an item does not imply seating it in the current model context. The store may contain thousands of memories. The model receives a bounded working set selected for the current goal.
These results produce a useful invariant:
Exclusion from the present context is not forgetting, and preservation in the store is not a promise of present influence.
That invariant makes a smaller architecture possible. The system does not need to destroy history merely because history grows. Most growth can first be handled by changing which representations compete and under what conditions.
The chapter therefore begins with a conservative bias: preserve first, suppress reversibly, delete only for reasons stronger than convenience.
There are deployment cases where deletion is mandatory — privacy, legal obligations, secret rotation, user request — but those are deletion requirements, not evidence that age or low retrieval frequency should be treated as memory decay.
Three operations, one problem
The older plan gave consolidation, compression, and forgetting separate chapters. They remain distinct operations, but they belong inside one growth problem.
Consolidation changes what the system believes
Suppose several migration episodes all end the same way: destructive schema change arrives before compatible code and the system fails. A memory layer may derive a higher-level claim:
For this project, compatibility should precede destructive
schema changes.
That is not merely a shorter representation. It is a new claim inferred from several experiences.
The danger is epistemic. The system may overgeneralise. One episode may have had a different cause. A later case may succeed safely without compatibility mode. The pattern may hold only for one platform or one era. Several echoes of the same incident may masquerade as independent evidence.
A consolidated claim therefore needs everything the earlier book learned to demand from derived state:
statement
support set
scope
validity
exceptions
provenance
derivation time
status
and, most importantly, a way back to the raw episodes.
The raw history remains canonical. A consolidated memory is a hypothesis about that history, not a rewrite of it.
Compression changes representation
Compression is different. A compressed form should not assert a new truth merely because it is shorter.
The useful boundary comes from Chapter 14:
execution-time assembly
decides what this model receives now
durable compression
changes how long-lived memory is represented or served
The execution-time problem is already measured. The durable problem remains open.
A project may preserve every source artifact while serving cheaper derived forms for common queries:
raw artifact
↓
event / claim
↓
compact current-state view
↓
task-specific context representation
The cheaper levels answer fewer questions. The raw source remains available when the cheap form is insufficient.
The operational definition from the former compression chapter survives intact:
Compression fails when the removed information would have changed later behaviour.
That definition is task-relative. The same summary can be adequate for “where did we discuss the migration?” and inadequate for “what constraint makes this migration safe?”
Forgetting changes availability
The third operation asks which retained memories should continue to compete strongly for future use.
This is the useful meaning of forgetting for the architecture:
Forgetting is availability management before it is deletion.
Several forms fit under that heading:
retrieval suppression
historical-only archival
supersession-aware demotion
context exclusion
replacement by a derived view
hard deletion
They are not interchangeable.
A superseded SQLite decision should be suppressed for a current architecture task but available for a historical query. A verbose meeting transcript may become archival once its decision and evidence have been extracted, while remaining available for audit. A known failed approach may be old and rarely retrieved but extremely valuable when the same risky situation returns.
Age alone is therefore a poor forgetting policy. Usage frequency is also dangerous: a critical disaster memory may be exactly the item the system has not needed for two years.
Old does not mean useless
The strongest control for any forgetting policy is an old failure.
If incident-026 has not been relevant for hundreds of tasks, a usage-based policy may want to suppress it. Then another schema migration arrives. The memory is suddenly one of the highest-value pieces of history in the store.
That does not justify a permanent global importance number. Chapter 10 showed why static importance is the wrong shape. Importance is conditional on present work.
The safer rule is more modest: some memory classes deserve protection from naive decay. Candidates include unresolved constraints, destructive-action warnings, provenance keystones, evidence for current decisions, memories explicitly pinned by project policy, failures whose recurrence cost is high, and historical state required for audit.
These are policy categories, not a scalar ranking of the past.
Confidence and utility stay separate
A memory can be high-confidence and low-utility, or moderate-confidence and high-utility. The old build server hostname may be known with certainty and almost never matter. A tentative warning about a destructive migration may be uncertain and still deserve retrieval when the relevant task appears.
Truth-confidence asks:
How well is this claim supported?
Utility asks:
How useful is this memory likely to be for the present work?
One must not silently rewrite the other.
That separation becomes essential in Chapter 16, because outcomes can legitimately change expected usefulness without making a claim more true.
Store it, derive it, or rebuild it?
Consolidation introduces a design choice earlier chapters have already encountered.
Chapter 9 compared maintained open-loop state with deriving status from history. Quality matched on the controlled fixture, while the maintained view bought faster listing at the cost of staleness. The same choice appears here:
raw episodes
↓
derive pattern when needed
versus:
raw episodes
↓
maintain consolidated pattern
↓
keep it current as evidence changes
The second is faster to reuse. It also creates a maintenance obligation.
Every stored consolidated claim must be reconsidered when a supporting episode is corrected, an exception arrives, a source is invalidated, the environment changes, or the claim’s scope expires.
A derived view that cannot be re-earned becomes precisely the stale memory the chapter was meant to control.
The architecture therefore favours rebuildable derived memory. Persistence is an optimisation. Canonical history is the authority.
A growth experiment, not three mechanism demos
No dedicated growth run exists yet for the merged chapter. The earlier drafts proposed separate experiments for consolidation, compression, and forgetting, but the merged structure suggests a stronger comparison: increase the size and age of the same memory world and ask which policy preserves useful behaviour as competition rises.
A controlled sweep could grow through:
100 memories
500
1,000
5,000
10,000
while preserving a stable set of critical old memories, current decisions, historical truths, echoes, completed work, stale summaries, and ordinary background.
The conditions should compete directly:
KEEP-ALL
every retained item remains available
SUPERSESSION-AWARE
historical/current state controls live availability
ECHO-COLLAPSE
derivation-linked repetitions stop competing independently
CONSOLIDATED
guarded higher-level claims may stand in for repeated episodes
ON-DEMAND
no persistent consolidation; derive higher-level views when required
COMBINED
conservative availability + rebuildable derived views
The behavioural instrument no longer has to be waited for: Chapter 12’s controlled-outcome harness exists and is frozen, which makes current-task behaviour a measurable column rather than a promised one. Alongside it the experiment should measure historical recoverability, stale-memory admission, critical-old-memory retention, context and retrieval cost, provenance preservation, false generalisation from consolidation, and recovery after an exception or correction.
The comparison should include a deliberately old catastrophic memory. Any policy that improves mean cost while suppressing that memory fails its most important control.
Book hypothesis. Long-term memory quality will depend more on controlling competition than on irreversible deletion. Supersession-aware availability and rebuildable derived views should capture much of the value of forgetting and consolidation while preserving historical recoverability. Automatic consolidation should survive only if it improves downstream behaviour beyond raw episodes or on-demand derivation without introducing harmful generalisation.
That remains a hypothesis until the scaling experiment exists.
What the existing runs already constrain
This chapter does not yet have its own run, but earlier experiments constrain what a viable growth mechanism may do.
Chapter 7 established that repetition is not automatically corroboration: derivation and support must remain distinct. Consolidation cannot count echoes as independent evidence.
Chapter 8 established that superseded history still has historical value. Forgetting cannot equate “not current” with “delete.”
Chapter 9 showed the price of maintained derived state: faster access can create stale projections unless re-verification exists.
Chapter 10 showed that relevance is conditional on project and work state. A permanent importance value would freeze a temporary judgement into the store.
Chapter 11 showed that a staged licence over derived consequences reaches precision 1.000 where unconstrained listing reaches 0.458, and removes the harmful recommendations entirely. It declined a scalar confidence threshold by design rather than beating one in a run, and its verdict carries demotion clauses: crisp traps, ledger adjudication, no reader. Consolidation inherits both the method and the caveat.
Chapter 14 showed that simple deduplication found little value in already-selected context. This weakens the idea that repetition alone is the main long-term problem and strengthens the case for treating availability as a policy over distinct evidence.
Together these results favour a conservative design:
raw history stays
derived views remain traceable
availability changes reversibly
current work controls competition
deletion is not the default optimisation
The smallest long-lived memory
A first implementation needs surprisingly little new machinery. It needs a record of why an item is available or suppressed:
memory item
availability state
policy version
effective time
reason
source / derivation
A suppressed item is not gone. A consolidated item does not destroy its episodes. A compact serving representation points back to the source that can reconstruct detail.
The system should be able to answer:
Why did this memory not appear?
with the same seriousness Chapter 10 brought to:
Why did this memory enter the context?
That makes long-term forgetting auditable instead of mysterious.
Where this chapter stops
Growth management is still memory management. The system is deciding how retained history remains available.
The next step is qualitatively different.
Suppose a migration succeeds. Should the memories involved become more likely to influence the next migration? Suppose a sequence of actions works repeatedly. Should the system extract a reusable procedure?
Those operations do not merely decide what part of the past remains available.
They let the outcome of present behaviour change how future behaviour will be produced.
That is the point where remembering begins to become learning.
Research foundations
Several existing systems motivate higher-level memory without resolving the book’s safety boundary. Generative Agents derives reflections from accumulated observations; ExpeL extracts transferable lessons from trajectories; MemoryBank updates long-term records; RAPTOR explores hierarchical representations for retrieval. These systems support the possibility that raw episodes need not be the only useful representation.
The chapter’s stricter requirement comes from the architecture already built: any higher-level memory remains derived, versioned, scoped, and traceable to sources. A cheaper representation is valuable only while the distinctions needed for future behaviour remain recoverable.
