When the US switched off Fable 5 last week, I had to move all my Claude sessions back to 4.8 overnight. However, I lost zero memory in the move.
I used Remember, a little open-source memory plugin I wrote myself for Claude, which lives entirely on your computer and is built on a protocol I think solves the structural problem with personal AI memory.
This post explains the protocol behind it.
Two modes dominate the current solution landscape. Vendor-controlled memory (e.g., ChatGPT Memory; Anthropic's Claude Projects) persists user facts in the platform's database, scoped per account, locked to one provider. Single-global-brain systems (gBrain, Roam-style global graphs, Mem at vendor scale) collapse all the user's contexts into one corpus, sacrificing per-context relevance — a household administrative question may surface coding-project results.
That's the wrong architecture.
Your AI memory should be:
Remember is the protocol that delivers this. It's structurally similar to Karpathy's three-layer note system, realized as a plugin you install once.
Four primitive verbs plus one flagship application:
And the application:
Each folder you "remember" becomes a memory project. Five typed folders for atoms (feedback/, projects/, reference/, people/, glossary/), an auto-regenerated MEMORY.md index, and an optional wiki/ layer for synthesized knowledge.
Five atom types map cleanly to common questions:
That's it. No database. No embeddings. No vendor schema. Just typed markdown on your disk, open in any editor.
The headline promise of any AI memory system is: as you work, the memory stays current. You don't have to type a save command.
This is unreasonably hard.
Earlier, Remember relied on instruction-based maintenance: the CLAUDE.md said "Continuous active maintenance: ON" and the agent was supposed to comply. Field testing revealed this is unreliable. Sessions spanning eight hours of substantive conversation produced ONE atom write — not the expected 15-20.
Why? Continuous maintenance is ambient behavior. There's no execution boundary, no defined post-condition. The agent reads the spec, intends to comply, then under attention pressure (a substantive conversation, a complex task) silently skips. The behavior is referenced in the spec but not structurally enforced.
The fix was a per-response hook. At the end of each substantive agent turn, a Stop hook mechanically runs the capture pass. The hook gives the maintenance loop the execution boundary it lacked. Plus a Lint backstop that catches under-firing after the fact.
Three tiers of memory persistence: hook-driven maintenance (structurally enforced), Lint backstop (after-the-fact detection), explicit Remember (user-initiated, fully verifiable). The user experience is "memory stays current"; the structure underneath is layered redundancy.
Remember works at personal scale. The more interesting question is whether the protocol composes upward into team and organizational scale. It does.
A shared folder (Dropbox, S3 bucket, Git repo) becomes a team memory project. The same atomic file structure, the same MEMORY.md regeneration, the same optional wiki layer. Multiple team members invoke the same verbs against the shared folder.
A company-wide memory folder — the "company brain" pattern in use at some organizations — follows the same protocol at organizational scale. Atoms capture organizational facts (people, decisions, milestones, market signals); the wiki synthesizes them into living documents (product strategy, competitive landscape, OKR dashboards). Same protocol, different scope.
The interesting feature: federation. A user maintaining personal Remember on a project might want to push specific atoms — decisions, people captures, market observations — to the company brain. The protocol's per-folder boundary makes this clean. Each scope is its own folder. Sync between scopes is explicit, user-authorized, per-atom — not bulk, not automatic, not bidirectional.
I have a "Sync to company brain" button sketched in the design doc, not yet implemented. It surfaces a four-step flow: select atoms, select target scope, preview the diff, confirm. The user controls what crosses the boundary; nothing is automatic.
This is what excites me most. The per-folder model preserves per-context relevance (a household admin folder and a work project don't bleed into each other). And the same protocol that works for one person also works for an organization. Federation through explicit sync, not implicit centralization.
sujayath.com/remember — MIT licensed, free.
There's a 7,000-word paper that goes deeper into every design decision (going on arXiv soon). DM me if you want an early read.
Building this taught me more about memory design than anything else I've worked on. If you're building memory systems and any of what I said resonates — would love to compare notes.
Locally, in plain files you own, scoped per project — not in a vendor's database. That way, switching models or losing access to one loses zero memory.
If your memory lives in plain local files, nothing — you keep it and point the next model at it. If it lives in a vendor's database, it goes with the vendor.
It's locked to one provider and lives in their database. When the vendor changes pricing, models, or terms — or a model gets pulled — your memory goes with it.
An open-source (MIT) memory plugin for Claude Cowork and Claude Code that captures your context as typed markdown files on your own machine. Get it at sujayath.com/remember.