When I was researching about harness engineering I asked Claude Code to compare 7 large repos: Claude Code’s leaked source, OpenCode, Pi and a bunch more. Directly pointing Claude Code to these repos was a mess, generating superficial answers.
The standard fix is to ask the agent to compile notes for each repo and then compare them, which works, but it’s cumbersome to manage. Especially if you want to repeat the process. On top of that, what if you want to mix your research with other company docs, articles, papers and YouTube videos?
That’s where an LLM wiki kicks in. It’s the best way I’ve found to merge all my research into one token-efficient memory layer that I can easily pass to my agent to anchor its reasoning in it.
The method is popularized by Andrej Karpathy as a pattern to give agents memory built only from Markdown files. He calls the wiki “a persistent, compounding artifact.” I use mine the opposite way: one wiki per project, deleted when the project ends.
You can use it as memory for coding, research, journaling, education, and brainstorming. The only issue is that it eats a lot of tokens unless you know how it works inside to customize it to your needs.
In my previous piece, I showed how I run it on top of my Second Brain.
In this article, I'll show you how to build an LLM wiki from first principles in 3 phases: vanilla (ingest, index, query local files), ingest custom sources, and continual learning.
P.S. You also have access to the code on GitHub, which contains the /llm-wiki skill in these 3 phases.
First, a quick word from our sponsor ↓
Build for the long run (Sponsored)
Long-running agents need endurance.
They must survive waiting for users and withstand tool failures. They must adapt to every leap in model intelligence.
⚡️ Inngest makes long-running agents durable, observable, and improvable over time.
Check out their generous free tier and a sleek local dev server for testing your workflows.
Now, let’s go!
What are LLM wikis?
In the first example from the GitHub repo, we have 5 notes on MCP and skills ingested into the LLM wiki. If, using our agent, we ask “What do my notes say about when to use an MCP server vs. a CLI?”, the agent finds the 3 most relevant wiki pages (agent-connectivity, cli, mcp) and answers with links to them. Each link leads down to the sources and raw notes behind the claim.
The LLM wiki is a directory of Markdown files that an LLM writes and an agent reads. Zero databases have seen the query. It’s surprising how much complexity you can squeeze out of Markdown files.
Sources go in, derived pages (the nodes) come out. As each page links to other relevant pages, plus the sources it was created from, the wiki indirectly forms a knowledge graph. To sum up:
An LLM wiki is a knowledge graph represented with Markdown files.
Image 1 shows the LLM wiki from exercise 2 of the repo, rendered as an Obsidian graph, with 14 sources and 17 nodes.
Image 2 shows an earlier snapshot of the wiki behind my current book, with 135 sources and 120 nodes.
But Obsidian is only a viewer. Every tutorial recommends it because it renders linked Markdown beautifully. The files are still plain Markdown and work in any editor. The agent doesn’t need Obsidian to operate the wiki. Just point it to the wiki dir, and it’s good to go. Zero setup, zero dependencies.
The architecture comes down to 4 steps, illustrated in Image 3:
Ingestion copies notes, repos, articles, and videos into
raw/.raw/is immutable: the source of truth, never edited.An LLM transforms it into
wiki/, derived pages for what we know.The agent queries only
wiki/.
The point is to turn raw data into something easy to query, instead of throwing all of it at the LLM and hoping for the best. In other words, we want to do RAG.
On disk, one wiki looks like this:
wiki-<slug>/
├── log.md # append-only history
├── raw/ # immutable copies of what was ingested
│ ├── <slug>.md
│ └── assets/
└── wiki/
├── index.md # generated root
├── overview.md # LLM-written summary of the whole wiki
├── sources/ # one page per raw file
├── entities/
└── concepts/Each raw file gets exactly one source page, an executive summary of what matters in it: a summary, key claims, notable quotes, and connections. From it, the LLM extracts entities and concepts. Entities are tools or frameworks, clear things that you can point at, while concepts are more like theoretical ideas.
In exercise 1 of the vanilla wiki example, the 5 ingested notes yield 5 source pages, 4 entities, and 5 concepts. The note “The Future of MCP vs. Skills” alone yields 3 entities (MCP, Claude Code, FastMCP) and 4 concepts (skills, CLI, agent connectivity, orchestration).
Entities and concepts are just an ontology. Swap them for whatever your domain needs: people, companies, organizations, locations, tools. Go too narrow, and extraction misses things. Go too wide, and it extracts everything. “Entities + Concepts” is a very generic ontology that works on anything, which can be a blessing and a curse. To go deeper, see how to ship a knowledge graph ontology in 5 minutes.
Next, follow a single item from the moment you ingest it to see where those pages come from.