Skip to content

LLM Wiki

The LLM Wiki is an architectural pattern for Personal Knowledge Management (PKM) and team knowledge bases, popularized by Andrej Karpathy in April 2026. It represents a paradigm shift from stateless, retrieval-centric workflows (like standard RAG) to stateful, agent-maintained, continuously compounding knowledge bases.

In this model, a Large Language Model (LLM) acts less like a search engine and more like a dedicated librarian or archivist. Instead of merely fetching chunks of raw text when queried, the LLM proactively digests incoming information and "compiles" it into a highly structured, interlinked network of markdown files—a wiki.

Why It Is Better Than RAG

Traditional Retrieval-Augmented Generation (RAG) suffers from a "stateless" problem. When you ask a question, the LLM pulls chunks of text from raw documents, synthesizes an answer, and then immediately forgets that synthesis. The next time you ask a similar question, it must re-read and re-synthesize from scratch.

The LLM Wiki solves this by introducing a persistence layer: - Compounding Synthesis: Knowledge is extracted and filed into canonical concept and entity pages. New documents append to or challenge existing knowledge rather than just sitting in a vector database. - Pre-computed Reasoning: Because the LLM maintains the wiki asynchronously (during the ingestion phase), complex synthesis is already "pre-computed." When queried, the LLM reads from a highly organized, dense knowledge graph rather than scattered raw fragments. - Human-Readable: Unlike vector embeddings, the intermediate state (the wiki) is plain-text markdown. You can browse it, edit it, and visualize it in tools like Obsidian.

When Does It Fit?

The LLM Wiki pattern is ideal for long-term, compounding knowledge domains: - Personal Development: Tracking health, psychology, journal entries, and synthesizing a structured picture of oneself over time. - Deep Research: Conducting multi-week research on complex topics where an evolving thesis must be maintained. - Book/Media Consumption: Building rich companion wikis for long-form content (e.g., character relationships, plot threads, thematic analysis). - Internal Team Wikis: Maintaining living documentation fed by meeting transcripts, Slack threads, and customer calls, without placing the maintenance burden on human engineers.

Ecosystem & Connections

The LLM Wiki pattern relies on a triad of tools: 1. The IDE (Obsidian): The human interface for reading, editing, and visualizing the knowledge graph (using features like Graph View and Dataview). 2. The Agent (Claude Code, Codex, OpenCode): The autonomous actor that executes instructions, reads files, and writes markdown. 3. The Search Engine (qmd): As the wiki scales, local hybrid search engines like qmd (BM25 + Vector + LLM Reranking) provide agents with precise retrieval capabilities via the Model Context Protocol (MCP).

Compatibility & Requirements

To implement an LLM Wiki, you need: - An LLM agent with direct, unrestricted read/write access to a local filesystem. - A well-defined schema or instruction file (e.g., CLAUDE.md, AGENTS.md) to enforce structural consistency. - A local-first markdown editor for human oversight. - (Optional) A local embedding/search tool for scaling beyond simple index.md traversal.

Alternatives

  • Standard RAG (e.g., NotebookLM, ChatGPT File Uploads): Better for quick, one-off interactions with static documents where long-term persistence is unnecessary.
  • GraphRAG: An advanced form of RAG that builds a knowledge graph from raw documents, but typically stores it in a graph database rather than human-readable markdown.
  • Manual PKM: The traditional Zettelkasten or Second Brain approach. Highly personalized but often suffers from "maintenance bankruptcy" where the effort of cross-referencing outpaces the value.

Migration & Lock-in

Because the output of an LLM Wiki is standard markdown, there is zero vendor lock-in. You can swap the LLM agent (e.g., moving from Claude Code to a local model via Ollama) or the IDE (from Obsidian to Logseq) without losing any synthesized knowledge or structural integrity.

Community Health

The shift toward agent-maintained wikis gained significant traction in mid-2026, driven by the release of highly capable, local-first coding agents and tools like qmd that bridged the gap between raw file systems and LLM context windows. The community heavily favors open-source, local-first toolchains to ensure privacy and data sovereignty.

Adoption signals (as of July 2026):

  • Karpathy's April 2026 X post introducing the pattern drew over 16 million views; the companion gist collected 5,000+ stars within days.
  • The framing that stuck with the community: "Obsidian is the IDE. The LLM is the programmer. The wiki is the codebase."
  • Community implementations have appeared that run the pattern fully offline (e.g., Ollama + Qwen3 + qmd), validating that the pattern does not depend on frontier cloud models.

Core Operations

The pattern reduces to three recurring agent workflows:

  1. Ingest — read a new raw source, create a provenance reference note, merge facts into entity/concept pages, flag contradictions, update the global index, append to the audit log.
  2. Query — read the index, open the 3-5 relevant pages, synthesize an answer; valuable answers are filed back as new wiki pages rather than discarded.
  3. Maintain — periodic lint passes: fix broken links, merge duplicate pages, refresh stale summaries, and keep the index consistent with the file tree.

Sources

Questions

  • Scaling Limits: At what point (file count/token size) does a pure index.md traversal break down, necessitating a dedicated local search engine like qmd?
  • Conflict Resolution: How should the agent handle direct contradictions between an older, highly trusted source and a newer, unverified source during the Ingestion phase?
  • Human-in-the-Loop: What is the optimal UI/UX for a human to review and approve the agent's wiki modifications before they are committed?