How do you stop an agent's long-term memory store from growing into noise?

## The failure this prevents A memory store that only ever grows has a predictable arc. In month one it feels magical. By month six a heavy user has thousands of entries, most of them stale operational trivia, several pairs of them contradictory. Every injection now carries more marginal and conflicting material, so answers get *worse* while cost goes up — the system is paying more to be less reliable. Nobody notices, because there is rarely a metric that would show it. So the principal-level question is not "how do we store more" but "what is the steady state". A store needs an equilibrium between what enters and what leaves, and that equilibrium is a policy decision with product, cost and privacy consequences. ## Lever one: admission The cheapest memory to manage is the one never written. A useful admission test asks three things of every candidate fact: - **Is it durable?** Will it still be true next month? "Prefers metric units" yes; "is looking at the Tuesday manifest" no. - **Is it reusable?** Will it apply outside this one task? A one-off calculation is not memory, it is a result. - **Would it change a future answer?** If injecting it would produce the same response as omitting it, it is decoration. A logistics dispatch assistant should persist "this operator plans in local depot time, not UTC" and should not persist "asked about route 14 on Tuesday". The instinct to keep everything "in case it's useful" is exactly what produces the month-six store. ## Lever two: asynchronous consolidation Even with a good admission bar, entries drift toward redundancy: five separate observations that all imply one underlying preference, two entries that contradict because the world changed. Consolidation is a background pass — run between sessions, on a schedule, or when a user's store crosses a size threshold — that rewrites the store rather than appending to it. It does three things. It **merges** near-duplicates into one canonical entry. It **resolves** contradictions by recency and provenance, keeping one current version. And it **promotes**: when the same episodic pattern recurs — the operator always wants the exceptions list before the summary — that becomes a single semantic fact or, if it is a repeatable multi-step routine, a procedure stored once and loaded when relevant. Promotion is the lever that makes a store denser instead of longer, and it is only affordable because it runs offline, where a slower and more expensive model call is fine. ## Lever three: expiry by class A single global TTL is always wrong. Thirty days deletes a user's language preference; two years keeps "currently covering the north depot" long after it stopped being true. Segment by volatility: - **Identity and preference facts** — effectively permanent, removed only by user action or explicit contradiction. - **Relationship and configuration facts** — long-lived but re-verifiable; worth a periodic check rather than a hard expiry. - **Operational state** — short lifetime by construction. Often this class should not be in long-term memory at all; it belongs to the session. - **Episodic records** — keep an event log if the product needs history, but consider whether it should be reachable at injection time or archived out of the way. The useful reframing is that expiry is not deletion for storage reasons — storage is cheap. It is deletion so that a stale fact cannot re-enter a context window and be presented as current. ## Instrument it or you are guessing Minimum viable telemetry: store size per user over time (is it converging or compounding?), duplicate and contradiction rate after consolidation, and the age distribution of entries that actually reach a prompt. If injected facts skew old and the store grows linearly with usage, consolidation is not keeping up. Pair that with an offline eval that replays real sessions with and without memory — the only way to answer whether the store is net positive at all, which is a question surprisingly few teams ask after launch. ## The tradeoffs to own This is contested ground and an honest answer says so. Aggressive expiry loses genuinely useful long-tail facts and produces the "it forgot again" complaint. Aggressive consolidation loses nuance and can launder a wrong inference into a confident canonical fact — a bad merge is harder to notice than a duplicate. Doing nothing is the worst option but has the best short-term demo. There are also non-technical constraints. Scope determines blast radius: a fact promoted from one user's session into a shared or global store is a leakage vector as well as a correctness risk. And retention interacts with deletion obligations — a store you can enumerate and purge per user is the reason to keep memory in an inspectable store in the first place, so consolidation must preserve provenance rather than melting facts into anonymous prose. The defensible position: default-deny on writes, consolidate offline, expire by class, measure the store, and accept that the right settings are found empirically per product rather than copied from anyone else.