PRACTICE · 2.5 hours
Solve memory bloat with consolidation — recency decay, importance scoring, and LLM-assisted summarization — grounded in the support system's 3-month ticket accumulation problem.
Think of a cluttered desk versus a filing cabinet. Both hold the same information. On the cluttered desk, finding anything requires shuffling through everything — and the noise competes with today's work. In the cabinet, old materials are summarized, grouped, and stored where they won't surface unless needed.
A long-running agent's memory store becomes the cluttered desk. Without periodic maintenance, retrieval quality decays — not because the embedding model changed, but because the ratio of relevant to irrelevant memories worsens over time.
Memory consolidation is the process of:
The consolidation cycle in the support system ran nightly. After the first month, retrieval precision improved — not from any change to the vector store or embedding model, but because the noise-to-signal ratio dropped.
When consolidation matters: Consolidation is most valuable in long-running agents accumulating memory over weeks or months — support bots, knowledge assistants, agents that learn from repeated interactions. For a short-lived agent with a bounded and small memory set, the overhead outweighs the benefit.
Checkpoint: Before continuing — what would happen to retrieval quality in a support system if every ticket, including closed duplicates and outdated resolutions, were stored forever? What specific problem does that create for the agent?
The answer: retrieval returns stale and superseded results alongside current ones. The agent cannot distinguish a resolution that worked two years ago from one that is still correct. Consolidation is what keeps the store current.
Three strategies work well together. In the support system I applied them in sequence: recency decay first, importance scoring second, then LLM-assisted summarization for clusters.
The simplest strategy: score each memory by how recently it was accessed, and flag entries that haven't been retrieved in a long time. The formula uses an exponential curve — the score halves every half_life_days days.
The half_life_days parameter controls aggressiveness. Thirty days worked well for support tickets, where resolutions go stale quickly. A knowledge base of stable documentation might use 180 days or no decay at all.
Recency alone isn't enough — some memories are accessed rarely but critical when they are. An importance score combines recency with access frequency.
Heuristic weights require validation: The weights above (0.4 recency, 0.6 frequency) are not ground truth. I arrived at them by testing against a sample of support tickets and checking whether high-scoring memories were the ones agents actually needed. Validate yours the same way: pick a "gold set" of memories that should survive consolidation, run the scorer, verify they survive.
When a cluster of related episodic memories exists — ten tickets about the same billing bug — summarizing them into one semantic memory reduces store size while preserving the knowledge. This is where a language model earns its place in the consolidation pipeline.
The summarization step runs after clustering — group memories by semantic similarity first (using the cosine search from module 03), then summarize each cluster. The summary becomes a new semantic memory; the originals are archived or deleted.
After consolidation, retrieval still needs to rank results. Semantic similarity alone is not the full picture. A memory retrieved hundreds of times is probably more reliable than one retrieved once. A recently accessed memory may be more current than an old one.
The weights here match what worked in the support system: similarity dominates because the embedding model is strong, recency matters because ticket states change, and frequency is a small tie-breaker. For a knowledge base where content rarely changes, you might shift weight away from recency toward frequency.
Reflective prompt: What would a consolidation bug look like in production? Suppose the recency threshold is too aggressive and prunes a memory that is rarely accessed but critical when needed — an edge-case resolution for a rare billing error. How would you detect that before users reported missing context? What logs or metrics would catch it early?
Summarization handles clusters of related memories. Compression handles individual long memories — converting a verbose episodic entry into a compact semantic fact.
In the support system, some ticket resolutions included full conversation transcripts. Storing them verbatim was expensive and made retrieval noisy. Compressing each to a two-sentence summary preserved the knowledge without the noise.
Compression is one-way: Archive the original before deleting it. In production I kept originals for 90 days before permanent deletion — long enough to catch cases where compression lost critical detail.
The support system eventually grew to three agents: one for triage, one for resolution lookup, one for escalation. All three read and wrote to the same memory store.
In the Python orchestration framework I use, shared memory works through a central store that each agent accesses through the same interface. The critical constraint: writes are tagged with the agent that created them.
Agent attribution makes it possible to audit conflicts — if the triage agent and resolution agent store contradictory memories about the same issue, the tag tells you which agent produced each version. It also lets you retire an agent's memories cleanly when the agent itself is replaced.
Multi-agent write contention: Two agents writing simultaneously can produce duplicate or conflicting entries. In production, serialize writes through a queue or add a deduplication step to the consolidation cycle.
1. What is the primary reason memory consolidation improves retrieval quality?
Correct Answer: B
Consolidation improves retrieval by removing stale, duplicate, and low-value memories. The embedding model and vector store stay the same — the store simply becomes more signal-dense.
2. When would you NOT use memory consolidation?
Correct Answer: C
Consolidation adds complexity and compute cost. A short-lived agent with a small, bounded memory set doesn't need it — the overhead outweighs the benefit.
3. What is a key risk of setting the recency decay threshold too aggressively?
Correct Answer: B
Aggressive pruning can remove memories that are rarely needed but critical when they are — for example, edge-case resolutions or compliance-related entries.
4. Why are the importance scoring weights (0.4 recency, 0.6 frequency) described as starting points?
Correct Answer: C
Heuristic weights reflect the tradeoffs in a specific system. They must be validated against real data — what works for support tickets may not work for a documentation base or personal assistant.
5. What does tagging memories with the agent_id enable in a multi-agent system?
Correct Answer: C
Agent attribution lets you trace which agent produced a memory, identify conflicts between agents, and retire an entire agent's memories cleanly when the agent is decommissioned.
6. What is the role of LLM-assisted summarization in the consolidation pipeline?
Correct Answer: B
LLM summarization compresses clusters of related episodic entries into reusable semantic knowledge, reducing store size while preserving the pattern and resolution.
7. In the composite retrieval ranking function, semantic similarity gets the highest default weight (0.6). Why?
Correct Answer: C
Semantic similarity gets the highest weight because a strong embedding model accurately captures meaning. Recency and frequency are useful signals but are weaker tie-breakers, not the primary relevance indicator.