LLM Wiki

A knowledge system where an LLM acts as a “programmer” that maintains and evolves an interconnected wiki of concepts, using an Obsidian vault or Markdown repository as the working surface. Unlike rag, which retrieves fragments at query time, this approach compiles knowledge into a structured, persistent base that improves with each new source.

Core Concept

The LLM Wiki pattern, as described by Andrej Karpathy in April 2026, represents a shift from retrieval-augmented generation to compile-time knowledge synthesis. Rather than fetching relevant snippets from sources during each query, the LLM processes sources during ingest and turns them into a durable, linked knowledge layer.

The important point is not merely “long memory.” It is a change of interface: from one-off retrieval of fragments to continuous maintenance of a cognitive artifact. The wiki becomes a middle layer between raw sources and answers. Future questions can consult that layer instead of rediscovering everything from scratch.

Origin and Status

The most solid origin point is Karpathy’s GitHub Gist from 4 April 2026, titled “LLM Wiki.” It framed the idea as a portable pattern, not as a closed product. The gist explicitly described:

• immutable raw sources;
• a generated and maintained Markdown wiki;
• a schema or operating manual such as CLAUDE.md or AGENTS.md;
• index.md as a semantic catalog;
• log.md as an operational history;
• three operations: “Index the sources,” query, and lint. Notable coverage from genai-unplugged documented the production workflow with specific guardrails for real-world use.

The later research report added an important historical distinction: the pattern did not begin as a paper or commercial framework. It began as an operational pattern. Academic and open-source projects then started formalizing it into more reproducible systems, including work described as “Retrieval as Reasoning: Self-Evolving Agent-Native Retrieval via LLM-Wiki.”

Self-Healing Knowledge Base

The community described Karpathy’s system as a “living AI knowledge base that actually heals itself” — the LLM not only ingests sources but actively maintains and repairs the knowledge base across sessions. ^[raw/articles/venturebeat-llm-wiki.md] This solves the “stateless AI development” problem: without a wiki, returning to a session means rebuilding context from scratch. With an LLM Wiki, the wiki is the persistent state.

The self-healing happens automatically during ingest and lint:

• Broken wikilinks are detected and flagged by lint
• Contradictions between old and new sources are surfaced
• Orphan pages are identified for reconnection
• The LLM cross-links new content to old, keeping the graph fresh

One ingest typically produces 5-15 wiki pages per source, depending on content richness. [confidence: low — single source]

Error Book Mechanism

The Tencent “LLM-Wiki” paper (May 2026) introduced the Error Book — a specific mechanism for recording and correcting recurring construction errors during ingest. ^[raw/papers/pesquisa-aprofundada-padrao-llm-wiki.md] Instead of treating each lint finding as a one-off fix, the Error Book accumulates patterns of mistakes (e.g., “repeatedly creates orphan pages for single-source topics”) and adjusts future ingest behavior to avoid them. This transforms lint from a reactive check into a corrective feedback loop. [confidence: medium — single paper, no local implementation yet]

The Error Book is not yet implemented in this vault, but it represents a natural evolution for Phase 2 (Health & Discipline).

Key Differentiators from RAG

The most direct contrast is with rag, but a broader family tree includes fine-tuning as a third approach:

1. When processing happens

   • RAG: at query time, using retrieve-then-generate.
   • LLM Wiki: during ingest, using compile-then-query.

2. Knowledge representation

   • RAG: chunks, embeddings, and similarity search.
   • LLM Wiki: readable pages, explicit links, source provenance, and accumulated synthesis.

3. Compounding behavior

   • RAG may re-summarize similar material repeatedly.
   • LLM Wiki preserves prior synthesis and extends it as new sources arrive.

4. Human inspectability

   • RAG internals can be opaque unless retrieval traces are exposed.
   • LLM Wiki produces an artifact a person can open, edit, audit, and browse.

5. Compounding vs Retrieving

   • RAG focuses on retrieving answers at query time, keeping the system static.
   • LLM Wiki focuses on compiling knowledge asynchronously, ensuring insights compound and grow richer over time.

Three-Layer Architecture

For the system to work properly, three components must stay distinct:

• Immutable source repository (raw/): original PDFs, articles, transcripts, and clippings. These are read-only evidence.
• Active knowledge base (wiki/): LLM-maintained pages for concepts, entities, comparisons, and filed queries.
• Governance framework (_schema.md, AGENTS.md, index.md, log.md): rules, taxonomy, navigation, and operation history.

This separation is what prevents the system from becoming either a pile of raw documents or a hallucinated summary layer. The wiki page must always point back to sources.

Skill-Based Enforcement Model (confidence: medium)

TrueHOOHA/LLM-Wiki-Skilled introduced a variation: workflow rigidity is enforced entirely by skills under .agents/skills/, not by inline instructions in AGENTS.md. The AGENTS.md stays as the schema contract; skills reference and enforce it without redefining schema inline.

The same source frames this as a deliberate division of responsibility:

• AGENTS.md: single source of truth for schema (page types, frontmatter, sections, cross-link rules, index/log contracts)
• .agents/skills/: executable workflow steps (ingest, query, lint) that read the schema and follow it
• No helper scripts: enforcement is entirely skill-based

This vault’s current approach (all workflows inline in AGENTS.md, enforced by scripts/wikilint.ps1) is the opposite trade-off: higher cognitive load on the agent, but model-agnostic and simpler to audit.

“Why This Works” Philosophy (confidence: high)

TrueHOOHA’s AGENTS.md includes a closing section titled “Why This Works” that articulates the core value proposition of the entire LLM Wiki pattern:

The tedious part of maintaining a knowledge base is not the reading or the thinking — it’s the bookkeeping. Updating cross-references, keeping summaries current, noting contradictions, maintaining consistency across dozens of pages. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don’t get bored, don’t forget to update a cross-reference, and can touch 15 files in one pass. The wiki stays maintained because the cost of maintenance is near zero.

This section also references vannevar-bush’s Memex (1945) as the philosophical ancestor, repeating the same citation pattern as Karpathy’s original gist.

Evidence and Terminology

The source-to-page relationship is the evidence trail: raw sources remain immutable, while wiki pages are the mutable synthesis derived from them. Keeping the contributing raw paths in a page’s frontmatter lets a reader trace a compiled claim back to the source material rather than treating the wiki as an unsourced replacement for it.

Karpathy labels the write workflow “Index the sources,” and venturebeat repeats that label. The Sozai Fable video (sozai) provides a walkthrough of the working pattern. This vault instead calls the write operation ingest: read a source and the existing wiki, then create or extend pages and update supporting records. The OKF v0.1 draft explicitly names this operation “Ingest.” index.md remains the catalog used to find pages, not the name of the write operation. ^[raw/articles/karpathy-llm-wiki-gist.md] ^[raw/articles/google-okf-spec.md]

The Processing Loop

When a new source is added to raw/, the LLM should:

1. read the complete source;
2. identify entities, concepts, claims, comparisons, and open questions;
3. check the existing index.md before creating anything;
4. create a new page only when the topic is central or well-supported;
5. update existing pages by preserving prior knowledge and adding new synthesis;
6. maintain wikilinks, frontmatter, index, and log.

This is a semantic process. It cannot be replaced by regex extraction or frequency counting. The failed first bulk ingest showed why: scripts created pages for words like “use,” “when,” and “yes.” A valid LLM Wiki requires LLM judgment.

Relationship to Agent Memory Systems

The newer research positions LLM Wiki inside a broader genealogy of agent memory and structured retrieval systems: agent-memory-systems, GraphRAG, LightRAG, HippoRAG, mem0, MemGPT, and Generative Agents. LLM Wiki is closest to the artifact-first family: it produces a legible Markdown artifact. Memory-first systems focus more on retention across sessions, while graph/retrieval-first systems focus more on scalable retrieval over large corpora.

The practical conclusion is: begin with the artifact, not with infrastructure. First prove that a Markdown wiki maintained by an agent creates useful compounding knowledge. See linking-connections-backlinks-smart-links for a full analysis of how connections work in the LLM Wiki ecosystem. Only then add graph search, MCP tools, managed memory, scheduled routines, or corporate governance.

2026 Convergence: Compiled Knowledge Above Retrieval

Denser’s newer analysis describes a production-oriented extension of the pattern: compile entities, relationships, coverage summaries, and contradiction reports during ingest, then answer from the compiled layer first and fall back to chunk retrieval when needed. It argues for typed entities, confidence scoring, human review for conflicts, and a browsable Markdown artifact rather than treating RAG as obsolete.

The DEV second-brain playbook adds an adjacent requirement: notes must be explicit and structured enough for an LLM to retrieve without guessing at implicit context. This supports the existing artifact-first model while retaining human judgment for selection, depth, and expression.

Implications: LLM Wiki is best treated as a durable compilation layer that can sit above RAG and alongside agent-memory systems, not as a single replacement technology.

Evidence of Effectiveness

In Karpathy’s demonstration, as covered by later analysis, the system started from a small number of sources and produced a set of linked pages within minutes. The key evidence is the emergence of a navigable structure — as one source notes, the-llm-finds-correlations-between-things-you-saved-separately-that-you-would-never-have-drawn-on-your-own — where future queries can use compiled knowledge rather than starting from raw text. [confidence: high — consistent across 3+ sources]

The most significant production extension is rohitg00’s LLM Wiki v2, which adds memory lifecycle management (confidence scoring, supersession, consolidation tiers), typed knowledge graphs, hybrid search (BM25 + vector + graph), and event-driven automation — directly addressing what breaks at scale.

The new research report strengthens this interpretation by placing LLM Wiki among several parallel developments in 2023–2026: Generative Agents, MemGPT, GraphRAG, MCP, HippoRAG 2, mem0, Karpathy’s gist, and Tencent’s LLM-Wiki paper.

LLM Wiki as the Memory Layer of an “AI OS”

The preserved research report describes the LLM Wiki as a compiled, persistent knowledge layer around Claude Code, Skills, and MCP. The original source for the stronger “LLM as operating system kernel” framing is unavailable in the current evidence layer, so that claim is not treated as verified here.

The same report proposes a practical modular framework for LLM Wiki, organized into functional modules: Capture, Normalization, Contextualization, Compilation (core), Organization, Indexing, Retrieval, Feedback, and Governance. Its recommended architectures scale from a Simple Personal AI Second Brain (Obsidian + Git + Claude Desktop) up to a Large-Organization deployment (Confluence + Claude Enterprise + custom Skills/MCP + AI-security infrastructure). This maps cleanly onto the phased plan in vault-roadmap.

The OKF origin story remains contested; see open-knowledge-format, which retains the direct specification and the ambiguity report instead of relying on the unavailable report.

Related

• eva-brain-desktop-app — Eva-brain — Desktop App for LLM Wiki

• rag — the retrieval pattern LLM Wiki most directly contrasts with.

• agent-memory-systems — broader field of persistent memory and structured retrieval for agents.

• claude-code — one of the most natural current tools for operating a local Markdown LLM Wiki.

• open-knowledge-format — structured frontmatter/schema discipline for machine-readable pages.

• llm-wiki-vs-memory-and-graph-rag — comparison between artifact-first, memory-first, and graph/retrieval-first approaches.

• resources — curated list of all external resources referenced across this vault.

• external-skills-ecosystem — comparison of nine installed agent skills for LLM Wiki and second brain workflows.

• vault-roadmap — phased evolution plan for this vault from Foundation to Scale.

• memory-lifecycle — memory lifecycle management (confidence scoring, supersession, consolidation tiers)

• llm-as-os — Karpathy’s framing of the LLM Wiki as the long-term memory layer of an “AI Operating System”

• tiago-forte — creator of CODE+PARA, whose methodology the LLM Wiki operationalizes (Organize+Distill steps)

• code-framework — the CODE processing loop that the LLM Wiki automates

• second-brain — the broader second-brain concept the LLM Wiki is an instance of

🔗 Conexão inferida — sugestão do segundo cérebro

Liga para: andrej-karpathy, claude-code, atomicstrata-llm-wiki-compiler Evidência observável: These three entities appear across 8+ of the 13 raw sources as the primary originators and implementers of the LLM Wiki pattern — they form the origin cluster of this wiki.

Open Questions

• How often does lint catch issues vs how often does it miss them? Sources describe lint checks but provide no recall or precision metrics.
• Is the Error Book effective? Sources propose the mechanism (Tencent paper) but no source measures whether tracking recurring errors actually changes agent behavior.
• What’s the false positive rate of lint rules? Sources list rules but don’t report how often they flag false positives.

^[raw/articles/google-okf-spec.md] (L3 Compiled requires gaps surfaced)

Recent Implementations

The LLM Wiki ecosystem has grown rapidly since April 2026. Notable recent additions:

• krakiun-llmwiki — Rust binary, BM25+semantic+hybrid search via MCP, multi-wiki registry
• pratiyush-llm-wiki — Python, auto-compiles coding agent sessions into Karpathy wiki + static site
• eva-brain — Desktop GUI app for interacting with LLM Wiki
• robust-llm-wiki — Research-backed schema framework for stable maintenance at scale
• geronimo-iia-llm-wiki — Headless wiki engine, 23 MCP tools, Rust binary

Sources

^[raw/articles/karpathy-llm-wiki-gist.md] ^[raw/articles/genai-unplugged-llm-wiki.md] ^[raw/articles/levelup-llm-wiki-deep-dive.md] ^[raw/articles/venturebeat-llm-wiki.md] ^[raw/transcripts/sozai-fable-llm-wiki-video.md] ^[raw/papers/pesquisa-aprofundada-padrao-llm-wiki.md] ^[raw/articles/beyond-rag-karpathy-llm-wiki.md] ^[raw/external/denser-ai-llm-wiki-karpathy-knowledge-base-ee288793.md]