Most memory implementations for AI applications are append-only. New memories go in, nothing ever comes out, and every stored item stays equally retrievable forever. That works fine for the first few hundred entries. It stops working somewhere in the thousands, and the failure is quiet, because retrieval quality drops while every dashboard still looks healthy.
The fix is not a bigger vector index. It is a lifecycle, meaning a set of rules for how a memory gets created, strengthened, merged, and eventually dropped.
Four problems compound as the store grows.
Contradiction. A user says in January that they prefer Python for new projects. In March they say they moved to Rust. Both memories sit in the store with equal weight. In April the assistant retrieves context for a coding question and may surface either one, or both. Nothing in a plain vector store knows that March supersedes January.
Staleness. Documentation gets rewritten, endpoints move, people change roles. A store that never forgets treats a two year old API reference with the same authority as one written yesterday, and similarity scoring will sometimes prefer the older entry because it happens to be longer and more detailed.
Cost. Every memory costs storage, embedding compute, and a slot in the candidate set that gets scored at retrieval time. Fifty thousand memories where thirty thousand are stale means paying more money to get worse answers.
Retrieval noise. Top-N retrieval returns the N most similar items. As the ratio of useful to useless entries falls, more of those N slots go to junk, and the thing the user actually needed gets crowded out.
Create. The memory enters with its content, extracted entities, an embedding, and a starting confidence that is deliberately moderate, because new uncorroborated information should not carry full authority on day one. Entity extraction also wires it into the graph, so it becomes findable through association and not only through text similarity.
Promote. Memories earn their place through use. Retrieval that goes well raises activation, and repeated corroboration across separate conversations raises confidence. Something confirmed in three different contexts should resist decay better than a one-off remark, which is roughly how human expertise behaves.
Consolidate. Over a few weeks you accumulate four memories about the same CI pipeline, captured at different times with different levels of detail, one of which corrects an earlier mistake. Consolidation merges them into a single authoritative entry that keeps the correction and drops the superseded version.
Forget. Entries that nobody retrieves, that carry low confidence, or that a consolidated version has already replaced fall below threshold and get archived or deleted. Forgetting here is maintenance, not data loss.
Consolidation is the stage that separates a managed lifecycle from a tidier append-only store. It clusters related memories using entity overlap and semantic similarity, then evaluates each cluster for redundancy and contradiction.
Redundant entries merge into the most complete and recent version. Contradictory entries get resolved on recency, confidence, corroboration count, and specificity, with the loser demoted or removed rather than left to compete at query time.
The merged entry inherits the combined confidence, the strongest activation from the group, and the union of the entity connections, which makes it reachable through more paths than any single source was.
In practice a weekly consolidation pass over ten thousand entries tends to leave six to seven thousand, with no information lost. Retrieval improves because the candidate pool is cleaner and each survivor carries more.
Small changes do not need any of that. When a version number or a job title changes, a diff-based update edits the existing memory in place and carries its activation history forward, instead of stacking a near-duplicate next to it.
The decay model comes from cognitive science. Ebbinghaus showed in 1885 that retention drops sharply at first and then flattens into a long slow decline, and ACT-R formalized that into a base-level activation equation with a tunable decay parameter.
That parameter is the knob worth thinking about. Customer support systems usually want faster decay, because product details change and old troubleshooting steps go wrong quickly. Research and legal systems want slower decay, because a document from two years ago may still be the authority on its subject.
Decay also interacts with confidence. Well corroborated memories with strong entity connections should fade more slowly than one-off observations, so established knowledge persists while noise disappears on its own.
If you are running an append-only store today, the cheapest first move is not consolidation. It is timestamps and a decay parameter, so retrieval stops treating a two year old entry and a fresh one as equals. Contradiction resolution is the second move, because it is the failure users actually notice and complain about. The full breakdown of the lifecycle, including importance scoring and contradiction handling, is here: https://www.adaptiverecall.com/memory-lifecycle/
The memory system these stages come from is at https://www.adaptiverecall.com/