How to build a second brain that maintains itself

Every note-taking system I tried died the same way: I was great at putting things in and terrible at maintaining them. So I stopped maintaining it. An AI agent does the filing, cross-linking, and cleanup, and my only job is feeding it things worth remembering and asking it good questions.

01The idea: a wiki, not a search engine

The usual way to give an AI your notes is to dump them in a folder and let it search them when you ask something. That works, but nothing accumulates. Every question starts from scratch, re-reading raw sources and re-deriving the same conclusions.

A second brain flips that. When something new comes in, the agent reads it once, writes it up as a proper page, and updates every existing page it touches: strengthening claims, adding cross-links, and flagging when new information contradicts something older. The knowledge compounds. By the time I ask a question, most of the synthesis is already done and sitting in a page.

I didn't invent this pattern. It's Andrej Karpathy's "LLM Wiki" gist — the idea that instead of an LLM re-reading raw documents on every query, it incrementally compiles them into a persistent, structured wiki. I just built the vault, wrote the schema, and have been living in it for three months.

The compounding has a second, more practical payoff: token cost. A raw-notes RAG setup re-feeds the model chunks of source material on every question, so cost and latency scale with how much you've written down. A wiki page is already the compressed, synthesized answer — reading three linked pages is a fraction of the tokens of re-reading the five source documents behind them. Combined with index.md → MOC → page navigation, the agent only ever loads the branch relevant to the question, never the whole vault. In effect, the wiki acts as a working, external context window with no size limit: the model's actual context window stays small and cheap per turn, while the vault itself holds hundreds of pages of accumulated knowledge it can selectively pull from indefinitely.

The split of work is simple:

• Me: choose what goes in, ask questions, make decisions.
• The agent: everything else. Summarizing, filing, linking, logging, and keeping the whole thing consistent.

02Setting it up, step by step

You need two free-ish tools: Obsidian (a Markdown editor that turns a folder of .md files into a linked wiki) and Claude Code (an AI agent that can read and write files in a folder). There's no database and no plugin. The whole system is plain Markdown files plus one rules file.

Step 1: Make the vault and give it a skeleton

Create an Obsidian vault and add numbered folders so every page has an obvious home. Mine:

00 Inbox              # raw sources waiting to be ingested
01 Maps of Content    # one index page per domain
02 Projects           # one page per project
03 Concepts           # how things work
04 Architecture       # system designs
05 Patterns           # reusable recipes
06 Decisions          # why I chose X over Y
07 Troubleshooting    # problem → fix
08 Reference          # cheat sheets, API notes
09 Archive            # superseded pages
Claude Sessions       # raw transcripts, read-only
CLAUDE.md             # the rules
index.md              # entry point
log.md                # append-only history

Step 2: Write the rules file

This is the whole trick. CLAUDE.md sits at the vault root and Claude Code reads it automatically at the start of every session. It tells the agent what its job is, where things go, what every page must look like, and exactly how to handle each kind of request. A trimmed version of the start of mine:

# LLM Wiki: Schema & Operating Rules

## Role
You are the wiki agent for this vault. You write and maintain
all pages. The human curates sources and asks questions.
You do the bookkeeping: summarizing, cross-referencing,
filing, and flagging contradictions.

## Rules
- Never modify files in Claude Sessions/ (raw source layer).
- Every page gets the standard frontmatter.
- Every page's Related Notes links back up to its owning MOC.
- Check with me before overwriting or contradicting a page.

## Frontmatter
---
title: Page Title
tags: [domain, type]
created: YYYY-MM-DD
updated: YYYY-MM-DD
status: active | draft | archived
related: [Other Page]
source: ingest | idea | query-result | manual
---

Below that I define page templates (project, concept, decision record) and the operations covered in the next section. Be specific. Vague rules like "keep things organized" get you vague results; "append one entry to log.md in this exact format" gets followed every time.

↓ Download my CLAUDE.md as a template

Step 3: Make the index a tree, not a list

index.md only links to domain index pages (Maps of Content, or MOCs): Software Projects, Coursework, Career, and so on. Each MOC lists its own pages, and each page links back up to its MOC. So you get index → MOC → page, which stays readable at 470 pages. My first version listed every page in the index and it became useless around page 60.

Step 4: Keep an append-only log

log.md gets one entry for every operation, with a greppable header like ## [2026-09-21] idea | Football chain crew robot. It's how the agent picks up where the last session left off, and it means every question I've ever asked is searchable context for the next one. The agent is told to read the latest entries at the start of each session.

Step 5: Capture sessions automatically

I do most of my building inside Claude Code, so I added a Stop hook: whenever a session ends, a small PowerShell script reads the session transcript, has a cheap, fast model summarize it, and saves a dated note into Claude Sessions/. Every coding session becomes raw material for the wiki without me doing anything.

// ~/.claude/settings.json
{
  "hooks": {
    "Stop": [{
      "matcher": "",
      "hooks": [{ "type": "command",
                  "command": "powershell -File ~/.claude/save-session.ps1" }]
    }]
  }
}

Step 6: Put it in git

The vault is a git repo. The agent edits a lot of files at once, and being able to diff "what did that ingest actually change?" or roll back a bad edit makes it safe to let it work freely.

03The five things it knows how to do

Each operation is a short recipe in the rules file. I trigger them in plain English.

1. Ingest. I drop an article, lecture notes, or a transcript in the inbox and say "ingest this." The agent writes a summary page, adds it to the right MOC, then updates the existing pages it relates to. One source usually touches 3 to 8 pages. That last step is the one that makes it compound.
2. Idea. I brain-dump a half-formed idea. The agent restates it as a rough plan, researches how you'd actually build it (with a source link on every claim), shows me the findings, and files it as a draft page.
3. Query. I ask a question. The agent checks the log for earlier answers on the same topic first, navigates index → MOC → pages, answers with links to its sources, and logs the Q&A. Good answers get promoted to their own page.
4. Lint. A health check: broken links, orphaned pages, contradictions between old and new pages, topics mentioned constantly with no page of their own. It reports and asks before fixing.
5. Receipt. I send a photo of a receipt and it becomes an itemized page with totals, linked from an expenses index.

04How I actually use it

Going by the log, here's where it earns its keep:

05What I learned

• The rules file is the product. Almost every improvement came from tightening CLAUDE.md, not from new tools.
• Log every question. I originally only logged ingests. Logging queries too means the brain remembers what I asked last week and builds on the answer instead of re-deriving it.
• Keep raw sources read-only. Transcripts and originals never get edited, so a bad summary can always be redone from the source.
• Make it ask before contradicting. When new info conflicts with an old page, it flags the conflict instead of silently overwriting. That's how it caught two "different" projects that were really one project under an old name.
• Lint regularly. Even with rules, a wiki drifts. A weekly health check keeps orphans and stale pages from piling up.

If you want to try it: make a vault, write a one-page CLAUDE.md with a role, a folder map, and an ingest recipe, and feed it one article. Add operations as you find yourself repeating requests. Mine started with three and grew to five.