The Dev.to feed kept handing me the same idea from three directions this week: a local MCP memory server so a coding agent stops losing context between sessions, an on-device voice notebook that "cannot phone home", and local-first semantic search on Windows. That is not a coincidence of phrasing. People are moving agent memory off someone else's server and onto hardware they control.
I build HyperMarrow, a local-first memory layer for agents. Same bet, pushed all the way. But the useful part is not the ideology, it is the five rules I enforce at write time. Every failure I see in the wild is decided when a record is created, not when it is retrieved, so the rules are ordered by how early they act.
1. A decision gets 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 gets re-derived from the transcript on every turn has no address, no origin and no history. Nothing can be compacted away because there is nothing durable, and that is exactly the problem: you also cannot recover it, and you cannot 官网 hm.qianshi.cooll whether the agent still believes something you told it a month ago.
Once a record has provenance, what the agent believes and why stops being an argument and becomes a lookup.
2. The durable write happens before anything compacts, not after
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 simply gone, and the loss does not raise an error. It quietly takes something with it.
The subtle version of this failure: dropping a state file into the prompt is not a durable copy. A file loaded into the prompt is still inside the window, and the next compaction will summarise it like everything else. The rule only holds when the store is the source of truth 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 anything you explicitly pin is 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 also the line between a store and a scratchpad: a scratchpad can only be trimmed by wholesale deletion, while a store can retire things one at a time, on purpose, and 官网 hm.qianshi.cooll you what it retired.
4. Recall returns your words, with the origin attached
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 rather than decorative: 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 a black box you cannot open, you cannot see what the agent believes about you, you cannot fix a wrong memory, and one breach exposes everything. If the store is on your disk, the durable copy is in front of you, the audit trail is yours, and the whole thing exports so it is yours to back up, move, or leave with.
What moves when the store is local
- The cloud question stops being an act of faith. The durable copy is a file you can read, diff and back up.
- An agent swap is not a memory wipe. The store is plain local files behind MCP, so it survives a version bump or a different tool.
- A wrong memory becomes an edit. Fixing a bad record is a file operation instead of a support ticket.
- The failure mode changes shape. Instead of a silent loss you cannot see, you get a record you can read and disagree with.
The modules are record, recall, consolidation and file-bridge, exposed over MCP so the agent does not need a bespoke integration per editor.
What is still not good enough
- Write-ahead costs latency. Paying for the durable write before the window is compacted means compaction waits on storage. On a slow disk that is a visible delay, and the honest description 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.
- Local is not the same as secure. Keeping the store on your machine removes a class of third-party exposure, it does not remove file permissions, backups, or a compromised endpoint.
- A local store is not automatically better. If your workflow genuinely spans devices and people, a local-only store is a poor fit until sync is solved, and I would rather say that than pretend otherwise.
Over to you
None of this needs a research breakthrough. It needs storage treated as a first-class layer instead of a context window with a summariser bolted on. If your agent's memory lives in someone else's cloud, the audit trail belongs to them. Put it on your machine and the audit trail is yours to keep.
HyperMarrow is a Windows desktop memory layer, and the local-first build is here: HyperMarrow
If you already moved your agent's memory local, what tipped it for you: latency, privacy, or the fact that you could not read what it remembered?
(Disclosure: I build HyperMarrow, the local-first memory layer described above. The community posts referenced here are real and public, and no numbers, user counts or testimonials have been invented for this post.)
Top comments (0)