What Is an LLM Wiki? The Knowledge Base AI Agents Maintain

Think of the notes you keep after reading a dozen papers on one subject. They are useful and they are a mess: duplicate pages, stale summaries, a claim you meant to check and never did. An LLM wiki gives an agent the job of organizing that pile. The agent writes summaries, adds cross-references, and records when two sources disagree ([evidence ev-201]).

What makes it a wiki rather than a chat transcript is that knowledge persists as pages you can open, link, and read in any order. What makes it an LLM wiki is that a model does the compiling and updating instead of a person doing it by hand.

An LLM wiki is a structured, interlinked set of markdown notes that an LLM incrementally compiles from raw sources, so a reader can consult a maintained summary instead of re-reading every document. Andrej Karpathy proposed the idea in April 2026 in a gist titled LLM Wiki and described the workflow in a post called "LLM Knowledge Bases" ([evidence ev-201]). The same workflow is covered in Karpathy's LLM wiki.

A folder of files becomes a wiki when the files link to each other and something keeps those links honest. It becomes an LLM wiki when that something is a model acting on defined instructions.

The system separates three things, and keeping them apart prevents the disorder people fear when a model writes freely ([evidence ev-201]):

Raw sources are never edited. The agent reads them and writes into the wiki layer. The schema file tells the agent how the wiki should be shaped: naming, folders, what a good page contains, and which operations it may run.

The agent has three jobs, mapping onto how a careful human maintainer works ([evidence ev-201]).

Ingest. Add a source, write a summary, update every concept and entity page the source touches, then update the index and the log. The update step is the one humans skip. When a new source contradicts an older claim, ingest records that instead of losing it.

Query. Find the relevant pages, answer with citations, and file a good answer back into the wiki as a new page. That turns a question into a durable asset rather than a throwaway reply.

Lint. Periodically check the wiki's health: broken links, orphan pages, stale summaries, duplicated concepts, and gaps where a page is expected but missing (Wiki Lint).

Everything else — the model, the folder layout, the editor — is a detail that can change.

A wiki of many pages needs a way in, and an LLM wiki uses two navigation files ([evidence ev-201]):

• Index File — a content catalog, one line per page, rewritten on every ingest so it reflects the current state.
• Changelog — an append-only chronological record with a consistent prefix, so a text tool can search it.

The index answers "what do I have?" The log answers "what changed, and when?" At small scale the index doubles as retrieval: the agent reads an accurate index, opens a few pages, and answers without any similarity search ([evidence ev-201]).

An LLM wiki is a form of retrieval-augmented generation; the difference is the retrieval method ([evidence ev-209]). Vector-based Retrieval-Augmented Generation fetches chunks by embedding similarity. An LLM wiki retrieves by following links and an index the model can read.

At personal scale — roughly a hundred sources — the index approach holds up and no vector database is needed to start ([evidence ev-201]). Links are visible: you can open the index, see the page it points to, and understand why the agent chose it. Embeddings add a pipeline to maintain and a layer of results you cannot easily inspect. Production systems often combine both methods ([evidence ev-209]), and you can add embeddings later once the corpus outgrows the index; see add embeddings to a knowledge base. The head-to-head tradeoff is in LLM wiki vs RAG.

The idea is older than the models. In 1945, Vannevar Bush described the Memex: a private store of documents with associative trails between them ([evidence ev-208]). Bush saw that the hard part was not storage or even linking. It was maintenance. Someone had to keep the trails current, and nobody wanted that job.

An LLM wiki answers that directly. The tedious work that made personal knowledge bases decay — cross-references, refreshed summaries, noting disagreements — is what an agent does without getting bored ([evidence ev-201]). The Compounding Knowledge argument is that a maintained collection grows more useful over time, while an unmaintained one rots.

Because the wiki is Markdown in a plain folder, any tool that reads and writes files can work with it. Obsidian stores notes as local markdown and renders wikilinks, backlinks, and a graph view, so the agent and the person edit the same folder ([evidence ev-210]).

For capture, Obsidian Web Clipper turns a web article into markdown before it enters the raw sources folder ([evidence ev-201]), so the agent receives clean text rather than a page full of ads. The Knowledge Graph is a view over explicit links, not a separate store. The overlap with Personal Knowledge Management is real; the difference is who maintains it. That persistence is also what lets the wiki act as Agent Memory, a store the model reopens on the next task.

A retrieval pipeline re-derives knowledge on every query: fetch, rank, summarize, answer. A wiki compiles once and compounds, because each ingest improves the pages every later answer depends on ([evidence ev-201]).

It suits anyone whose reading concentrates on a topic: researchers tracking a field, writers building a beat, operators who need a durable internal reference, analysts who revisit the same questions. The common trait is repetition. If you look something up once and never again, a wiki is overhead. If you look up variations of the same thing every week, it pays for itself.

• Scale. The index method is described at personal scale, around a hundred sources. Past that, a combined approach becomes reasonable ([evidence ev-201]; [evidence ev-209]).
• Source quality. The wiki is only as good as what you feed it. Immutable raw sources are a discipline, not a guarantee.
• Human review. The agent writes; you still own judgment. Deciding which side of a contradiction is right is your call.
• Tooling drift. The schema file governs behavior. If the configuration changes, the wiki's shape can change with it.

Is an LLM wiki the same as a knowledge base?

A knowledge base is the broader category; an LLM wiki is a specific kind. Its pages are markdown, they link to one another, and an agent maintains them from immutable raw sources ([evidence ev-201]).

Does an LLM wiki need a vector database?

No. At personal scale, roughly a hundred sources, an index the agent reads is sufficient and avoids embedding infrastructure ([evidence ev-201]). Vector search becomes worth adding when the corpus outgrows the index ([evidence ev-209]).

What is the difference between an LLM wiki and RAG?

Both are retrieval-augmented generation. RAG retrieves chunks by embedding similarity and re-derives an answer each time. An LLM wiki follows links and an index, and compiles knowledge into pages that persist ([evidence ev-209]).

Who maintains the wiki, the person or the agent?

The agent does the mechanical maintenance; the person sets direction and judges content. Raw sources are immutable and owned by the person, the wiki is agent-owned markdown, and the schema file configures the agent ([evidence ev-201]).

Why not just use a chatbot over my documents?

A chatbot answers and forgets. An LLM wiki files the answer back as a page, updates the index, and records the change in the log ([evidence ev-201]), so the next question benefits from the previous one.

Is the idea actually new?

The maintenance problem is not. Vannevar Bush described the Memex in 1945 as a private store with associative trails and noted that keeping them current was unsolved ([evidence ev-208]). What is new is a model willing to do that upkeep.

The XKnow Knowledge Base at XKnow Knowledge Base is a pre-compiled LLM wiki you own: an organized set of SEO and SaaS notes with an index, cross-links, and a changelog, ready for an agent to read and extend. Instead of assembling the schema and the first few hundred pages yourself, you start from a structure that already holds together.

• Karpathy's LLM wiki — the origin of the gist and the workflow behind it.
• LLM wiki vs RAG — how the two retrieval models compare.
• add embeddings to a knowledge base — when to add vector search to a linked wiki.