Memory Compression
Uncompressed memory will blow the window. Blind delete will drop the one constraint that mattered.
Packing a suitcase: fold, do not throw the passport.
Visual Workflows
Start here — scroll inside each diagram frame to explore, then use + / − to zoom up to 200% if needed.
Overview
Scroll inside the frame to explore · use + / − to zoom up to 200%
Scroll inside the frame to explore · use + / − to zoom up to 200%
Before the next call
Scroll inside the frame to explore · use + / − to zoom up to 200%
Compress the tail, then pack. Never compress the live goal.
Key Takeaways
- 1.Compression shrinks memory so it still fits the token budget. Drop noise, keep constraints, ids, and decisions.
- 2.Lossy is fine if the lost bits cannot change the next action. Measure: tokens saved vs answers that got worse.
- 3.Compression is lossy reduction: extract ids and rules, drop chatter and huge tool JSON. Pair with summarization.
- 4.Eval on tasks that depend on a buried constraint.
Learn elsewhere
- →Memory Summarization
- →Context Management
Real Example
Scenario
A 12k-token tool dump becomes 'query returned 3 rows, ids 18, 22, 41, none overdue' — 40 tokens, same next action.
What you would do
In Agent Memory, apply Memory Compression to this scenario: A 12k-token tool dump becomes 'query returned 3 rows, ids 18, 22, 41, none overdue' — 40 tokens, same next action. Identify the inputs, run the technique, validate the output, and note one thing you would monitor in production.
Commands
Commands to Remember
Keep ids and constraintsDrop dumps and chatterDo not compress the live goalEval quality vs tokens
Cheat Sheet
Quick recap
quick ref- •Suitcase, keep the passport
- •Lossy on purpose
- •Ids + rules stay
- •Measure regressions
Common Mistakes
- ✕Deleting the user's constraint to save 200 tokens
- ✕Compressing the current user message
- ✕No eval after turning compression on