LLM Wiki Pattern

What It Does

The LLM Wiki Pattern is a knowledge management architecture proposed by Andrej Karpathy in April 2026. Instead of using RAG (Retrieval-Augmented Generation) to retrieve raw documents at query time, this pattern has an LLM agent process source documents once and maintain a persistent, interlinked collection of markdown files — a “wiki” — that serves as an intermediate knowledge layer between raw sources and the user.

The key insight is the distinction between compilation and rediscovery. Standard RAG rediscovers relationships and synthesizes knowledge fresh on every query, with no memory across sessions. The wiki pattern compiles knowledge incrementally: sources are processed once, entity pages are built and cross-linked, contradictions are flagged, and the wiki becomes progressively richer with each ingestion cycle. Future queries read from the compiled wiki rather than raw sources, which is typically smaller, more structured, and pre-synthesized.

Key Features

• Three-layer architecture: raw sources (immutable) → LLM-maintained wiki (markdown pages) → schema document (configuration and workflow specification)
• Ingest operation: LLM processes sources one at a time, discusses findings, writes summaries, updates entity pages, and appends to a chronological log
• Query operation: LLM searches wiki pages and synthesizes answers with citations; valuable query explorations become new wiki pages
• Lint operation: periodic health check to identify contradictions, stale claims, orphaned pages, and data gaps
• index.md: auto-maintained catalog of all wiki pages with summaries and metadata
• log.md: append-only chronological record with consistent prefixes for CLI parsing
• Optional local search: integration with tools like qmd for hybrid BM25/vector search with LLM re-ranking
• Image handling: local image downloads rather than URL references to ensure durability
• Schema-driven: a schema document specifies page types, linking conventions, and agent workflows — changes to the schema reshape all future ingestions

Use Cases

• Use case 1: Technical research compounding — processing 50–200 papers/articles on a domain over months, building entity pages for concepts, authors, and datasets that grow richer with each addition
• Use case 2: Personal second brain — tracking notes, ideas, and references across projects with persistent cross-linking maintained by an agent rather than manually
• Use case 3: Domain expertise capture — systematically reading a corpus (e.g., all papers on a niche topic) and building a queryable, synthesized knowledge base that can answer complex questions by reading the pre-compiled wiki
• Use case 4: Stakeholder intelligence — enterprise adaptations tracking stakeholders, projects, and decisions in interlinked entity pages updated on each new input

Adoption Level Analysis

Small teams (<20 engineers): Fits well for personal or small-team knowledge management. The pattern requires only a capable LLM agent (Claude Code, GPT-4, etc.) and a filesystem. No infrastructure beyond the agent itself. Operational overhead is low; the main cost is LLM API calls on ingestion.

Medium orgs (20–200 engineers): Can fit for specialized teams building domain expertise wikis (e.g., a research team, a security team tracking threat intelligence). Shared wiki requires version control and conflict resolution conventions. The lint operation becomes more important at this scale to catch agent-introduced inconsistencies.

Enterprise (200+ engineers): Not suited in current form. The pattern is single-agent and does not address concurrent writes, access control, auditability, or integration with enterprise knowledge systems. Enterprise adaptations would require significant additional engineering. The community reports “service delivery management” adaptations, but these are informal.

Alternatives

Evidence & Sources

• Original gist by Andrej Karpathy — primary source
• Karpathy’s LLM Knowledge Bases: The Post-Code AI Workflow — independent commentary
• LLM Knowledge Bases | DAIR.AI Academy — educational writeup
• Andrej Karpathy Moves Beyond RAG — industry coverage

Notes & Caveats

• Hallucination risk in maintenance: The agent maintaining the wiki can introduce incorrect information, broken cross-references, or silently drop nuance during synthesis. The lint operation relies on the same model to detect its own errors — a circularity problem with no guaranteed resolution.
• Stale wiki poisoning: Unlike RAG which always queries source material, the wiki becomes an intermediate artifact that can contain errors. A wrong entity page will affect all future queries that touch it, whereas RAG would re-read the original source on each query.
• No independent benchmark: No controlled comparison exists between LLM Wiki query accuracy and equivalent RAG query accuracy over the same corpus. The pattern’s claimed superiority is based on intuition and anecdote, not measurement.
• Schema dependency: The quality of the wiki is tightly coupled to the schema document quality. A poorly designed schema will produce a poorly organized wiki. This is a hidden ongoing cost.
• Pattern maturity: Published April 2026, spawning community implementations within days. Adoption is early-stage. Enterprise-grade tooling does not yet exist.
• LLM API cost: Ingestion requires LLM calls for each source document processed. For large corpora, this can be non-trivial. The pattern is most cost-effective when the corpus is stable (process once, query many times) and queries are frequent.
• llmwiki.app: A cloud implementation appeared within days of the gist. No independent review of its reliability or data practices was available at review time.