I read a lot — vendor docs, architecture reviews, long articles, the occasional PDF I download with real intentions and never open again. For years my system for keeping any of it was the one everybody has: highlight the good parts, clip them to a notes app, and forget they exist. The “second brain” I was promised turned out to be a second junk drawer.
A few months ago I tried a different approach, and it has changed how I keep information enough that I wanted to write down the whole recipe. The core idea isn’t mine — it comes from a short note by Andrej Karpathy — but the version I built has earned its place in my daily routine, so here’s how it works and how to build one yourself.
The idea, in one line: stop being the librarian.
This is the first of two posts. Here I’ll lay out the pattern and how to stand up the basic version — which is essentially Karpathy’s original idea, made concrete. Part 2 is about everything I’ve added on top of it since, and why.
Why it works
Keeping a good personal knowledge base is really two jobs, and most of us are only good at one of them.
The first job is deciding what matters — what to bring in, what to ask, what’s worth remembering. That part is interesting, and it’s yours; nobody can do it for you.
The second job is everything after that: reading the source closely, writing an honest summary, linking it to the dozen other things it connects to, catching the moment it contradicts something you filed six months ago, and holding the whole collection consistent as it grows into hundreds of pages. That job is tedious, it never finishes, and it’s the one every note system dies on. You start strong, the maintenance debt piles up, and eventually you just stop.
Language models are the reverse. They’re unreliable at deciding what matters to you, but they are patient and consistent at reading, summarizing, and cross-referencing — the exact work people give up on. So split the labor along that seam: you curate and ask questions; the model reads and files. That’s the whole trick.
The shape of it
The wiki has three layers, and keeping them separate is most of what makes it work.
Raw sources are immutable. When I clip an article, save a PDF, or drop in a transcript, it goes into a raw/ folder and never changes. The model reads from it and can add new captures, but it never rewrites history — so anything a wiki page cites is still there, exactly as it was, months later.
The wiki is the model’s to own. One page per source, per person, per concept, per analysis, all densely cross-linked. This is the layer I actually read and search, and I almost never edit it by hand — the model writes and maintains it.
The schema is the contract between us — a plain-text file of conventions: what metadata every page carries, how folders are organized, how sources get cited, what the daily workflow is. It’s the part I didn’t expect to matter and now think is the most important piece. That’s most of what Part 2 is about.
Underneath all of it is plain Markdown in Obsidian. Local files, no proprietary format, mine forever, searchable with plain tools whether or not any of this machinery is running. That was non-negotiable for me.
How it’s wired
The setup is less complicated than it sounds. Four pieces:
- Obsidian holds the vault — the Markdown files.
- Obsidian’s Local REST API community plugin exposes that vault over HTTP on localhost.
- A thin command-line wrapper — a few hundred lines of Python — gives the model clean verbs against that API: read, write, search, link, log, lint.
- An LLM coding agent — I use Claude Code — reads the schema file on startup and drives the wrapper.
The important detail is that the model never touches the files directly. It goes through the REST API, which lets the wrapper enforce rules the model can’t casually break — like the immutability of raw/. The agent proposes; the plumbing disposes.
Standing one up on a Mac takes about fifteen minutes: install Obsidian, enable the REST plugin, copy its API key into a config file, install the wrapper, and point your agent at a folder with the conventions written down. The tooling is small enough that you can write your own in an afternoon — which is part of the appeal; there’s nothing magic in it.
Living with it
Day to day it’s three motions.
Ingest. I drop a source into raw/ and say “ingest this.” The model reads it end to end, tells me what’s surprising or contested, and asks what to emphasize. Then it writes a summary page, updates every existing page the source touches, and logs what it did. A single meaty article might touch a dozen pages.
Ask. I ask a question in plain language. The model searches, opens the actual pages — not just the index — and answers with links back to its sources so I can check its work. If the answer is worth keeping, it files it as its own page.
Lint. Every so often it runs a health check — orphaned pages, missing metadata, dead links, pages that have gone stale relative to newer sources — and I decide what to fix.
The part that separates it from AI slop
Here’s what I’d tell anyone trying this: the model is the easy part. The discipline is the hard part, and it’s the difference between a knowledge base you trust and a pile of confident-sounding garbage.
A few conventions carry most of the weight:
- Every page cites its sources, and links are first-class. A claim you can’t trace back is a claim you shouldn’t trust.
- Contradictions get surfaced, not smoothed over. When a new source disagrees with an existing page, the model flags the disagreement instead of quietly overwriting — because the disagreement is often the most valuable thing in the file.
- Discover before creating. Before writing a new page, the model searches for an existing one, so the wiki grows connections instead of duplicates.
- The schema co-evolves. When we hit a case the conventions don’t cover, we change the conventions — in the schema file — and everything downstream follows. Treating the schema as a living document is what keeps a growing wiki coherent instead of letting it drift into a thousand inconsistent pages.
None of that is exotic. It’s the ordinary editorial discipline that every good reference has and that nobody wants to do by hand. Which is the point: now something does.
What surprised me
Three things.
The immutable raw/ layer mattered more than I expected. Being able to trust that every citation still points at the original, unaltered source is what makes me trust the wiki at all.
The model is genuinely good at the connective tissue — noticing that something I read today relates to something I filed in the spring, and linking them without being asked. That’s the work I always meant to do and never did.
And the schema became the real artifact. The Markdown files are the output, but the accumulated conventions — the hard-won rules about how to handle contradictions, how to cite, how to organize — are the thing I’d actually be sad to lose.
Try it
The pattern is Karpathy’s original note. The ingredients are Obsidian, an LLM agent that can run shell commands, and a willingness to let the machine keep the notes. The tooling is simple enough to build yourself, and honestly that’s half the fun.
I mostly stopped taking notes a few months ago. I’ve never had better ones.
That’s the basic system — really just Karpathy’s idea, built out. In Part 2 → I get into the parts that aren’t his: treating the schema as code, catching contradictions and stale pages automatically, keeping separate analyses consistent, and the rest of the machinery that makes a wiki hold up past a few thousand pages.