Building a Second Brain That Files Itself

I’ve started a dozen personal knowledge bases in my life and watched most of them die the same way: not from a lack of information, but from a lack of filing. Capturing is easy; the ongoing work of summarizing, linking, cross-referencing, and keeping it all coherent is a chore, and chores lose to real work every time. So the latest one is built on a different premise, and it’s the first that hasn’t rotted: I supply the raw sources and the questions, and an LLM does the compiling and the bookkeeping — the exact part that used to kill the whole thing. Here’s how it’s put together and why the division of labor is the point.

The premise: separate the sources from the knowledge

The core design decision is a split between two layers:

• Raw sources, immutable. Whatever I want to remember — an article, a paper, a thread, a set of notes — gets dropped into the knowledge base as-is and never edited. It’s the archive: the original, untouched, so I can always go back to what was actually said.
• The wiki layer, LLM-maintained. On top of the raw sources sits a web of interlinked pages — one per concept, per entity, per source — written and continuously updated by an LLM. This is the part I actually read and query, and it’s the part the machine tends.

Knowledge accumulates in that wiki layer instead of being re-derived from raw documents every time I have a question. That’s the whole game: I compile a source into the wiki once, and every future question is answered from the compiled, connected knowledge — not by re-reading the source from scratch. It’s the practical realization of an 80-year-old idea about linked personal knowledge, with the maintenance finally offloaded.

Three operations run the whole thing

The system is driven by three verbs, and once you have them, running a knowledge base becomes almost mechanical:

• Ingest. Point the LLM at a raw source. It reads the whole thing, writes a summary page, then updates every existing page the source touches — adding to concept pages, cross-linking to related notes, reconciling with what’s already there — and records that it did so. One source in, many pages updated and connected.
• Query. Ask the knowledge base a question. It answers from the compiled wiki, not by re-reading raw sources — and good answers get filed back as their own synthesis pages, so asking a question literally grows the knowledge base.
• Lint. Periodically, have it audit itself: find contradictions between pages, stale claims, and orphan notes that nothing links to. This is the health check that keeps the web from quietly decaying.

Ingest grows it, query uses it and grows it, lint keeps it honest. That’s the entire operating loop.

The LLM does the bookkeeping, and that’s why it survives

Here’s the part that makes this work where every previous attempt failed: the tedious, never-finished maintenance — the summarizing, the linking, the “does this contradict what I wrote last month,” the keeping-the-index-current — is exactly what an LLM is good at and what humans reliably abandon. I keep the two jobs that need a human: choosing what’s worth ingesting (curation, taste, signal) and asking the questions (knowing what I actually want to know). The machine does everything between.

That division is the design, not a convenience. The reason knowledge bases die is that the connective tissue is a burden; move the burden to something tireless and the base stays connected and alive. It’s the same reason a handoff file keeps a long-running agent continuous — you offload the bookkeeping the human won’t sustain.

Why a linked wiki, not a pile of embeddings

The obvious modern instinct is “throw the documents in a vector database and retrieve chunks.” I went the other way on purpose, and it’s held up: a maintained web of linked pages is a different, often better thing than similarity search over raw text. It carries accumulated understanding — a concept page reflects everything I’ve ingested about that concept, reconciled and connected — rather than returning whichever raw passages happened to be nearby in vector space. For a personal knowledge base you actually read and reason with, compiled-and-linked beats retrieved-and-raw, which is the case I’ve made before for why you probably don’t need a vector database to have a genuinely useful second brain. The links are the value — the same reason I write everything down and connect it in the first place.

What it takes to keep honest

Two disciplines keep it trustworthy. First, raw sources stay immutable — the LLM writes the wiki layer, never rewrites the archive, so there’s always ground truth to check the compiled pages against. Second, contradictions get flagged, not silently overwritten — when a new source disagrees with an existing page, the system surfaces the tension instead of quietly picking a winner, because a knowledge base that hides its disagreements is lying to you. That’s a small guardrail with a big payoff: I can trust the wiki because I can see where it’s uncertain and always trace back to the source.

The result is the first personal knowledge base I’ve kept that genuinely compounds — every source makes it denser and more connected, every question makes it a little bigger, and the filing that used to kill these projects just… happens. I bring the taste and the questions; the machine brings the tireless tending. If you’ve built a self-maintaining knowledge base — or have opinions on compiled-wiki vs vector-search — I’d like to compare approaches.