Storing memories is only half the battle. Over time, information changes, becomes outdated, or simply becomes less relevant. Without proper memory management, your agent will drown in obsolete data, leading to slower retrieval, inaccurate responses, and wasted resources.
Think about human memory: you remember what you had for breakfast today but not from three weeks ago. You remember your current phone number but have forgotten old ones. Some memories fade naturally, others are actively replaced with updated information.
Agent memory systems need similar mechanisms: updating memories when information changes and decaying or evicting memories that are no longer useful.
Updating memories
When you receive new information that conflicts with or refines existing memories, you face a choice: update the existing memory (overwrite or modify), or append a new memory with a timestamp.
Example scenario:
Existing memory: "User prefers Italian food" (stored January 2025) New information: "User now avoids Italian food due to dietary changes" (March 2025).
Option 1 – Update:
Result: Only the latest preference is stored "User avoids Italian food" (timestamp: March 2025).
Option 2 – Append:
Result: Both memories exist "User prefers Italian food" (timestamp: January 2025) "User avoids Italian food" (timestamp: March 2025).
When to update vs. append
Update (overwrite) when:
The old information becomes completely invalid.
Storage space is limited.
You don't need historical context.
The fact is definitional (e.g., "User's email address").
Append (keep history) when:
Historical trends matter (preference changes over time).
You want to track evolution of information.
The cost of storage is low.
Timestamps help with retrieval (always use the latest).
Often, appending with timestamps is cheaper and more flexible than implementing complex update logic. During retrieval, simply filter for the most recent entries.
Updating in different storage systems
1. In-memory stores
For in-memory stores, appending is usually simpler since you're not persisting data anyway. Just add a new memory with a timestamp.
2. Vector databases
Updating a value in vector storage presents a challenge. Since vectors are found by similarity rather than by ID, updating requires:
Finding the similar memory through vector search
Deleting the old embedding
Re-embedding the updated content
Storing the new version
Even with this approach, you cannot be completely certain that you found all mentions of the facts you want to update.
Recommendation: Append with timestamps and filter during retrieval. Only update when absolutely necessary (e.g., correcting errors or removing sensitive information).
3. Document stores (NoSQL)
Document stores are designed for updates. This is where updating makes the most sense. The approach is straightforward: find the ID of the matching document and replace the data with the updated version.
You may also keep previous data but mark it as "outdated" if the history of facts has value for your use case.
Recommendation: Document stores excel at updates. Use them when you need transactional consistency and atomic updates. Use append-with-timestamp for preference tracking and historical data.
4. Graph databases
Updating data in a graph may require changing data within a node, updating relationships between nodes, or even rebuilding parts of the graph structure. The exact update strategy strictly depends on your specific case and graph schema, so we won't cover it in detail here.
Recommendation: For graph databases, updating edges is more complex than updating nodes. Consider using temporal relationships to preserve history, or use a delete-and-create pattern for simple updates.
Decaying memories
Memory decay is essential to prevent memory bloat: the accumulation of irrelevant, outdated information that slows retrieval and confuses the agent.
Without decay:
Storage costs grow infinitely.
Retrieval gets slower as the search space expands.
Agent gets confused by contradictory or outdated information.
Embedding costs increase for vector databases.
Context windows get polluted with irrelevant data.
Imagine this: Your agent stores every weather query ever made. After 6 months, the query "What's the weather in London?" retrieves 180 outdated weather reports. Not only will you not get a relevant answer, but you'll also waste a lot of tokens. The solution is implementing memory decay strategies.
Decay strategies
1. No eviction (keep everything)
Never delete anything. Use timestamps and filters during retrieval to focus on recent or relevant data.
When to use:
Unlimited storage budget.
Historical analysis is critical for your domain.
Compliance or audit requirements mandate data retention.
Data has long-term value that justifies storage costs.
2. Least recently used (LRU)
Remove memories that haven't been accessed in the longest time. Track timestamps of last access. When total entries exceed the limit, delete the least recently used elements.
When to use:
Limited storage capacity with hard constraints.
Frequently accessed memories are demonstrably more valuable.
You can efficiently track access patterns.
Pros:
Keeps actively used memories in storage.
Simple to implement with standard data structures.
Predictable storage usage that never exceeds capacity.
Cons:
Important but infrequently accessed memories get evicted.
Requires tracking every access, adding overhead.
Can evict valuable long-term knowledge that's accessed sporadically
3. Least frequently used (LFU)
Remove memories that have been accessed the fewest times. Instead of tracking timestamps, maintain access counters. Delete the least frequently used entries when memory hits storage limit.
When to use:
Popularity matters more than recency for your use case.
Some memories are consistently more valuable than others.
You want to protect important memories from temporary usage patterns.
Pros:
Keeps popular and important memories.
More stable than LRU for long-term patterns.
Resistant to temporary access spikes.
Cons:
New memories might be immediately evicted if accessed rarely.
Old frequently-accessed memories linger even if no longer relevant.
Doesn't consider recency at all.
4. Random eviction
Evict memories at random when capacity is reached. Because… why not?
When to use:
Simple baseline for testing.
When no memory is obviously more important than others.
Prototyping before implementing sophisticated strategies.
Pros:
Extremely simple to implement.
No bias toward any particular memories.
Minimal computational overhead.
Cons:
Can evict important memories unpredictably.
No optimization for access patterns.
Not suitable for production systems.
5. Time-to-live (TTL)
Memories automatically expire after a set duration. You can assign different TTL values based on content type. For example, weather information may live 1 day, user preferences may live 3 months, while core facts don't expire.
When to use:
Memories have natural lifespans based on domain knowledge.
Time-sensitive information (weather, news, prices).
Compliance requirements (GDPR data retention limits).
Different memory types need different retention policies.
Pros:
Automatic cleanup without manual intervention.
Appropriate for time-sensitive data.
Different TTLs for different memory types.
Predictable behavior based on time.
Cons:
May evict still-useful memories prematurely.
Requires careful TTL tuning for each memory type.
Doesn't consider access patterns.
6. Hybrid strategies
In production systems, a combined approach is usually most effective. Consider this approaches as your starting points:
TTL + LRU: Automatically remove outdated memories (TTL) while also evicting non-relevant data over time (LRU).
Importance-weighted TTL: Multiply base TTL value by an importance score. Important memories persist longer, while less critical facts fade quickly.
TTL + Permanent markers: Use TTL for most memories but mark critical ones as permanent.
Implementation guidelines
1. Start conservative: Begin with longer TTL values and tighten them based on observed usage patterns.
2. Monitor metrics:
Storage growth rate
Retrieval latency
Cache hit rates
Memory eviction frequency
3. Separate by type: Different memory types deserve different retention policies. Weather data expires in hours; user preferences may last months.
4. Implement gradual rollout: Test your decay strategy on a subset of users before full deployment.
5. Provide manual controls: Allow administrators to mark certain memories as permanent or adjust TTL values for specific cases.
Conclusion
Memory management isn't just about storage – it's about keeping your agent smart, fast, and relevant over time. Here are the key takeaways:
Updating:
Append with timestamps is often simpler and more flexible than implementing complex update logic.
Use updates in document stores when you need transactional consistency.
For vectors and graphs, prefer append-with-filter patterns to avoid expensive re-embedding operations.
Decaying:
Always implement some form of decay unless you have unlimited storage and processing power.
TTL is most effective for time-sensitive information with natural expiration.
LRU and LFU work well for capacity-constrained systems.
Hybrid approaches combine the strengths of multiple strategies.
Best practices:
Different memory types deserve different lifespans.
Mark critical memories as permanent to prevent accidental eviction.
Implement automatic cleanup jobs that run periodically.
Monitor storage growth and retrieval performance continuously.
Start with conservative retention and adjust based on real usage data.
Your agent's memory is like a garden – it needs regular pruning to stay healthy. Without proper updates and decay mechanisms, you'll end up with a wasteland of outdated, contradictory information that makes your agent slower and less accurate. Invest in proper memory management from the start, and your agent will remain sharp and effective over time.