Andrej Karpathy posted a gist describing a personal wiki maintained by an AI agent. 41,000 bookmarks later, the question keeps turning up in my inbox: is this just notebooks with extra steps, or does it change how I should structure my context layer?
It changes things, but only if you’re honest about what it’s for.
Karpathy’s setup is folders of markdown read in Obsidian, written by an agent. When a new source arrives, the agent reads it, updates the relevant pages, and links it to existing notes. The wiki is the artefact. The raw sources sit untouched in a side folder so he can always go back to ground truth.
Compare that to OpenBrain, Nate B Jones’ structured database for the same problem. Information lands in tagged rows. Nothing is synthesised on the way in. When you or an agent ask a question, the AI reads the relevant rows and produces an answer fresh.
They sit on opposite sides of one decision.
When does the AI do the hard work
The fork is timing. The wiki synthesises on write. The database synthesises on query.
A wiki on write means the heavy lift happens once, when the source is added. Every subsequent question reads pre-built understanding. The cost is paid up front and amortised across every read.
A database on query means ingest is cheap. Add a row, tag it, done. The cost lands when you ask. Each question burns tokens to reread the relevant rows and rebuild the picture.
The trade-offs flow from this one choice, and most people picking a tool aren’t picking the trade-off.
Where the wiki wins
The wiki wins when one person reads ten papers on a topic and wants the connections between them. Paper five contradicts paper two. Paper seven confirms a thread from paper three. The wiki, maintained on every ingest, surfaces those contradictions and links at the moment they happen.
This is Karpathy’s actual workflow. He’s a researcher reading deeply on one subject. The agent acts as a writer, the human as a reader and curator. By paper ten, the wiki is a navigable artefact of the current state of his thinking.
It fits a solo researcher building narrative knowledge from sources read over time.
Where the database wins
OpenBrain wins when the questions are operational, not narrative. Show me every meeting where pricing came up. Pull the three most recent competitor notes. Filter by date, sort by tag. A folder of markdown can’t answer those without keyword search that misses things.
It also wins on multi-agent access. Three agents writing markdown to the same page is a merge conflict. Three agents reading and writing to a tagged table is normal database behaviour. If you’re building agent infrastructure rather than a personal scratchpad, that’s the constraint that matters.
Volume too. Karpathy’s setup works well at 100 to 10,000 high-signal documents. Past that, you need search tooling on top, and you’re rebuilding a database badly.
The drift problem
There’s a quieter issue with the wiki I haven’t seen discussed enough. When the agent writes a synthesis, it makes editorial choices. Which sources to lean on. How to frame a contradiction. What to leave out.
Most of those choices are fine. Some are wrong. The wiki reads with the confidence of well-written prose either way, and the next ingest builds on whatever was written last. Errors compound silently.
The database has the opposite failure mode. Old facts stay true. A neglected database has gaps. A neglected wiki drifts, and you can’t tell from reading it.
For a personal research project, this is fine. For team or org context, it’s a real problem. A wiki that smooths engineering’s 12-week estimate and sales’ 8-week promise into a tidy 10-week answer has just hidden the disagreement that should have been visible.
The hybrid I’d build
If I were picking now, I’d keep the database as the source of truth and generate the wiki on demand from it.
The structured store handles ingest, multi-agent access, and precise queries. A scheduled job reads the database, builds a graph of related entries, and writes synthesised wiki pages to a folder. Obsidian opens the folder. The wiki is a generated view, never edited directly. If a page is wrong, you fix the source row and regenerate.
This keeps the database authoritative. It also gives you the browsable, narrative layer that makes the wiki feel useful in the first place. The wiki can’t drift from reality because it’s rebuilt from reality.
It’s the same pattern as a static site generator over a CMS, where the database is authoritative and the site is a generated view.
Pick by the shape of the work
If you’re one person, deep on one topic, and the value is in connections between sources, use the wiki. Karpathy’s gist is enough to get started.
If you’re running multiple agents, capturing high-volume mixed information, or expecting any of this to outlive a single project, use the database.
If you want both, generate the wiki from the database rather than maintaining two stores.