What is an LLM wiki? Karpathy's pattern, and how to build one

What is an LLM wiki?

An LLM wiki is a set of Markdown pages that a language model agent keeps up to date from your sources. In Karpathy's words, the LLM "incrementally builds and maintains a persistent wiki", "a structured, interlinked collection of markdown files that sits between you and the raw sources" (gist).

When you add a source, the agent reads it, writes a summary page, and updates the existing pages it touches: people, projects, concepts, comparisons. It also notes where the new source contradicts an older one. You mostly read the wiki. The agent writes it.

Karpathy is clear about the split: "You're in charge of sourcing, exploration, and asking the right questions." His own setup is an agent on one side of the screen and Obsidian on the other, which he sums up as "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."

• Personal: goals, health, journal entries, articles and podcast notes.
• Research: papers and reports on one topic over weeks or months.
• A book: pages for characters, themes and plot threads as you read.
• A team: an internal wiki fed by meeting transcripts, project documents and customer calls, with people reviewing the updates.

Those are the gist's own examples. What they share is knowledge that piles up over time and is more useful organized than scattered.

LLM wiki vs RAG: compile once instead of searching every time

Retrieval-augmented generation (RAG) is how most "chat with your documents" tools work: the model looks up relevant chunks of your files when you ask a question, then answers. Karpathy's objection is that "the LLM is rediscovering knowledge from scratch on every question. There's no accumulation."

An LLM wiki does the work up front. The cross-references, summaries and flagged contradictions already exist when you ask, because the agent wrote them at ingest time. In the gist's words, the knowledge "is compiled once and then kept current, not re-derived on every query."

That also changes the infrastructure. Karpathy says an index page the agent reads first "works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure." Past that size, he suggests adding a proper search tool.

The three layers of an LLM wiki: sources, pages and schema

The gist splits an LLM wiki into three layers, plus two special files:

The schema is what Karpathy calls "the key configuration file". It works because coding agents load it automatically: Claude Code reads CLAUDE.md at the start of every session, and reads AGENTS.md instead when a repository has no CLAUDE.md (Claude Code docs). If you use several agents, AGENTS.md vs CLAUDE.md covers how to keep one file for all of them.

How to build an LLM wiki, step by step

This is one way to start that follows the gist. The folder names are my suggestion; Karpathy leaves the exact structure to you and your agent.

1. Make a folder and put it under git. Inside, create raw/ for sources and wiki/ for the pages, plus an empty index.md and log.md.
2. Write a short schema in AGENTS.md or CLAUDE.md: what the wiki is about, the page types you want, how to name pages, and the three workflows below. Keep it short at first.
3. Open your agent in that folder, paste in Karpathy's gist, and ask it to set up the structure with you. The gist is written for exactly this.
4. Add one source to raw/ and ask the agent to ingest it. Read the summary it writes and the pages it changes, and tell it what to emphasize.
5. Ask questions against the wiki. When an answer is worth keeping, ask the agent to file it as a new page.
6. Every so often, ask for a lint pass, and commit the changes so you can see what moved.

Karpathy says a single source "might touch 10-15 wiki pages", and that he prefers to ingest sources one at a time and stay involved. Batch ingests are possible with less supervision, but early on, reading each change is how you learn what to put in the schema.

How to maintain an LLM wiki: ingest, query and lint

The gist describes three operations. Writing each one into the schema is what makes the agent consistent from one session to the next:

• Ingest: read the new source, discuss the key points, write a summary page, update the index and the related pages, and append an entry to the log.
• Query: read the index first, open the relevant pages, answer with citations, and offer to save a good answer as a page. Karpathy's point is that answers "shouldn't disappear into chat history."
• Lint: look for contradictions between pages, stale claims, orphan pages with no inbound links, concepts that need their own page and missing cross-references.

The log helps both of you. Karpathy suggests starting each entry with a consistent prefix, such as ## [2026-04-02] ingest | Article Title, so grep can list the latest entries. A new session can then read the last few entries and know what changed recently, without rereading everything.

This is also why the wiki lives in files rather than in a chat: the next session starts with an empty context window, and the pages are what it can read. More on that in context rot: why long agent sessions get worse.

LLM wiki tradeoffs: what can go wrong

The pattern is simple, and the risks are the ones you'd expect when a model writes your notes:

• Mistakes compound. A wrong summary becomes a page, and later pages cite it. Keeping raw sources unchanged, asking for citations, and reading ingests yourself are the safeguards, and all three are part of the workflow in the gist.
• Scale needs search. The index file is enough for a moderate wiki. For more, Karpathy mentions qmd, a local search engine for Markdown files with a command line tool and an MCP server.
• Images are clumsy. The gist notes that LLMs can't read Markdown with inline images in one pass, so the agent reads the text first and the images separately.
• Your sources go where your model runs. If your agent uses a cloud model, the pages and sources it reads are sent to that provider. Decide what belongs in the wiki with that in mind.
• It is not hands-off. The agent does the bookkeeping, but you still choose the sources and check the synthesis.

LLM wiki tools: what you need and what is optional

You need an agent that can read and write files, and somewhere to read the pages. The gist mentions these tools, and says all of them are optional:

If Obsidian's graph view and plugins are part of why you want an LLM wiki, Karpathy's setup of a git folder plus Obsidian is the most direct route. There is nothing to install beyond the agent and the editor.

Running an LLM wiki with Koru

Koru Workspace is our free, open-source (MPL-2.0), local-first workspace for Windows and macOS, with mobile and Linux coming soon. Two parts of it matter here: a local MCP server and API that run on your device alongside the app (Koru for developers), and terminal tabs, where you can run a coding agent such as Claude Code next to your documents.

Koru works with the AI you choose and never makes you use a Koru cloud AI. The agent and the model are yours to pick. That leaves two ways to use it with an LLM wiki:

• Keep the wiki as Markdown in git, as the gist does. Run Claude Code in a Koru terminal tab inside the wiki's folder, and keep your own writing and drafts in Koru next to it. Koru isn't storing the wiki in this setup; it's where you work beside it.
• Keep the wiki in your Koru workspace. Connect an MCP client such as Claude to Koru's built-in MCP server, and let it read and edit pages in your workspace. The pages live in a local database on your device, work offline, and sync between your devices peer to peer, end-to-end encrypted, for free.

The second setup changes the pattern, and I'd rather say so. Koru keeps notes in its own local database, not in a folder the agent can browse, so grep, git history and Obsidian plugins don't apply to those pages. You can export Markdown whenever you want out. If a folder of Markdown is the point for you, use the first setup, or Obsidian.

The schema file and the wiki are, in the end, context you want every assistant to have. That's the problem we're designing Koru Weave around. It's in development: the idea is to keep useful context in one place and share selected parts with compatible AI assistants and the people you choose. Join the early access list for development updates and to hear when testing opens.

Frequently asked questions