LLM Wiki (pattern)

A pattern for personal knowledge bases in which an LLM incrementally builds and maintains a persistent, interlinked markdown wiki that sits between a person and their raw sources. Defined in llm-wiki-gist.

Core idea

The wiki is a persistent, compounding artifact. Rather than re-discovering knowledge per query (as in retrieval-augmented-generation), the LLM compiles each source into the wiki once and keeps it current — cross-references, flagged contradictions, and synthesis are already in place. The wiki gets richer with every source ingested and every question asked.

Architecture — three layers

Raw sources — immutable curated documents; the source of truth.
The wiki — LLM-owned markdown pages (summaries, entity/concept pages, an evolving synthesis). The LLM creates, updates, and cross-references these.
The schema — a config file (e.g. CLAUDE.md) defining structure, conventions, and workflows; co-evolved with use. This is what makes the LLM a disciplined maintainer rather than a generic chatbot.

Three operations

Ingest — add a source; the LLM summarizes it, updates entity/concept pages and the synthesis, and logs it (~10–15 pages touched).
Query — ask a question; the LLM answers with citations and can file good answers back as new pages so explorations compound.
Lint — periodic health check for contradictions, stale claims, orphans, missing pages/links, and data gaps.

Why it works

The hard part of a knowledge base is bookkeeping, which humans abandon. LLMs make maintenance near-free, so the wiki stays maintained. Division of labor: human curates and directs; LLM does the rest. Lineage traces to vannevar-bush's memex — the maintenance problem Bush couldn't solve is the one the LLM handles.

What the compile step costs (wicer, 2026-08-30)

The pattern's load-bearing sentence is in Core idea above: "the LLM compiles each source into the wiki once and keeps it current." wicer (Huerta, arXiv 2605.07068, T1) is the first source here that grades that once. Against 6,800 probe questions over 17 RepLiQA topics, blind compilation scores 2.17 out of 5 with 55.1% of answers wrong or irrelevant — the compiled wiki cannot answer more than half of what its own sources could. Compile-evaluate-refine (probe, find the failures, pin the facts they needed, recompile) recovers about 80% of that in one or two passes and still lands under the raw documents.

Two consequences for this page. First, "compile once" is the expensive assumption, not the cheap one — the pattern's economy comes from not re-reading sources per query, and the price is paid at ingest, unmeasured. Second, the RAG contrast below needs a condition attached: see the contradiction recorded in synthesis.

Tooling (optional, modular)

obsidian (browsing/graph view), qmd (search at scale), Marp (slides), Dataview (frontmatter queries). All optional — "pick what's useful."

Compared to gbrain

gbrain (garry-tan) is the same idea taken further: where the LLM Wiki keeps a human in the loop and navigates by a hand-maintained index, GBrain adds an autonomous "dream cycle" daemon, a self-wiring knowledge-graph, and hybrid vector+BM25 retrieval at ~100K+ pages. The LLM Wiki is the minimal, legible end of this family; GBrain is the maximal, automated end. Both treat a git repo of markdown as the system of record.

Named "wiki memory" and framed as agent memory — LangChain (wiki-memory)

Harrison Chase (LangChain) named the pattern "wiki memory" (Jun 2026) and recast it as a type of agent memory, not just a personal-KB idea. Two additions: (1) it slots the LLM-wiki into a memory taxonomy with an explicit scope boundary — durable domain knowledge, not conversation state, user preferences, or high-frequency event logs (bridge to agentic-tooling-wiki's agent-memory); (2) it sharpens the RAG contrast — "RAG retrieves raw chunks at query time; a wiki precomputes and maintains a higher-level synthesis, so the agent doesn't rediscover the structure every time." Coming from the agent-framework establishment, it's a notability signal like OKF was from Google Cloud.

Implementations

openkb — the pattern packaged and installable (pip install openkb, Apache-2.0, ~4.2k★): the same raw/→wiki/ layout, index.md/log.md spine, an AGENTS.md schema file, auto-extracted entity pages, and add/query/lint commands, plus long-document handling via pageindex and a Skill Factory that compiles the wiki into an agent skill.
gbrain — heavyweight, automated (DB + vector + knowledge graph + daemon).
llm-wiki-agent — lightweight coding-agent skill, markdown-only, no API key; a near-twin of this wiki.
Codebase-documentation sub-genre (wiki-memory): deepwiki (Cognition, AI-generated GitHub repo docs), autowiki (Factory, codebase docs that stay current), and opendeepwiki (AIDotNet, the self-hostable one) — the pattern applied to code rather than personal notes.

What the convergence is and isn't (revised 2026-08-31)

This section used to read the agreement between llm-wiki-agent and this wiki as "multiple independent realizations converging on the same design — evidence the pattern is a natural attractor, not one author's idiosyncrasy." openkb makes that claim harder to keep in that form. It lands on the same three layers, the same two spine files, the same schema-file-as-operating-manual, and the same number — "a single source might touch 10–15 wiki pages" against this page's "~10–15" — and it says outright that it is built from the concept in llm-wiki-gist. So does this hub. Four descendants of one gist agreeing about file layout is descent, not independent arrival, and the attractor argument was overstated.

What survives is narrower and better evidenced: the design survives packaging. A workflow can depend silently on its author; a pip install used by strangers has to write its conventions down and hold them against corpora it did not choose. That is a claim about robustness, not about inevitability. Genuinely independent arrivals still exist in the corpus — OKF (Google Cloud, an enterprise data-catalog format) and tana's supertags do not descend from the gist — and those, not the implementations, are what carries the attractor argument.

Standardized — open-knowledge-format (Google Cloud)

open-knowledge-format (OKF) is the same substrate written down as an open standard by Google Cloud: a bundle of markdown concept files with type frontmatter, reserved index.md/log.md spine files, and prose cross-links — "metadata as code." It's the fifth arrival at typed markdown pages (after this gist, gbrain, tana, and this wiki's @type model) and the first from a hyperscaler, so the pattern is no longer just builder folklore. Of that five, OKF and tana are the ones that owe nothing to the gist — see What the convergence is and isn't above, and note that openkb is now the first tool to claim conformance to this spec.

The compiler critique — wiki-compiler

A sharp counter-argument (wikis-over-engineered-compiler): the claim above — "LLMs make maintenance near-free, so the wiki stays maintained" — concedes too much. Most wiki-work (parsing, cross-referencing, linting) is mechanical and deterministic, and doing it with an agent loop buys token cost, latency, and non-determinism (the same folder compiled twice yields different links). Better to run a deterministic compiler for that 90% and reserve the LLM for the semantic 10% (linking paraphrases a lexical matcher misses). "An agent decides what your wiki might look like; a compiler guarantees what it must look like." It doesn't refute the pattern so much as re-cut the division of labor inside it — and describes what most maintained instances (this hub included) already are: a hybrid of LLM ingest + deterministic link/orphan checks.

retrieval-augmented-generation · memex · associative-trails · gbrain · llm-wiki-agent · openkb · pageindex · wiki-compiler · open-knowledge-format · vannevar-bush · andrej-karpathy