Skip to content
Hussh
Connect MCP

LLM Wiki pattern — landscape & R&D

How people are spinning up LLM Wikis as of May 2026. Karpathy's origin gist, three implementation levels, known failure modes, tooling landscape, and how Hussh's wiki compares.

About Wiki

TL;DR: The "LLM Wiki" is a pattern (not a product) where an LLM agent maintains a persistent, interlinked markdown knowledge base on top of immutable raw sources, governed by a schema file. It was crystallized by Andrej Karpathy in an April 2026 GitHub Gist and triggered an ecosystem of Obsidian workflows, Claude Code skills, MCP search backends, and packaged wiki agents. Hussh now implements the pattern as a live app: markdown canonical store, qmd hybrid search, MCP tools for read/write/capture/artifacts, public/private visibility, and a Next.js reader. The most important remaining upgrades are semantic relation typing and fact-level confidence/recency metadata. Status as of 2026-05-14: Updated to reflect the live Hussh wiki app + MCP implementation.

Relations

  • A page-schema document at the wiki root encodes our conventions (private).
  • A top-level index page auto-loads on every Claude turn (private).
  • A constitutional rules document holds standing rules (private).
  • An open-questions ledger tracks contradictions awaiting resolution (private).
  • LLM Wiki Landscape — Three Levels — Three-levels landscape diagram
  • LLM wiki pattern landscape — comparative landscape diagram.

1. Origin: Karpathy's gist (April 2026)

The pattern crystallized in a single ~2,000-word GitHub Gist by Andrej Karpathy ("llm-wiki"). Its three claims:

  1. RAG re-derives knowledge on every query. Compiled wikis don't.
  2. The bookkeeping is the hard part of any knowledge base — and bookkeeping is exactly what LLMs are good at, never get bored of, and can do across 15 files in one pass.
  3. The pattern is intentionally abstract — a domain language, not a product. You instantiate it with your LLM agent.

Three layers, in his words:

  • Raw sources — immutable. The LLM reads but never modifies.
  • Wiki — LLM-generated markdown. Pages, summaries, syntheses.
  • Schema — the operating manual (e.g., CLAUDE.md, AGENTS.md). "The most important file in the system."

Three operations:

  • Ingest — drop a source, the LLM reads, extracts, integrates across 5–15 pages.
  • Query — read the index, drill in, answer. Good answers get filed back as new pages.
  • Lint — periodic health check for contradictions, stale claims, orphan pages, missing pages, missing cross-references.

Two indexing files:

  • index.md — content-oriented catalog.
  • log.md — chronological, append-only, parseable with grep.

Karpathy explicitly grounds the pattern in Vannevar Bush's Memex (1945) — the human couldn't solve the maintenance burden, the LLM can.

2. Three implementation levels in the wild

People are spinning this up at three escalating levels of investment:

Level 1 — "Just paste the gist"

Copy-paste Karpathy's gist into a Claude Code / Codex / Cursor / Gemini CLI session, pick a folder, start dropping sources. Open the folder in Obsidian as a side-by-side IDE (LLM on one side, Obsidian on the other). 5-minute setup. No code. This is what the aimaker.substack tutorial and MindStudio walkthrough advocate. Most viral version: it's all prompting. This is roughly where the Hussh wiki started.

Level 2 — "Slash commands and skills"

Wrap the workflow in agent-native slash commands. Two notable repos:

Level 3 — "Hybrid retrieval + knowledge graph"

For wikis above ~100–200 pages, the flat index breaks down and people bolt on real retrieval infrastructure. The dominant tool here is qmd:

  • Local hybrid search: BM25 + vector embeddings + LLM reranking, all on-device via node-llama-cpp GGUF models.
  • Reciprocal-rank-fusion combines BM25 + vector scores; LLM reranker scores top-30 candidates.
  • Ships both a CLI and an MCP server, so Claude Code can use it as a native tool.
  • Shopify CTO Tobias Lütke is the maintainer, which is why it has visibility.

Beyond qmd, the LLM Wiki v2 gist by rohitg00 layers four ideas on top of the pattern:

  • Knowledge lifecycle: facts decay (Ebbinghaus curve), reinforce on access, and supersede explicitly with timestamps.
  • Confidence metadata per fact (source count, recency, contradictions). "A claim should know it came from two sources, was last confirmed three weeks ago, and sits at confidence 0.85."
  • Memory tiers: working → episodic → semantic → procedural.
  • Self-healing lint: contradiction-detection automated, not manual.

3. What's known to break

The critical perspectives are sharper than the boosters. Three named failure modes:

  1. Compounding errors — unlike RAG which re-reads the source, the LLM Wiki bakes the LLM's interpretation into the artifact. Hallucinations during ingest become permanent until lint catches them. The compounding effect cuts both ways. (Discussed in the MindStudio LLM-Wiki-vs-RAG comparison.)

  2. Manual relationship discovery — agents don't autonomously notice that two pages should link. The pattern claims "LLMs do the bookkeeping" but in practice, the human has to point at every connection. Vault Linker (autonomous overnight crawl with human approval) is one fix.

A fourth implicit failure mode is wiki rot at scale. Without automation hooks (auto-ingest on new sources, auto-lint on schedule), the wiki decays just like a human-maintained one — slower, but real.

4. Tooling landscape (May 2026)

ToolLayerRole
Claude Code / Codex / Gemini CLI / OpenCodeAgentThe maintainer. Reads CLAUDE.md/AGENTS.md/GEMINI.md.
ObsidianEditorMarkdown IDE. Graph view = wiki health visualization.
Obsidian Web ClipperSource ingestorBrowser → markdown for fast raw-source capture.
DataviewPluginFrontmatter-based queries (dynamic tables).
MarpPluginMarkdown → slide decks.
qmdSearchLocal BM25 + vector + LLM-rerank, with MCP server.
PenfieldGraph backendMCP-accessible knowledge graph for cross-session memory.
markitdownConversionPDF/DOCX/PPTX → markdown for ingest.
wiki-skills (kfchou)Skill packClaude Code skills for ingest/query/lint/audit.
llm-wiki-agent (SamurAIGPT)Skill packAgent-agnostic skill bundle + graph visualization.
gitHistoryFree version-control, branching, recovery.

5. How the Hussh wiki compares

Pattern elementKarpathy gistHussh wikiNotes
Three-layer architectureRaw / Wiki / SchemaSameAdapted the index pattern to the wiki's auto-loaded context page.
Schema fileProject rule document recommendedSchema page at wiki rootCould add a global local-agent rules redirect.
Index fileIndex markdown pageAuto-loaded indexHussh-specific because of the agent-memory contract.
Log fileParseable log markdownSame conventionPlain text search works on the timeline log.
OperationsIngest / Query / LintQuery and lint are MCP tools; ingest/capture is tool-backedDurable moments can become pages or drafts through MCP.
FrontmatterOptionalMandatory name, description, typeType system aligns to auto-memory: user / feedback / project / reference.
Page templateImplicitExplicit TL;DR, Status as of, Relations, SourcesHussh-specific addition.
Cross-linkingPlain markdown linksSameCould upgrade to typed wikilinks later.
Constitutional layerNot explicitConstitutional rules documentHussh-specific addition; public pages abstract private operating rules.

6. Recommendations for Hussh — ordered by leverage

High leverage, low cost

  1. Routinize lint as a recurring pass. Schedule a monthly lint review. Output: a checklist surfaced as a new dated entry in the timeline log. Catches contradiction drift before it compounds.
  2. Add a wiki-audit style fact-check for high-stakes pages. Dispatch focused review passes per cited source to confirm the page matches its evidence.
  3. Add a confidence line to volatile facts (source count, last-confirmed date, contradiction status). Cheap text addition; gives future agents clear epistemic posture.

Medium leverage, medium cost

  1. Adopt typed-wikilink syntax for the Relations blocks where relation type matters: [Page A @unverified], [Entity @contradicts rule X], [New Contact @supersedes Old Contact @track_active]. Does not require a plugin; it needs schema documentation and lint support.
  2. Ingest the backlog of source artifacts from upstream knowledge stores, founder notes, and internal artifacts. Each should become an immutable source entry before synthesis lands in public pages.

Higher leverage, higher cost

  1. Keep qmd operationally boring. It is already wired into the MCP; the next improvement is monitoring/index freshness, not a new retrieval stack.
  2. Add a global local-agent rules redirect so the founder's standing rules apply when working outside this repo. Currently project-only.
  3. Mirror to a private remote for off-machine backup once the backup/export boundary is stable. Git should remain audit/export, not the hot write path.

7. What we should NOT borrow

  • Penfield's MCP knowledge-graph backend is overkill until Hussh's wiki crosses several hundred entities and you actually need cross-session, query-over-graph behavior. The current Obsidian graph view + plain links solves the human-readable case.
  • Memory tiers (working / episodic / semantic / procedural) from v2 — interesting framing for agent memory broadly, but for a single user's domain wiki, the marginal value over Status as of dates is small.
  • Auto-ingest from Slack/email/podcasts — the LLM Wiki essay floats this as a possible direction. For Hussh, explicit ingest is a feature, not a bug — it aligns with PCHP's "no silent data flows" principle. Auto-ingestion would be inconsistent with the consent-first architecture you're building elsewhere.

Sources