Karpathy LLM Wiki: Build a Source-Backed AI Knowledge Base

Andrej Karpathy described an LLM Wiki pattern for turning raw knowledge into curated, interconnected pages that an AI agent can load on demand. This article uses his public note as a maintained source for the pattern; it does not imply that Karpathy endorses Wenlan.

In practical terms, an LLM wiki is a maintained AI knowledge base. It turns source material and durable work context into topic pages with enough provenance and maintenance state for a person to inspect why the current answer exists.

It is not simply a folder of AI-written notes. A useful LLM wiki separates raw evidence from reusable facts and maintained explanations, then gives each layer a different update rule. The result should remain useful even when the reader never installs the product used to build it.

The smallest dependable design has four planes: source storage, durable memory, maintained pages, and selective retrieval. Keeping them separate prevents a polished page from losing its evidence and prevents a raw event log from masquerading as the current answer.

Maintenance is part of the architecture, not a later cleanup job. When support changes, the system needs to mark the affected page stale, propose or perform a refresh according to ownership, and keep the revision inspectable.

Can your wiki answer a project question, show its evidence, and notice when that answer stops being safe to reuse? Try this small, fictional source packet with your existing AI tool first. These are authored teaching inputs and reference answers, not a Wenlan run, a customer result, or a performance comparison.

Save the three blocks below as separate Markdown files with the displayed filenames in a new, disposable folder. Give your agent read-only access to those files. Keep any generated answer in a separate wiki file; do not let it edit the sources.

Ask: “Using only api-v1.md, decision-07.md, and runbook-v1.md, write a short retry-policy wiki page. Cite the filename for every rule, distinguish retries from total attempts, and list unanswered questions. Do not fill gaps from general knowledge.”

Compare your result with this reference. The point is not matching the wording: all four claims must have the right support, and the timeout must stay unknown. Open each cited file yourself; a plausible citation is not evidence that it supports the sentence.

Next add api-v2.md using the replacement text below, so it replaces api-v1.md. For the second question, ask: “Using api-v2.md, decision-07.md, and runbook-v1.md as the current sources, with api-v1.md as a historical reference only, compare the prior wiki answer with the current evidence. Identify any stale conclusion, preserve the unresolved 1-versus-3 retry conflict, and do not silently modify decision-07.md or settle the conflict.”

If plain files and your agent already handle this clearly, keep that simpler workflow. Consider Wenlan when maintaining source-linked pages and shared lookup across your AI tools is recurring work. Its source links do not verify meaning, and adding a replacement source is not the same as updating an already linked source: review the actual page state. This exercise does not establish Wenlan's accuracy, time savings, automatic maintenance, or your later reuse.

Start only after Wenlan is installed and connected to the AI client. Use one harmless topic first. The protocol below exercises session startup, targeted retrieval, one durable write, a session boundary, page distillation, and human-readable output.

The commands are separate on purpose: recall should not silently write, capture should not rewrite a whole page, and distillation should not overwrite human-owned content without a review path.

Keep the always-loaded contract small. A CLAUDE.md or AGENTS.md should describe what the wiki is for, what never changes silently, and which procedures the agent should load on demand. It should not contain the whole wiki or a long copy of every maintenance instruction.

This is a vendor-neutral information and maintenance contract, not a required folder layout or product database. Adapt the names to your tools while keeping every boundary observable.

A template is not proven when the files merely exist. Test one harmless topic end to end, including a source change, before importing private or business-critical material.

This test works for a folder-and-prompts setup, an Obsidian workflow, or a dedicated LLM-wiki product. The expected result is evidence you can inspect, not just a fluent answer.

Do not stop at a successful command. Verify the artifacts and the next retrieval. A trustworthy setup proves that the agent can recover the intended context later and that a person can inspect the maintained result outside the chat.

If any check fails, keep the test capture harmless, diagnose the connection or source boundary, and repeat the same topic before adding real project knowledge.

Suppose a release document establishes which platforms are actually supported. The source document remains inspectable, an atomic memory preserves the release decision and why it matters, and a maintained page compiles the current install answer. When the release document changes, the page should become stale or receive a reviewable revision.

This evidence trail is more useful than a detached summary because each layer has a clear owner and failure mode.

The hard part is not generating the first page. It is keeping the wiki small enough to retrieve, current enough to trust, and explicit enough that people can repair it.

These failure modes repeat across real LLM-wiki, Obsidian, Claude Code, and agent-memory workflows:

These tools can work together, but they do not own the same layer. The useful question is not which label wins; it is where evidence, current answers, human writing, and cross-session context should live.

An LLM wiki does not replace codebase search, repository maps, current source code, test output, or the native documentation for a tool. Those surfaces remain authoritative for what the software does now.

It is also unnecessary for one-off chats or a small set of stable documents that people already maintain well. Use the wiki when repeated work needs a current, inspectable answer across sessions or tools.

Wenlan implements the pattern with three durable roles: Sources preserve inspectable material, Memories preserve atomic knowledge from work, and Pages compile maintained explanations. The local daemon owns retrieval while readable Markdown keeps pages and session artifacts visible.

The page lifecycle is explicit: distill support, cite it, track dependencies, refresh when needed, and review ownership-sensitive changes. That is the difference between a generated note and a maintained LLM wiki.

Wenlan does not require a user-authored Page schema. Typed Memory fields and built-in Page rules already govern provenance, citations, refresh, ownership, and review; the starter schema above remains a portable evaluation contract for the client and workflow.