Karpathy's LLM wiki: a knowledge base your coding agent maintains

In April 2026 Andrej Karpathy published a short note on what he calls an LLM wiki: a folder of markdown files that a coding agent writes and keeps current, sitting between you and the raw sources you collect. The one line that captures it is his own: “Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.” You curate sources and ask questions; the agent does the writing.

I have run several knowledge bases the old way for years, and the old way has a failure mode that Karpathy names precisely: “Humans abandon wikis because the maintenance burden grows faster than the value.” Every note you add is another page to cross-reference, another index to update, another stale link to notice later. The wiki decays because the person maintaining it is the bottleneck. The LLM wiki inverts that bottleneck. This guide covers what the pattern is, why it earns a place in a project rather than being one more folder that rots, and how to set it up so the agent does the upkeep.

What an LLM wiki is, and how it differs from RAG

The default way most people connect an LLM to their documents is retrieval. You drop files into a vector store, and at query time the model pulls the chunks that look relevant and answers from them. It works, but the model rediscovers your material from scratch on every question. Nothing accumulates. Ask something that needs five documents synthesized and the model has to find and reassemble those fragments again, the same way, every time you ask.

The LLM wiki moves that work to the front. Instead of retrieving from raw documents at query time, the agent compiles the sources once into structured, interlinked markdown and then keeps that structure current as new material arrives. Karpathy’s framing is that the knowledge is compiled once and then kept current, so the cross-references already exist when you go looking. The practical consequence: the synthesis a query would have to redo lives in the wiki as a page, and the next question builds on it instead of regenerating it.

So a wiki has two directories at its core, and the community skill that packages the pattern makes the split explicit:

your-project/
  raw/       # immutable sources: articles, papers, notes, transcripts
    topic/
      2026-07-10-source-article.md
  wiki/      # agent-maintained, compiled knowledge
    topic/
      concept-name.md
    index.md   # global table of contents
    log.md     # append-only record of what the agent did

raw/ is what you put in and never edit. wiki/ is what the agent produces and owns. You read wiki/, you rarely write it. Karpathy is blunt on that division: “You never (or rarely) write the wiki yourself. The LLM writes and maintains all of it.”

Why it earns a place in a project

I was skeptical that this was different from every note-taking system that came before it, so the question worth answering is what actually changed. Two things did.

(1) The maintenance cost moved off the human. A wiki is valuable in proportion to how well its links and indexes are kept, and that upkeep is exactly the work people stop doing. When the agent owns the upkeep, the value can compound instead of decaying, because adding the hundredth source is no more work for you than adding the first. You still choose sources and ask questions; the cross-referencing, the index edits, the reconciliation of a new claim against an old page, all of that is the agent’s job now. Therefore the effort you used to spend keeping the wiki alive moves to choosing what goes in it.

(2) The wiki becomes a first-class context source for the same agent that maintains it. This is where it stops being a personal-productivity trick and starts mattering for how you work in a repository. A compiled, linked knowledge base is a far better thing to point a model at than a pile of PDFs, because the model reads structure faster than it reassembles fragments. The pattern is the same discipline behind pointing an agent at a good instruction file rather than making it infer everything, which I wrote about in my notes on AGENTS.md and CLAUDE.md: give the model curated, linked context and it spends its budget reasoning instead of searching.

I would not put a wiki on every project. A throwaway script does not need one. The pattern earns its place where a project accumulates sources over time and where answers depend on synthesizing several of them: research you return to, a domain you are learning, a codebase whose decisions are scattered across issues and docs, a running investigation. Those are the cases where retrieval alone keeps paying the same cost and a compiled wiki stops paying it.

The pieces you need

Karpathy’s own setup names four roles, and it is worth separating them because you can start with two and add the rest later.

• The agent. A coding agent that can read and write files in the folder. Claude Code is the one Karpathy uses. This is the only piece that is non-negotiable, because the agent is what does the compiling.
• A viewer. Obsidian renders the markdown, follows [[wikilinks]], and shows the graph of connections the agent builds. Every link the agent writes becomes a visible edge. The viewer is optional at first; the files are plain markdown and readable in any editor.
• A capture tool. Something to turn a web article into clean markdown so it lands in raw/ without hand-copying. Karpathy uses the Obsidian Web Clipper.
• A search layer. As the wiki grows past what fits in a single context window, the agent needs a way to find the right pages instead of reading all of them. This is where a local search engine comes in, covered below.
• Version control. The wiki is a git repository of markdown, so every compile is a commit you can inspect or revert.

Setting it up

The minimum viable version is a folder and an instruction file, and I would start there before adding tooling.

1. Scaffold the two directories. Create raw/ and wiki/, and seed wiki/ with an index.md and a log.md. The index is the agent’s table of contents; the log is where it records each ingest so you can see what it touched.

2. Write the schema as an instruction file. The wiki needs house rules, and those belong in the agent’s instruction file (CLAUDE.md for Claude Code) so they are read as trusted instructions on every run. State the directory layout, the page conventions (one concept per page, link entities with [[wikilinks]], never edit raw/), and the rule that every wiki claim cites the raw/ source it came from. This is the same one-file-of-house-rules idea from the AGENTS.md guide, pointed at a knowledge base instead of a codebase.

3. Define three operations. The packaged skill settles on a clean set of three, and they are a good contract to hold your own setup to:

• Ingest: read a new source, drop it in raw/, and compile or update the wiki pages it affects.
• Query: answer a question from the wiki with citations back to the pages, not the open internet.
• Lint: a health check that finds broken links, missing index entries, and stale cross-references, fixing what it safely can.

That is the whole system. A folder, a schema, and three verbs.

Ingesting a source

Ingest is the operation you run most, so it is worth understanding what a good one does. You hand the agent a source, by URL, file, or pasted text, and tell it to ingest. It stores the immutable copy in raw/, then works outward: it writes or updates a summary page, updates the index, and touches the entity and concept pages the source affects. Karpathy’s number for a single ingest is that a single source might touch 10-15 wiki pages, which is the tell that the agent is doing the cross-referencing you would otherwise skip. One article does not produce one note. It produces one summary and a dozen small edits to the pages that article now connects to.

The instruction I have found matters most is to make the agent reconcile rather than append. When a new source contradicts an existing page, the wrong outcome is two pages that disagree; the right outcome is one page that records the disagreement and cites both sources. Put that in the schema explicitly, because the default behavior of a model asked to “add this” is to add, not to reconcile.

Querying and keeping it healthy

Querying is the part that feels like the payoff. Because the synthesis already lives in the pages, a question that would have needed five documents retrieved and stitched now reads a few linked pages that were written for exactly that connection. Ask the agent to answer only from the wiki and to cite the pages it used, so you can check its work and follow the trail back to raw/.

Linting is the part that keeps the whole thing from becoming the abandoned wiki it was meant to replace. Run it periodically and let the agent report broken links, orphan pages, contradictions, and gaps where the index promises a page that does not exist. This is upkeep that a human stops doing and an agent does not mind, which is the entire reason the pattern works.

Search as the wiki grows: qmd

A small wiki fits in a context window and the agent can read all of it. A large one does not, and reading everything on every query gets slow and expensive. The search layer Karpathy points to is qmd, written by Tobi Lütke, described as “an on-device search engine for everything you need to remember.” It combines three methods: BM25 full-text search for exact keyword matches, vector search for semantic similarity, and an LLM re-ranking pass to float the strongest results to the top, all running locally.

What makes it fit this pattern specifically is that qmd ships both a CLI and a Model Context Protocol (MCP) server, so the same agent maintaining the wiki can call it as a native tool mid-session to find the right pages instead of loading the folder. That is the kind of local, single-purpose server I keep reaching for, which I have written about in the MCP servers I use daily: the value is a tool the agent invokes on its own, not a feature you operate by hand. Add it when the wiki outgrows a single read, not before; a search layer over a twenty-page wiki is machinery you do not need yet.

Where it holds and where it stops

The pattern travels well because it asks for very little: a folder, an agent with file access, and the discipline to let the agent own the writing. It does not need a bespoke application, which is why the same shape works for research notes, meeting transcripts, and a codebase’s scattered decisions alike.

The honest limit is the same one that applies to any agent loop that produces an artifact you then trust: the wiki is only as good as the sourcing rule you enforce and the linting you actually run. An agent that appends without reconciling, or that writes claims without citing raw/, produces a confident-looking wiki that is wrong in places you will not notice until you depend on one of them. The maintenance moved off you, but the judgment did not. This is the same tension I keep running into with autonomous loops, the one I wrote about when I put Karpathy’s autoresearch loop to work on parameter optimization: the loop does the labor, and your job shifts to writing the rules it runs inside and checking the output it produces. On a knowledge base, those rules are “cite the source” and “reconcile, do not append,” and the check is the lint you schedule. Get those two right and the wiki compounds. Skip them and you have rebuilt the abandoned wiki, faster.