LLM Wiki: How AI Agents Build Compounding Knowledge

An LLM wiki is a knowledge base an AI agent writes and maintains for you: an interlinked set of markdown pages, with an index and a changelog, that compounds as you work instead of being re-derived on every question. If you've used Claude Code or Cursor seriously for more than a few months, you've probably already tried to build one.

I did too. Then I built it into CandleKeep properly — and the surprising part was how little code it took. This is the story of why, and what an LLM wiki actually is.

What is an LLM wiki?

An LLM wiki is a structured, self-maintaining knowledge base that a language model reads and writes during your sessions. Instead of a chat history you lose or a pile of docs you re-summarize every time, it's a living set of pages: concept entries, an index, a changelog, links between related ideas.

The key word is compounding. Most LLM-and-documents setups rediscover knowledge from scratch on every query. An LLM wiki is the opposite — knowledge is compiled once into pages, then kept current. The cross-references are already there. The contradictions have already been flagged. Every source you add and every question you ask makes it richer.

You don't write it. The model does. Your job is to curate sources and ask good questions; the model does the summarizing, cross-referencing, and bookkeeping that makes a knowledge base actually useful over time.

The DIY LLM wiki — and what it quietly costs you

The pattern has a recognizable shape. You make a raw/ directory for sources. You write a CLAUDE.md (or AGENTS.md) that defines the wiki's structure and conventions. You add a search script — or a small vector database — so the agent can find things. Maybe you sync it to Obsidian to view the graph.

It works. I've seen people get real value from exactly this stack. But it has a tax that nobody mentions up front.

You become the janitor of your own memory system. The schema drifts. The search script breaks on an edge case. Cross-references go stale because updating them by hand is tedious, and the one job humans reliably abandon is maintenance. The value grows linearly; the upkeep grows faster.

That's the real problem — and it isn't the external symptom (a stale wiki). It's the internal one: your agent should arrive knowing your context. Maintaining the infrastructure for that shouldn't be your second job.

How CandleKeep does it: the least complicated manuscript

CandleKeep is a library your AI agents can actually read. You add books — PDFs, your own docs, marketplace titles — and your agent reads them by page, with citations, during a session. A manuscript is a special kind of book: one your agent writes and maintains from your real work.

The LLM wiki is the simplest manuscript there is. It's seeded for you the moment you install — a book called "My LLM Wiki" is already in your library. There's no raw/ directory to feed, no schema to write, no search engine to wire, no Obsidian to configure. Your agent starts maintaining it on the next session, and reads it back on the one after.

Zero config. That's the entire pitch. The hard part of the DIY stack — the setup and the upkeep — is the part CandleKeep removes.

LLM Wiki vs RAG: why full-document reading beats chunked retrieval

This is the question every developer asks, so here's the direct answer. RAG retrieves chunks at query time and rebuilds context from scratch on every question. An LLM wiki compiles knowledge once into pages the agent reads directly — and keeps them current.

RAG is similarity search over fragments. A wiki is reading. The agent browses a table of contents, opens the pages it needs, follows links to related pages, and cites by page number — the way you'd use a real reference book, not a search index.

The practical difference shows up on the hard questions. Ask something that requires synthesizing five sources, and a RAG system goes hunting for fragments every time. A wiki already did that synthesis once and wrote it down. There are no embeddings to manage, no chunk-size tuning, no vector store to operate. There's just a book that keeps getting better.

How it works under the hood — the one-boolean version

Here's the build-in-public part, because it's the most useful thing I learned.

I expected the LLM wiki to be a big feature. A new content type, a maintenance engine, a way to render an index and a changelog and backlinks. I started sketching all of it.

Then I realized the wiki is just a book. Everything the "LLM wiki" pattern asks for, CandleKeep already had as ordinary book mechanics:

Table of contents — auto-extracted from the book's # headings. Already there.
Changelog — a ## Changelog section in the book, plus a full version snapshot on every write. Already there.
Backlinks — books are multi-page, so a page can point to another page the agent opens with the CLI. Already there.
Reversibility — every edit is versioned. Already there.

So the actual feature was tiny: one boolean on a manuscript (autoUpdate) that tells the agent to maintain the book at the end of a session without asking, plus a seed that creates the wiki for every user. The hardest design decision wasn't code at all — it was deciding that the instructions for how to maintain the wiki should live on the manuscript itself, as data the agent reads, rather than baked into a prompt. That keeps it configurable per book and out of the way.

That's the whole thing. The reason it was easy to build is the reason it's easy to use: an LLM wiki was never a new system. It was a book that writes itself.

Get your LLM wiki

If you've been hacking one of these together, you don't need the scaffolding anymore. Install CandleKeep and your LLM wiki is already there — seeded, zero-config, maintained by your agent from the next session on.

Your agent walks into every session already knowing what you know. Your knowledge compounds. You stop re-explaining, you stop maintaining — you just work.