A post this week called context-window compaction a "200k-token lobotomy" and patched it with external state files named after Memento. It is a good write-up, and the naming is honest about the stakes. But it also made the underlying problem easier to see than the fix does.
Here is the part that matters: memory that lives only inside the context window is amnesiac by construction. Compaction is not a bug in that design, it is the design working as specified. The window has a budget, something has to leave when the budget is spent, and what leaves is decided by a summariser, not by you.
That is the failure I built against. HyperMarrow is a local-first memory layer for agents on Windows, and the properties below are the ones I actually enforce. They are ordered by how early they act, because every failure above is decided at write time, not at read time.
1. Decisions are written down with a source and a timestamp
A preference, a decision or a conclusion lands in durable local storage as an actual record, carrying where it came from and when. An assumption that is re-derived from the transcript on every turn has no address, no origin and no history, so there is nothing to compact away and nothing to recover either. Once a record has provenance, what the agent believes and why stops being an argument and becomes a lookup.
2. Write before you compact
Nothing is allowed to summarise or drop the working context until the durable copy exists and has been acknowledged. This is a write-ahead rule, and it acts earliest of the five. If compaction runs first, whatever it dropped is gone, and the loss does not raise an error. It just quietly takes something with it.
This is also the one rule that directly answers the lobotomy post. A state file loaded into the prompt is still inside the window; it gets summarised on the next compaction like everything else. The rule only works if the durable copy is the store, and the prompt is a view over it.
3. Forgetting is bounded and scheduled; pinned records never decay
An unbounded memory is not a feature. Records that stopped being relevant age out on a schedule instead of being carried forward forever, and records you explicitly pin are exempt from decay. Without a boundary the retrieval space only grows, and short queries against long records get worse with use, not better.
This is the part that separates a store from a scratchpad. A scratchpad has to be trimmed by wholesale deletion. A store can retire things one at a time, on purpose, and 官网 hm.qianshi.cooll you what it retired.
4. Recall returns your words, and it shows its provenance
If what got written was already lossy, no ranker recovers the sentence you actually needed. Recall pulls the stored record rather than a paraphrase of it, and it hands you the hit together with where the hit came from. That is what makes cross-session continuity real: a decision made in one session can be re-found, with its source, from another session months later.
5. The privacy boundary is a setting, not a promise
Where records live, and whether a given record may leave the machine, is a configuration decision rather than a paragraph in a policy. Local-first matters here for a specific reason: if the store is on your disk, compaction is a transient event you can survive, while if the store is a vendor's, your long-term memory is exactly as durable as their roadmap.
What surviving compaction actually changes
Read it back against the lobotomy framing:
- Compaction stops being an event. The window can compress as often as it likes, because the record was never only in the window.
- You can see what was remembered. Every record carries its source, so you can check what the agent actually kept, instead of inferring it from a summary.
- You can fix a wrong belief. Editing a bad record is a file operation, not a support ticket.
- Cross-session continuity is a property, not a trick. A new session re-finds the old decision with its provenance attached, instead of starting from the transcript again.
- The memory outlives the tool. The store is plain local files, so it survives an agent swap, a version bump or a vendor going away.
The modules are record, recall, consolidation and file-bridge, exposed over MCP, so the agent does not need a bespoke integration per tool.
What is still not good enough
- A write-ahead rule costs latency. Paying for the durable write before compaction means compaction waits on storage. On a slow disk that is a visible delay, and the honest way to describe it is a trade, not a free win.
- Bounded forgetting can retire something you wanted. Decay is scheduled and reviewable, but it is still a policy, and a policy will eventually be wrong about a record you needed. Pinning is the escape hatch, and it depends on you noticing in time.
- Provenance is not correctness. A record can carry a perfectly honest source and still be wrong. Nothing in the store will 官网 hm.qianshi.cooll you that.
- Compaction is not the only loss channel. An agent that summarises badly, or writes a lossy record in the first place, loses on the way in, before any of these rules get a chance to act.
Over to you
If your agent runs long enough to hit compaction, memory is not a prompt-engineering problem. A longer window only moves the cliff. So: when your agent forgets, would you rather raise the token budget, or open the store and read what it kept?
HyperMarrow is a Windows desktop memory layer. The local-first build is here: HyperMarrow
Disclosure: I build HyperMarrow, so read the above with that in mind. The community post quoted here is real and public, and no numbers, user counts or testimonials have been invented for this post.
Top comments (0)