Six months ago I noticed I was re-deciding the same things in every Claude Code session. Stack choices, naming conventions, why we ruled out option three weeks earlier, all gone the moment the context window cleared. The agent was capable, but it walked into every session a stranger to its own past work.
I built Memento OS to fix it. Plain markdown vault, four reasoning artifact types, [D] decision, [I] insight, [E] error, [S] seed, each tagged with an invalidation trigger so the agent knows not just what was decided, but what would make the decision wrong. A skill at session start reads the active artifacts; a skill at session end writes new ones. The whole thing fits in a folder. The folder works in any AI coding tool.
It worked. After two months of using it daily, my Claude Code sessions stopped opening with the same arguments I'd already won. The agent remembered. More importantly, the agent could explain to itself what it remembered. That was the unlock, not just persistence, but persistence with structure.
I shipped the plugin. I wrote the README. I added adapters for Codex, Cursor, Windsurf, Cline, Gemini, Aider, Continue. The OSS arc looked clean from the outside. From the inside, I had a quiet conviction the system was novel.
The week the structural pattern went commodity
Last week a productivity YouTuber with about two million subscribers, mainstream-mainstream, not niche-developer, published a free Claude Code + Obsidian template. It gave away the structured CLAUDE.md / memory.md / archive.md ontology, the cascading per-project memory pattern, the 150-line ceiling. HubSpot sponsored the post with a twelve-prompt "Claude Cowork Stack." A paid course was launching alongside it.
The structural pattern I'd been quietly proud of just became commodity. Not in eighteen months. In one weekend, to a viewer base that dwarfs the entire developer ecosystem I'd been thinking about.
I sat with that for a day. The first instinct was to add features. The second instinct was to call it. The right move was something else.
What I had wasn't the structural pattern. The structural pattern was the surface layer. The part anyone could copy in a week. What I had underneath, in the year of refinement, were the rules nobody copies because nobody can see them. The grammar of an [E] error artifact, root cause AND fix. The invalidation trigger that's required, not optional. The priority matrix that's confidence times impact, not gut feel. The eviction rule that never auto-removes a [D] marked critical.
Those rules are enforceable. The structural pattern is not.
So Memento OS v2.3 is what's left when you strip the commodity layer. Two new verbs: memento:lint and memento:decay.
What enforcement actually means
memento:lint walks every _context.md in the vault and validates every artifact against the schema. Every [D] must contain an invalidates if clause, or invalidates when, or dies if. Every [E] must contain a fix: line. Every [S] must contain an activation condition. Every artifact must carry a number, a priority, a date. It exits non-zero on any violation, which means it runs as a pre-commit hook or in CI, which means broken artifacts can't sneak into the vault.
A prose template can describe the schema. It cannot enforce it. The lint rules are about thirty lines of Python regex and three lines of bash hook config. Nothing here is hard. The point is not difficulty. The point is that the lint is enforceable, and the structural pattern is not.
memento:decay does the inverse. It walks every decision older than thirty days and asks: has the invalidation trigger fired? It looks for evidence in three places, the git log of the repo for commits mentioning the trigger keywords, the current vault state for newer artifacts that contradict the old one, and finally the age itself. It ranks candidates by signal strength and surfaces them to the agent, which prompts you yes or no on each. Nothing gets superseded without your confirmation.
I ran it on my own vault. It surfaced two decisions I'd silently invalidated months ago. They were still sitting in the active table, still influencing every session, even though I'd long since changed my mind. The lint surfaced two more decisions where I'd written the conclusion without the invalidation trigger. The artifacts looked valid but were technically unfalsifiable. Those are the artifacts that hurt you. They look like load-bearing decisions but they're actually permanent.
The combined feeling of running lint and decay on my own vault was uncomfortable in a useful way. The tooling had a higher standard than I did.
Why this isn't a paid tier
I have a working schema for a team-collaboration layer, owners, reviewers, scope, status transitions, dissent threads. The acronym is DICE: decision, insight, consequence, error. It's specced for a paid product I'm building separately. I considered shipping it as the v2.3 differentiator. Two things stopped me.
The first is that Memento OS is on a different lane. It's the OSS, reputation-building lane, I sell trust through visible quality, not subscriptions. Putting team-collaboration features in Memento OS would erode the differentiator of the paid product without proportionally lifting the OSS line. The right strategic move for both is to keep DICE on the commercial side and let Memento OS lead with enforcement.
The second is harder. DICE is unproven. It's well-designed in spec, but no one is using it in production yet, including me. Shipping it in the OSS release would have made Memento OS the proving ground for a feature that should prove itself in a paid context where I can actually iterate with users. Enforcement, by contrast, I'd been doing manually for six months. The lint rules came out of patterns I was already catching by hand. The decay heuristic came out of decisions I'd already noticed going stale. Shipping enforcement was confirming what already worked.
There's a general principle hiding in here. The temptation when a structural pattern becomes commodity is to add bigger features, a team layer, a sync engine, a UI. The right move is usually the opposite: go deeper into the operating discipline you were already running, formalize the parts that are too obvious to copy from outside, and ship those. Depth is harder to commoditize than breadth.
What's next
The follow-up release is already specced. Four features from my private vault that have been quietly running for a few months, split insights to a companion _insights.md file (the cap shape changes from twenty-four entries to a token budget), pre-created class folders for OSS / SaaS / iOS projects so cross-project learnings have a home, an archive split so old artifacts don't auto-load at session start, and an emission discipline rule that says only deliberation skills are allowed to write decisions. The research skills have to downgrade to seeds. The maintenance skills are pass-through only.
That last rule is the one I'm most curious to ship. It's a fix for a problem I named "Gresham's law of context", when low-conviction artifacts auto-load alongside high-conviction ones, the LLM weighs them identically, and the bad ones crowd out the good ones over time. The rule is two paragraphs of prose and an emission_class: field in the skill frontmatter. The intervention is small. The effect should be large.
DICE will get its own release on the commercial product, with its own positioning and its own pricing. If it survives ninety days in a real paying-customer deployment, I'll reconsider whether any subset belongs in the OSS line. Until then, the team-collaboration moat stays where it can defend itself.
What I learned
The lesson isn't that you should be wary of mainstream channels. I had no influence over Jeff Su's editorial calendar, and the wider exposure for the pattern is mostly a good thing. The lesson is that the parts of your system that feel like your contribution are usually the parts most easily copied. The parts that don't feel like a contribution at all, the operating discipline, the rules you follow without thinking about them, are the parts no one else can lift, because no one else can see them.
If I'd been asked six months ago what was novel about Memento OS, I'd have said the structural ontology. I'd have been wrong. What's actually novel is the willingness to lint your own decisions.
Memento OS lives at github.com/Aiyo28/memento-os. MIT, no paid tier. The v2.3 release notes have the lint and decay flags in detail; the next-version spec for the Knowledge OS feature port is in docs/specs/. If you want to try the lint on your own vault, the --ci flag is the fast path.