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.

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

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. Together with this wiki itself, that’s multiple independent realizations converging on the same raw/→wiki/ + index/log/synthesis + ingest/query/lint design — evidence the pattern is a natural attractor, not one author’s idiosyncrasy.
Codebase-documentation sub-genre (wiki-memory): deepwiki (Cognition, AI-generated GitHub repo docs) and autowiki (Factory, codebase docs that stay current) — the pattern applied to code rather than personal notes.

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 independent 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.

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 · wiki-compiler · open-knowledge-format · vannevar-bush · andrej-karpathy