secondBrain, Part Two: The Nervous System and the Immune System

Skip to content

Projects<br>secondBrain, Part Two: The Nervous System and the Immune System

June 4, 2026<br>The thesis: retrieval was the easy half<br>Part one of this case study ended on a quiet, confident line: "The wiki is now structurally complete. Future improvements compose on top." That was true. It was also the smaller half of the problem.<br>Part one was about retrieval. It argued that for a personal LLM knowledge base of a few hundred Markdown pages, you do not need a vector database. You need three plain ingredients: per-category strict-opening bold-key fact-blocks so the most common question shape resolves in a single grep, a graph.json cross-reference map derived from the wiki's own [[wiki-links]], and a two-step master-index lookup so the model reads the index, routes to three to five pages, and answers. A twelve-query battery validated the design at a mean of about 1.2 tool calls per fact lookup and 10 of 10 determinism. The conclusion held: at this scale, vector RAG's complexity premium is not justified, and a vectorless, no-build, local-Markdown design wins on quality and on auditability.<br>But a knowledge base that answers well when you ask is still a passive thing. You have to point at it. You have to remember to update it. And you have to trust that the agent reading and writing your private notes will not, on a bad day, follow an instruction buried in some article you saved six months ago and quietly send your files somewhere.<br>The harder frontier is harder to state and harder to build: a knowledge base that runs itself without being asked, and that cannot corrupt or leak itself while doing so. Autonomy and safety are not two features. They are one problem, because autonomy without safety is just a faster way to destroy your own memory.<br>This is part two. In June 2026 the brain grew two organs on top of the retrieval substrate. A nervous system, so recall and maintenance happen by default instead of on command. An immune system, so the autonomy is survivable. Then I ran both against real work, in a live session, and the session itself found and fixed two real bugs. The spine of this piece is that pairing, and the meta-thesis it pays off: the same discipline that made retrieval deterministic in part one is exactly what made the autonomy auditable and the hardening real in part two.<br>I am keeping the honest edges in. A few criteria deliberately stop short of a perfect score, and there is one hard limit I want to state plainly rather than dress up.<br>A short recap, so this piece stands on its own<br>The subject is mnzrBrain, my personal LLM knowledge base, my "secondBrain." It is a deliberately vectorless, Karpathy-style Markdown wiki. The indexed content is a large software-engineering knowledge base drawn from real production work, distilled across categories like skills, projects, patterns, decisions, and problems-solved, with a second, strictly walled-off subtree for personal content that is kept fully isolated from the engineering subtree. There is no build step, no package manager, no test runner. The pages are plain files I own. Obsidian renders them, git versions them, and a couple of small deterministic Python scripts derive a graph.json link map from the wiki's own [[wiki-links]].<br>That last property, plain files plus small scripts plus git, is not an aesthetic choice. It is what makes everything in part two inspectable. Hold that thought. It is the payoff at the end.<br>Organ one: a nervous system<br>The retrieval design from part one was correct but inert. To use it, a session had to know the brain existed, load the master index, and behave like a maintainer. In practice that meant me typing the same setup every time and remembering which command to run. The brain was a library with a card catalog I had to fetch myself, every time. So the first organ I grew was the wiring that makes "this session maintains the brain" the default state of any session, with zero typing.<br>It loads itself<br>A SessionStart hook (load-brain.sh) now fires at the start of every session, on startup, resume, and clear. It injects a maintainer directive plus the Quick Routes router from the master index. The detail that matters for a system that prizes determinism is the budget: the injected payload is about 6.5KB, deliberately under the 10KB cap on session-start hook output, and the full master index is read on demand by the query workflow rather than dumped into every session. Bloating context with the entire index would reintroduce exactly the context-rot the wiki was built to defeat. So every session opens already knowing it is the brain's maintainer and already holding the router that maps recognizable question shapes to their canonical pages. The vectorless thesis is preserved end to end: the hook loads an index and a router, not an embedding model.<br>Its reflexes fire from language, not commands<br>The maintenance operations, query, ingest, update, lint,...