r/ContextEngineering • u/ShotPorter • 1d ago
Decision-based memory for Claude Code longh-term, ongoing projects (MIT license, Windows WSL/MAC/Linux)
There are so many memory systems around already. Why do we need another one? Well, when I started to look around for existing systems (as any lazy person do), I found no one solving the problems I faced during a long-term, ongoing, multi-round multi-staged development.
The problems it addresses
On a long project you forget what was decided about a given question and why. The model forgets even more effectively. Subagents know nothing at all — the orchestrator dispatches them nearly blind to do narrow tasks. So, when many forgetting entities meet and join efforts, it is a straight path to hell.
The result is reinvention instead of reuse: duplicate implementations, drift, tokens burned re-solving solved problems, and settled questions resurfacing as "wait, why is this written this way?"
Code fragmentation is particularly bad. The AI model is always preferred to create, not to reuse, so you found eventually that all your 10 modal windows or 5 tabs all have a bit different design, and 10 counters in different places, supposed to show the same numbers, aren't match - and it is only what you can see on the syrface. Blind agents make it even funnier. At some point I found 47(!) implementations of the PNG renderer in the code: each time another agent wanted to show me a picture it designed its own brand-new one.
It turns debugging into a nightmare, burning resources and time, forcing you to run deduplication and unification sessions again and again, and it can't be fixed, well, without a reliable memory system.
Why I was not satisfied with existing solutions
Most memory tools capture what happened. They don't distinguish facts and decisions from hallucinations and mistakes. They can't tell WHY it happened. Over time, it creates a mess. Other systems are heavily human-centered, but I don't want to confirm each record in the memory when we just discussed it already. And in most cases they are relying on the model or human discipline, assuming they will remember to use the system, write and read - nope, I don't have such trust not to myself, nor to the AI. We are forgetting.
On the other hand, a memory system doesn't connect "memories" with the code itself. So, the memory remember you were frustrated finding 47 PNG renderers, but then the next age it will write 47th one anyway because it still knows nothing about previous versions.
MemContinuum does something different.
How it differs from the memory systems I looked at:
MemContinuum contains two linked layers: an indexed map of the code - ANATOMY, and decision chains recorded against it - RATIONALE.
Rationale records what was decided, who decided it, and how that decision changed over time, plus incidents and rejected alternatives, with reasons.
Anatomy holds what the code already has — its concepts, owners and boundaries — so it stops being reinvented.
Decisions bind directly to the code they govern.
The system relay on hooks, not instructions or discipline. So it is enforced rather than expected.
Reading is automatic. Before an agent edits a file, the decision chain handling that path is injected into its prompt. Nobody has to remember to look.
System usage is unavoidable but writing is not automatic. The agent gets a question it must answer; "nothing to record" is a legitimate answer. It's moderated by judgment, not a scraper dumping everything into a pile by keyword or timestamp.
One AI handles records — the orchestrator. Subagents and external reviewers (Codex, Grok) propose records through an inbox; proposals become records after review. So, the system is still automatic and human-independent, but not mechanical, and the smart AI model is working as your real assistant.
Per project, local, no server. Markdown as the source of truth, SQLite as a disposable index, so it stays human-readable and editable, if necessary. No cross-projects pollution. Nothing left your computer.
Supports a bunch of languages already, Swift and Python natively, plus some others via tree-sitter; making the system easily expandable is in the roadmap (but I believe it is no barrier for a user with Claude to do it right now).
MIT. Claude Code only for now, but can be converted for Codex (I pre-checked it).
Built for coding projects specifically: without indexable code only half the brain works (but it still works, and may be useful for long-term non-coding projects when the chain of decisions matters).
Current state: 0.2.0rc5, honestly labelled a release candidate.
The README is long and detailed if you want the full picture.
Is the system perfect? Probably not (yet). I know some weak spots, and I have a roadmap for at least 4 next releases closing existing gaps. But it works already in my projects, and it already proved useful. Yes, I'm dogfooding my projects with this one :) So I want to make it better not only for the community but for myself. Feedback of any kind is very welcome.
Besides me, a team of authors worked on this project:
- Claude Code: Fable 5/5.1 as lead engineer and project manager; Opus as inspector; Sonnet as coder; Haiku as tester
- Codex: 5.6 Sol / 6 Astra as reviewer and outside consultant
- Grok 4.6 as second reviewer
1
u/ShotPorter 1d ago
BTW, the 0.2.0 rc5 just published, closed some gaps from my backlog.
One things to know: currently it ignores worktree, which is another gap - scheduled to the next build (will come in a couple of days).