Mnesis
A family of tools for retaining useful context across projects, people and AI work.
- Category
- Persistent context / agent tooling
- Tags
Overview
Mnesis is about one question. How do you keep the right information around when the work spans sessions and tools?
An assistant that remembers nothing makes you repeat yourself every morning. One that remembers everything buries the good part, then starts confidently acting on stuff that stopped being true months ago.
So most of the work isn't storage. It's deciding what's worth keeping, what to show right now, and how something quietly stops counting.
Where it's at
Working
Exists today- Structured storage with scope, type, lifecycle, importance and confidence.
- A local agent integration that pulls a bounded slice of project context at session start, and keeps working when the store is down.
- A separate Markdown note system with wikilinks, scoring, session capture and graph upkeep.
- This website, reading its content from a local file.
In progress
In progress- Simplifying the interfaces.
- Deciding which system owns what.
Just an idea
Proposed- A small shared read API.
- A retrieval inspector, so I can see what got pulled and why.
- A public view of the note graph.
- An evaluation set for retrieval quality.
- Curriculum integration.
Current context paths
- Interface or output
- Processing
- Stored data
Architecture from the September 2026 project report, plus this site's current setup. A repo is not automatically a running service. Nothing syncs the database and the wiki.
The pieces
roukh-brain
- Job
- The durable store.
- What it holds
- Project identity and objectives. Memories, rules, issues and preferences, each with scope, lifecycle, importance and confidence.
- Who reads it
- The agent integration, and me.
roukh-llm
- Job
- Local agent integration.
- What it holds
- No store of its own. Skills, a safety guard, and a bounded context reader.
- Who reads it
- Coding sessions on my machine.
shapa-llm
- Job
- File-based memory.
- What it holds
- Markdown notes with frontmatter and wikilinks, forming a graph that outlives my software.
- Who reads it
- Capture and retrieval. Also a human, or Obsidian.
personal-web
- Job
- This site.
- What it holds
- A local JSON file holding only what I chose to publish.
- Who reads it
- You.
Four separate repos. Listed because the boundaries explain the design, not because each one is running somewhere.
Two stores, on purpose
The database and the wiki aren't two copies of the same thing. The database is good at structure: identity, records I want to filter, a clear lifecycle. The wiki is good at everything the database is bad at. A human can read it, git can track it, and it survives my software.
Nothing syncs them, on purpose. A row and a file can't both be the truth without stable IDs, revision markers and a conflict rule. I haven't built that, so I'm not pretending it exists.
How retrieval behaves
Bounded, not everything
A session start pulls a limited slice, not every match. The limit is the point. Context that fills the window stops being context.
Advisory, not blocking
If the store is unreachable, the session carries on without it. Memory should help the work, not be the thing that stops it.
Marked as reference
Retrieved context is labelled reference, so an old note about how something used to work doesn't get read as current policy.
Lifecycle, not just storage
Records carry status, confidence and expiry, and get replaced on purpose. Nothing silently overwrites a record for looking similar.
How notes get ranked
The Markdown side ranks on a few things instead of one number. How close a note is to the work at hand, how much it matters, how recent it is, and how often it's actually been pulled. The use count goes up mechanically on retrieval, which keeps that signal away from a model's opinion of itself.
No formula here, because I keep changing the weights. Which is also why the evaluation work below matters more than adding another scoring factor.
Capture, retrieval and review
- Interface or output
- Processing
- Stored data
Three separate paths. Capture writes, retrieval reads, and review is something I do on purpose, not something the system does to itself.
Proposed shared application context
- Stored data
- Processing
- Interface or output
- Proposed, not built
Proposed, not built. Public content would be a chosen slice of private records, never open access to the stores behind them. Today the site dodges the whole question by reading a file I maintain by hand.
What's broken or unknown
- The database and the wiki overlap and I haven't picked a winner. Drift is a matter of time.
- Retrieval quality is unmeasured. The scoring is reasonable, but nothing proves the context I pulled made the work better.
- Publishing has to be a decision. Nothing should go public because a system could reach it. That's why this site reads a file I edit by hand.
- Some of what the report describes is source code, not a verified deployment.
Next
Simplify the interfaces. Decide who owns what. Maybe a small shared API for apps that want the same context.
The one I want most: seeing what got retrieved, why it ranked there, and whether it helped. Without that, every scoring change is a guess with extra steps.
Who did what
I designed and built it. I use AI coding tools throughout. The boundaries, the calls and the mistakes are mine.
Useful collaborator: someone who's thought hard about evaluating retrieval, or who wants to argue that one big embedding index beats a small structured store plus a readable note graph. I'd rather find out early than late.