Jun 16, 2026

Bounded contexts for your brain

I built myself a second brain. It’s a folder of markdown files my LLM reads and writes — no plugin, no magic, just text on disk. It works, and I use it every day.

Then I plugged two of my own side projects into the same agent over MCP, and the penny dropped: they were vaults too. Suddenly I didn’t want one brain in a folder. I wanted a federation of them, each owning its own corner of my life.

Compile once, don’t re-read the soup

The seed was the Karpathy LLM-wiki pattern. The idea is simple and good: don’t make your model re-read a pile of raw documents on every single question. Keep your immutable sources in one layer, and a layer of derived wiki pages the model writes and interlinks itself. Ask a question, and it reads the compiled knowledge — not the source soup.

The work gets done once. Knowledge compounds instead of being rediscovered on every query. That’s the whole reason it beats stuffing everything into RAG.

On the left, a RAG agent connected to every raw document, re-reading all of them for each question. On the right, sources compiled once into derived wiki pages that the agent reads. — RAG re-reads everything, every time. A wiki compiles once — then just reads the answer.

What I actually kept

I didn’t follow it to the letter. I skipped the raw/ folder entirely — most of what I’d want is already sitting in my Gmail, so I pull from there with the gog CLI when I need it, and the rest I just tell the agent directly.

What I kept is the half that matters: a local pile of markdown the agent reads and writes, laid out so Obsidian can open it and I can browse it. No plugin, no MCP — just files in a format Obsidian understands.

Inputs in, markdown out, Obsidian on top. No raw/ folder.

The vaults I already had

Then I added two of my own projects into the agent over MCP — and realised they were vaults in their own right.

Rwrds (rwrds.com.au) helps you churn credit cards; it holds my whole card history so I can work out what to apply for next. Networth (networth.craigsaves.com) tracks my money — accounts, balances, expenses, total net worth. Both already expose an MCP endpoint, so I plug them straight into my agent. (Rwrds’ is public — rwrds.com.au/mcp; the Networth one I haven’t documented yet.)

Both hold true facts about me. They’re just not in my markdown folder — and, crucially, they’re not just data.

Generalist and specialists

The vault and the services do different jobs.

My markdown vault is the generalist. It knows a little about everything, but it isn’t specialised or bounded. Rwrds and Networth are the specialists — each owns one slice of my life completely, and each couples behaviour to its data.

The local vault as a broad generalist listing many topics it knows lightly, beside Rwrds and Networth as specialists that each own one slice with behaviour attached. — One knows a bit about everything. The others know one thing — and what to do with it.

Put them together and you get the shape of the thing: one generalist in the middle, specialists hanging off it over MCP, and room for more.

The federation, so far.

Why a folder of markdown isn’t enough

Why not shove all of this into markdown too? Two reasons — both lifted straight from how we build software.

One: data and behaviour, together

A markdown note can record that I had a NAB card in the last 12 months. It can’t tell you what that means. Rwrds can, because the domain logic lives right next to the facts. I ask “what card should I get next?” and it answers — it doesn’t make the agent reconstruct eligibility from a wiki page. It already knows a NAB card in the last 12 months locks me out of another for 24.

It can just give me that information. It doesn’t have to go and derive it all from the wiki. It has that behaviour built in.

In domain-driven design this is a bounded context — a self-contained island that owns both the data and the behaviour for one part of the world. The MCP tools (check_eligibility and friends) are the boundary: they compile a pile of messy internal logic into one clean call.

A markdown note records the NAB card fact but cannot say what it means. Rwrds, a bounded context, keeps the card history and the eligibility rules together, so one MCP call returns the answer. — A note knows the fact. A bounded context knows what to do with it.

Two: every fact lives in exactly one place

DRY, pointed at my own life. A piece of knowledge should have a single home, so my card history is maintained only in Rwrds — that’s its single source of truth, full stop. I don’t copy it into markdown and let it drift into a second, stale answer. The vault points at Rwrds; Rwrds owns the facts.

Kept in one home, the card history stays current. Copied into markdown, the two copies disagree and the agent gets a stale answer. — Copy a fact and you don't have two facts. You have two answers that disagree.

None of this is a knock on the markdown vault — I use it constantly. It just can’t do anything: no behaviour, no domain logic. I could bolt some on with skills, but a skill that recomputes all this on every query and writes the result back into markdown is slower and more fragile than writing the code once, in a real service, right next to the data. Code is the right tool for behaviour. Markdown is the right tool for broad, loose knowledge. The federation lets each do what it’s good at.

What it looks like in practice

Say I want to apply for the Bankwest card. I tell the agent, and it composes across all three without me thinking about it:

It draws on my local vault for broad context — who I am, that I’m actively churning.
It asks Rwrds whether I’m even eligible for that card right now, given my history. Rwrds answers from its own rules.
When the application wants my total assets and monthly expenses, it pulls those live from Networth — the one place those numbers actually live.

Applying for the Bankwest card: the agent makes three calls — the local vault for context, Rwrds for eligibility, Networth for live assets and expenses — then fills the application. — Three vaults, three questions, one application.

The agent never had to hold my whole life in one context window. It only had to know which vault owns which kind of truth — and go and ask.

Where this is going

“Bounded-context vaults” is the most accurate name I’ve got: one generalist, a handful of specialists, each carrying its own behaviour.

The open questions are the fun part. How does the agent reliably know which vault owns a given question, without me hand-wiring every case? How does a new vault announce itself? And the one I’m most into: I want that routing decision — which vault to ask — to run on a local model, so the most personal questions about my money and my history never leave my machine. The specialists stay where they are. Only the questions travel.

On your machine, a local-model router and the local vault decide which vault owns a question. Only the question travels over MCP to the remote specialists, Rwrds and Networth; the personal data stays put. — The router runs at home, and your data stays home. Only the question goes out.

That’s the shape of it: one generalist, a handful of specialists, each owning its corner and bringing its own logic, all reachable over MCP.

Less a second brain in a folder. More a federation.

More as I build it.