Most L&D research dies the moment a project ends. The articles you skimmed for the compliance redesign, the SAGE study you cited in last quarter's evaluation framework, the Philippa Hardman piece you almost referenced in a stakeholder meeting. They live as bookmarks, browser tabs, and PDFs in a folder nobody opens.

The LLM Wiki pattern fixes this. Andrej Karpathy described it in April 2026. The core idea: stop treating AI as a search tool you query from scratch every time. Instead, feed it raw research materials and have it incrementally compile a structured, interlinked wiki. The LLM owns the wiki. You curate sources, ask questions, and direct the synthesis.

For L&D folks, this is the closest thing to having a research assistant who reads everything you read, writes summaries, builds cross-references, and never forgets. And it doesn't require a vector database, an embedding pipeline, or an MLOps team.

TL;DR
  • The LLM Wiki pattern: drop raw sources into a raw/ folder. Tell Claude to compile them into a wiki/ folder of summaries, concept pages, and cross-references.
  • Four operations: ingest (process new sources), query (ask multi-hop questions across the wiki), lint (Claude scans for inconsistencies), file answers back (save synthesis to the wiki).
  • Karpathy reports this works at ~100 articles and ~400K words without needing vector DBs or RAG.
  • For L&D: research synthesis, SME knowledge capture, framework libraries, evaluation lessons, vendor evaluation archives.
  • Pairs with the memory system: memory tells Claude who you are; the wiki gives Claude what to reason from.

Why This Pattern Now

The pattern Karpathy described isn't new. Vannevar Bush wrote about the Memex concept in 1945: a personal, curated knowledge store with associative trails between documents. The idea has been around for 80 years.

The unsolved problem was always the same: who maintains the system? Who keeps cross-references current? Who flags contradictions? Who fills gaps when new sources contradict old assumptions?

LLMs solve that. The tedious part of knowledge management isn't reading or thinking. It's the maintenance. That's exactly the kind of work LLMs handle well, at any scale, without burning out.

Karpathy's observation about his own usage: "A large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge." That shift matters for L&D. The same LLM that writes your code can also organize, synthesize, and maintain your research, and it does it without needing a coffee break.

The Architecture

The system has three layers:

Raw sources (raw/). Articles, papers, reports, images, transcripts, data files. The LLM reads these but never modifies them. They're the immutable source of truth. Use the Obsidian Web Clipper extension to convert web articles to markdown. For PDFs, images, and other formats, drop them directly into the folder.

The wiki (wiki/). LLM-generated markdown files: summaries, concept pages, entity pages, and synthesis articles. This layer is fully owned by the AI and evolves continuously. A single new source might trigger updates across 10 to 15 existing wiki pages as cross-references, summaries, and concept entries get revised.

The schema: A configuration document (in CLAUDE.md or a dedicated wiki-rules.md) defining wiki structure, naming conventions, and page formats. This ensures consistency as the wiki grows.

topic-folder/
  raw/                   (immutable sources you drop in)
  wiki/                  (LLM-maintained pages)
  index.md               (catalog of all wiki pages)
  log.md                 (chronological activity log)
  wiki-rules.md          (schema and conventions)

The Four Operations

Ingest

Drop a new source into raw/. Tell Claude to process it. Claude reads the material, writes a summary page, updates the index, creates or updates concept pages, adds cross-references to related entries, and logs the activity. One article can generate updates across a dozen wiki pages.

The L&D version of this: every ATD report, every Philippa Hardman article, every conference recording transcript, every internal stakeholder interview goes into raw/. Claude compiles. Six months in, you have a living synthesis of your professional reading instead of a graveyard of bookmarks.

Query

Once the wiki reaches meaningful size, Claude can answer complex, multi-hop questions by researching across wiki pages. Karpathy found that at ~100 articles and ~400K words, he expected to need vector databases and RAG pipelines. He didn't. The LLM's ability to read index files and follow links handled it.

Translated to L&D: "What does the research say about scenario-based assessment for compliance training? What's the consensus on cognitive load for high-stakes safety modules? Which of our past programs hit Level 3 outcomes and what did they have in common?" The wiki holds the inputs. Claude reasons across them.

Lint

Run periodic health checks where Claude scans the wiki for inconsistencies, stale claims, orphaned pages, missing cross-references, and gaps that suggest new research directions. This is the maintenance work that kills most personal knowledge systems. People lose energy for it. LLMs don't.

Recommended cadence: monthly lint pass. The output is a list of "things to look at". Not edits Claude makes unilaterally. You review and either confirm the changes or tell Claude what to investigate further.

File Answers Back

This is what makes the system compound. When Claude produces a useful synthesis in response to a question, file that answer back into the wiki as a new page. Every query adds to the knowledge base. The wiki gets smarter the more you use it.

The discipline that matters: don't just save the answer, save the question that generated it. Future you (or future Claude) will want to know why this synthesis exists.

The Two Supporting Files

Two files keep the wiki navigable at scale:

index.md. A catalog of all wiki pages with one-line summaries, organized by category. Updated on every ingest. This is how Claude (and you) find things without reading everything. Same principle as the MEMORY.md index in the persistent memory system: cheap to read, points to what matters, never load the whole vault to find one thing.

log.md. An append-only chronological record of ingests, queries, and lint passes. Parseable with standard tools (grep "^## \[" log.md | tail -5). Provides a timeline of how the wiki evolved and when specific knowledge was added.

L&D Use Cases Where This Pays Off

Research Library That Compounds

Every article you read for a project goes into raw/. Six months from now, when you need to design an assessment strategy and you vaguely remember reading something about cognitive load and scenario-based testing, you don't search your email or scroll through bookmarks. You ask Claude. It searches the wiki, pulls the relevant pages, and gives you a synthesis grounded in sources you've already vetted.

The ATD research report you read in January, the Philippa Hardman article from March, the SAGE study on AI-generated assessment quality: all in the wiki, linked to each other, with summaries Claude wrote when you first ingested them. Your past research is now a queryable asset, not a forgotten bookmark.

SME Knowledge Capture

An SME gives you 45 minutes of gold in a kickoff call, and three weeks later you're trying to remember what they said about the exception handling process. Your notes are incomplete. The recording is an hour long. The context is gone.

Instead: after the SME call, drop the transcript or your notes into raw/. Tell Claude to extract the key process knowledge, flag ambiguities that need follow-up, and file the insights into the wiki under the relevant project and concept pages. The SME's knowledge is now captured, indexed, and connected to everything else you know about that topic.

Framework and Methodology Library

How many times have you explained Kirkpatrick's four levels to a new team member? Or walked someone through when to use Bloom's taxonomy versus Mager-style objectives?

Build a wiki section for your methodologies. Not textbook definitions, but how your team actually uses these frameworks. Which Bloom's levels matter most for your compliance training. How you've adapted Kirkpatrick for programs where Level 3 data is hard to collect. The specific evaluation rubrics that worked for your last three projects.

This becomes the onboarding document you wish you had when you started. Updated by Claude every time you add a new source or refine an approach.

Vendor and Tool Evaluation Archive

Every authoring tool demo, every LMS RFP, every AI vendor pitch becomes a raw source. Over time, the wiki holds the consolidated truth: who promised what, what the actual capabilities turned out to be, what your team's experience was. Next time procurement asks about an LMS migration, you have a decision history instead of a guessing game.

Evaluation and Measurement Lessons

Capture the lessons from every program evaluation in the wiki. What Level 3 data actually told you. Which leading indicators predicted business impact. Where your measurement approach broke down. Over time, you build a measurement knowledge base specific to your organization, your programs, and your data.

How This Pairs with the Memory System

The persistent memory system and the LLM Wiki serve different purposes but share the same vault:

  • Memory tells Claude who you are, what you're working on, and how you like to work. It's continuity and preferences. Covered in the setup guide.
  • The Wiki gives Claude deep domain knowledge to reason from. It's accumulated understanding of a topic.

The combined vault structure looks like this:

vault/
  00-MOCs/
    Mission Control.md     (memory hub. Loads at session start)
  09-Memory/               (memory files. Facts about you)
    MEMORY.md              (memory index)
  research-topic-a/        (LLM Wiki for one topic)
    raw/                   (immutable sources)
    wiki/                  (LLM-maintained pages)
    index.md               (wiki catalog)
    log.md                 (activity log)
  research-topic-b/        (separate wiki for another topic)
    raw/
    wiki/
    index.md
    log.md
  CLAUDE.md                (boot sequence. Behavior rules for both systems)

Memory loads at session start (index only). Wiki directories load on demand when you're working on a topic that needs them. CLAUDE.md tells Claude where everything lives and how to interact with each layer.

Anti-Patterns Specific to the Wiki

Manually editing wiki pages. This is the key principle from Karpathy's design: the wiki is the LLM's domain. Curate sources and ask questions. The moment you manually edit wiki pages, you create inconsistencies the LLM doesn't know about. If something needs correcting, tell the LLM to fix it.

Skipping the log. Without log.md, you lose the ability to trace how the wiki evolved or when specific knowledge was added. It costs almost nothing to maintain and pays off when you need to verify a claim.

One giant wiki for everything. Topic-specific wikis (one per research area) keep ingest and query operations cheap. A single 5,000-page wiki across every topic you've ever researched starts to slow down and confuses retrieval.

Treating raw sources as drafts. The raw/ folder is immutable. If a source is wrong or outdated, leave it and tell Claude in a new wiki page why it's been superseded. Editing raw sources breaks the audit trail.

Parallel agents editing the same wiki. Without coordination, merge conflicts waste tokens on recovery. If you run multiple Claude sessions, give each one a different topic-folder.

How to Get Started

If you already have the memory system set up, adding a wiki is straightforward:

  1. Pick one research area you care about: AI in L&D, scenario-based assessment, change management for tech rollouts, whatever you read about most. Don't try to wiki everything at once.
  2. Create the structure: topic-folder/raw/ and topic-folder/wiki/.
  3. Drop in 5 to 10 sources you've already read. Use Web Clipper for web articles, paste transcripts as markdown files, drop PDFs directly.
  4. Write a brief schema in CLAUDE.md or a dedicated wiki-rules.md: page format, naming conventions, frontmatter fields. Even three sentences is enough to start.
  5. Tell Claude: "Process the sources in raw/. Create summary pages, identify key concepts, build an index.md, cross-reference related ideas, and start a log.md with what you did."
  6. Ask a question that spans multiple sources. See what comes back. File the answer back into the wiki.

That's the proof of concept. From there, it's a habit: every article you read, every SME conversation, every framework you apply goes into the system. The wiki grows. The AI gets more useful with every session because it has more of your context to work with.

The Compounding Math

Three months in, you have a wiki with a few dozen pages and a memory system that saves you 15 minutes per session.

Six months in, you have a genuine research library that answers complex questions about your domain.

A year in, you have something that would take a new team member months to build from scratch. And that they can query on day one.

That's the compounding effect. Every source you add makes the next query better. Every session builds on the last. Your knowledge stops being ephemeral and starts being infrastructure.

This is what L&D has been missing. Not better authoring tools. Not faster content production. The thing that compounds: a system where what you learn doesn't evaporate.

—Eian

Sources & Further Reading