AI operating layer
Personal build: the setup I run my own work on
AI works on my own knowledge every day through one interface I built. In its vault server, the rules on what the model may change are code, and documents, pages and decks are scored before I see them.
Why it matters to an organisation: The same parts work for a team: a typed server over your decision records, guardrails in code, and a quality gate built from your own principles.
In brief
- Challenge: Letting AI work on almost 10,000 of my own notes every day without pasting them into chats, and without trusting a prompt to keep the rules.
- Outcome: Every Claude Code session I run starts inside it: 18 tools on a local vault server, 16 hooks and 19 skills, with every write through the server logged.
Context
I keep my working memory in a Markdown vault of nearly 10,000 notes. I wanted AI to read, search and write in it every day, without pasting notes into chats and without relying on a prompt to keep the rules. So I built one interface for it and put the rules in code.
Constraints
- The notes are personal, so the search index had to be built on the laptop and nothing could listen on a network.
- A prompt can be talked past, so the rules on what the model may change had to be enforced where the files are, not written into an instruction.
- Context is expensive, so each session had to start with only what is relevant, and long reading had to happen somewhere other than my own conversation.
Decisions
- Gave the model one typed interface: a local MCP server with 18 tools for search, graph queries and guarded writes. Every client works on the same vault, and the model reads notes through tools, so nothing has to be pasted into a chat.
- Used hybrid search: local bge-small embeddings and BM25 keyword scores over heading-aware chunks, merged by reciprocal rank fusion, so search can return a note whose idea matches when its wording does not.
- Put the write rules in the server, so writes made through it follow them whatever a prompt says. Configuration folders and the rules file are blocked, locked notes need an explicit override token, and a note without a status is refused.
- Every write through the server lands in a daily log, and every patch backs up the old version first.
- Agent notes in my project folders stay drafts until I adopt them, so I decide what becomes a record.
- Kept hooks advisory and quiet. Sixteen hooks run at session start, on each prompt, after each write and before compaction. They print a hint or a warning, exit cleanly, and say nothing when there is nothing to say.
- Added a quality gate. Documents, pages and decks are scored against principle packs built from Norman, Galitz and Filipiuk for design and from my own writing rules. A critic agent flags any critical rule it breaks; after two fix loops, anything still open ships with the issues listed.
Trade-offs
- Advisory hooks can be ignored. Blocking hooks would be stricter, and they would also become noise I learned to skip, so the server enforces and the hooks inform.
- A single-user server over stdio needs no authentication because nothing listens on a network. The cost is that it cannot be shared as it is: a team version needs authentication first.
- Search re-embeds up to 200 changed notes inline on each call, which keeps answers fresh without a background job. A bigger backlog waits for a full rebuild.
Controls and limits
Controls
- Blocked paths: configuration folders, the rules file and anything outside the vault can never be written.
- Locked notes (finished, archived or exam-ready) need an explicit override token before any change.
- A new note must carry a status, and no note may exceed 1 MB.
- Every patch is backed up first, and every write through the server is appended to a daily log.
- New agent notes in my project folders stay drafts until I adopt them.
- The search index is built on the laptop, and the server talks over stdio only.
Limits
- Single user: it runs on my own Mac.
- The write rules cover the server only. Claude Code can still edit files directly, and my machine-safety rules are written instructions that nothing enforces.
- Hooks print hints that I can ignore.
- The server talks to Claude Code over a local pipe (stdio) with no authentication, which is acceptable on a single-user laptop and unsafe on a network.
- A backlog of more than 200 changed notes needs a full index rebuild.
- No formal evaluation of answer quality yet.
- The counts change daily; the ones here were taken on 30 October 2026.
What reaches a third party
- Reaches Anthropic (Claude): my prompts, and the note excerpts the model reads through the server's tools.
- Stays on the laptop: the vault, the search index and its embeddings, the write log and the backups.
Outcome
Every Claude Code session I run starts inside this layer. The relevant notes are surfaced at the start, long reading goes to subagents that return a short answer with sources, and plans, decisions and audits land in one searchable place with a log of every write.
Evidence
- 9,976 notes in the vault, 18 server tools, 16 hooks and 19 skills, counted on 30 October 2026.
- The vault server has its own pytest suite, eight test files covering search, chunking, the graph layer and the write tools.
- The reviews behind this site's October 2026 redesign ran on it: the UI, interaction and content audits used its review agents and quality gate.
Stack
- Claude Code
- Python
- MCP
- bge-small-en-v1.5
- BM25
- NetworkX
- pytest
Architecture
- Interface: Claude Code (19 skills) — Where I work: quality gates, review councils, document builders
- Hooks: Session and write hooks (16 hooks) — Context at the start, hints on each prompt, checks after each write
- Vault server: Search (bge-small · BM25) — Semantic and keyword search, merged by rank; Graph (NetworkX) — Links between notes and central concepts; Guarded writes (MCP tools) — Create, append and patch, behind blocked paths and a write log
- Knowledge: Vault (Markdown) — 9,976 notes; Search index (NumPy) — Built on the laptop