Build a Karpathy-style LLM wiki in Obsidian: the implementation guide

In April 2026, Andrej Karpathy described a pattern he calls the LLM wiki, and it quietly inverts everything about how most people keep notes. The usual second brain is a pile you maintain and occasionally ask an AI about. Karpathy's version reverses the arrows: the model builds and maintains the knowledge base, and you almost never write in it by hand. His own words are blunt - you rarely ever write or edit the wiki manually, it's the domain of the LLM. The framing that stuck with the community: Obsidian is the IDE, the LLM is the programmer, and the wiki is the codebase.

There is now no shortage of posts explaining that idea. What is genuinely scarce is the layer below it: the actual frontmatter fields, the exact ingest contract, the shell script that makes the whole thing safe to leave on a timer, and an honest account of what breaks after a few hundred pages. This guide is that layer.

Everything below is taken from a wiki that has been running since July 2026 for our own research and for two companies. As of 10 August 2026 it holds 163 pages - 13 topic hubs, 33 entity pages, 25 concept pages and 92 source summaries - across roughly 145,000 words, with 94 logged decisions and more than 8,000 captured events behind it. Almost none of that was typed by hand. Where a number appears in this guide, it was measured on that repository, not estimated.

If you want the shortest possible summary: you own the sources, the model owns the wiki, and a schema file is the contract between them.

The reversal, and why it matters#

Tiago Forte's Building a Second Brain made the case for capturing everything you learn. The problem was always the maintenance tax: a knowledge base decays the moment you stop grooming it, and nobody grooms it. Karpathy's move is to hand the grooming to the model. You spend your token budget not on generating code but on knowledge manipulation - reading, summarizing, cross-linking, reconciling. At the time he posted, one research topic in his wiki had grown to roughly 100 articles and 400,000 words, longer than most PhD dissertations, and he had not typed a word of it.

That is the promise. The rest of this guide is how to build one that survives contact with a few hundred sources.

The architecture is not folders. It is write permissions.#

The design is deliberately small: three directories, three roles, and one hard rule about who is allowed to write where.

The rule to internalize: sources are append-only and model-read-only; the wiki is model-write; the schema is human-write.

Source immutability is not fussiness, it is auditability. If the model can rewrite a source, you lose the ability to trace any conclusion back to what it was actually based on. Ground truth does not get edited by the thing reasoning over it.

The wiki itself has exactly four page types, and the distinction earns its keep:

• source - one summary per ingested document. What it is, its key claims, and a "Touched pages" list naming every wiki page that changed because of it. Written once at ingest, rarely edited after.
• entity - a living page for a person, company, org or product. Facts with citations, updated on every relevant ingest.
• concept - a term, idea or framework. Definition, context, and how it relates to entities and topics.
• topic - a synthesis hub with an evolving thesis. This is the most valuable layer and the newest, and it is where contradictions and open questions are allowed to live in the open.

Get the permission boundary right and the rest is detail. Get it wrong and you have a very confident mess.

Three frontmatter fields carry the whole system#

This is the part almost nobody publishes. Every page opens with YAML, and most of it is bookkeeping - type, tags, created, updated, sources. Three fields do the real work.

---
type: concept
tags: [aeo, search]
created: 2026-07-12
updated: 2026-08-04
aliases: [AEO, answer engine optimization, answer-engine optimisation]
reviewed: true
sources:
  - strategy/firms/cognerd/full-audit-and-plan-2026-07-09.md
---

aliases: - every entity and concept page lists the other names someone might search for: abbreviations, expansions, former names, common misspellings. This looks like metadata housekeeping. It is actually the field that prevents the single most common failure in an auto-maintained wiki, which is aeo, answer-engine-optimization and AEO (Answer Engine Optimization) all existing as three separate pages that each know a third of the story. Populate it at ingest time. Skip it and drift starts somewhere around a hundred pages.

reviewed: true - set by hand on any page you have personally curated. A reviewed page's existing content is authoritative: the model never rewrites, re-orders or re-words it. New information goes into a new section appended at the end, or into a conflict callout. Everything else stays byte-identical. One field, zero code, and it is the only thing standing between your careful hand-editing and your own automation. We borrowed this from the obsidian-llm-wiki plugin, whose prompts branch on exactly this flag.

The conflict callout - not a field, a rule, and the one that matters most for trustworthiness. When a new source disagrees with an existing claim, the model must never silently pick a winner:

> [!warning] Conflict: source A (2026-05) says X; source B (2026-07) says Y. Unresolved.

Both claims stay, flagged, until there is evidence to settle it. A wiki that hides its disagreements is a wiki that launders bad information into consensus.

The ingest contract: five steps, and the one everybody skips#

Ingest is the operation that makes the thing compound. In the schema it is five numbered steps, and it is worth being pedantic about the order:

1. Read the raw source in full. Not the abstract, not the first screen.
2. Write or update its sources/ page. Summary, key claims, and the list of pages this ingest will touch.
3. Resolve before you create. For each entity and concept the source names, check the index - titles and every aliases: list - for a page that already means the same thing. Differing case, abbreviation versus expansion, or a renamed company all count as the same page. Update the existing page and add the new name to its aliases. Only create a page when nothing matches.
4. Ripple outward. Update every entity, concept and topic page the source informs. Create red-linked pages where warranted. Respect reviewed: true - append, never rewrite.
5. Update the index and append one line to the log.

Step 3 is the one everybody skips, and it is the difference between a knowledge graph and a pile of near-duplicates. Most published implementations write the new page, add forward links out of it, and stop. The dedupe pass is what keeps the corpus converging instead of fragmenting, and aliases: is what makes the dedupe pass actually find anything.

There is a companion move to step 4 that is worth building early, and which we have not built yet: backlink write-back. Ingest writes links out of the new page, but nothing sweeps the existing corpus for pages that mention the new page's subject without linking to it. The result is that orphans get reported by a lint pass later instead of being prevented at ingest. The cheapest version is a grep, not a model call: extract the new page's concepts, search the corpus for unlinked mentions, add the link.

The dispatcher: three invariants that make automation safe#

The ingest itself is a model task. The thing that schedules it is not, and it should be as boring as possible. Ours is a 172-line bash script that finds inbox files the wiki has not seen and hands them one at a time to a headless Claude Code run. Three properties make it safe to leave on a timer forever.

1. Hash the content, never the path.

sha="$(shasum -a 256 "$f" | awk '{print $1}')"
if already_ingested "$sha" "$MANIFEST"; then
  skipped=$((skipped+1)); continue
fi

A sha256 manifest means a renamed file is not re-ingested and an edited file is. Path-based tracking gets both cases wrong.

2. Sequential, never parallel. It is tempting to fan out across the inbox. Do not. Two sources that both mention the same company will both edit that company's entity page, and one will silently clobber the other. This is a genuine write race, not a theoretical one, and the fix is to be slower.

3. Record nothing unless the wiki actually changed. This is the single best idea in the script and the one we have never seen published elsewhere:

before="$(wiki_state)"
if (cd "$WORKSPACE" && claude -p "$prompt" $PERM); then
  if [ "$(wiki_state)" != "$before" ]; then
    printf '%s\t%s\t%s\n' "$sha" "$rel" "$(date -u +%Y-%m-%dT%H:%M:%SZ)" >> "$MANIFEST"
  else
    echo "   ! claude produced no wiki changes - NOT recorded, will retry" >&2
  fi
fi

A run that exits zero having done nothing is a failure, and the naive version of this script cannot tell the difference. By comparing wiki state before and after and withholding the manifest write when nothing changed, a silent no-op gets retried on the next run instead of being marked permanently done. Without this invariant, one bad afternoon quietly swallows a batch of sources and you find out months later.

Give the script --dry-run, --limit N, a --seed mode that marks the current inbox as already-done without running anything, and a --self-test. Then it is genuinely safe on a cron:

*/30 * * * * PERM="--dangerously-skip-permissions" /path/to/bin/process-inbox.sh >> /tmp/ingest.log 2>&1

Retrieval: no embeddings, and the size where that stops being true#

The retrieval layer is a single markdown file. index.md is a plain catalog - one line per page, a name and a one-sentence summary, grouped by type - updated on every ingest. Ours is 195 lines. There is no vector store, no embedding model, and no RAG.

This is a deliberate bet, and it is not a permanent one. At a few hundred pages, a maintained catalog genuinely beats a search index: the model reads the catalog, picks the three pages that matter, and reads those. Progressive disclosure, no infrastructure, nothing to keep in sync. Community calibration puts the point where cross-linking starts paying at roughly 100 to 200 processed notes, which matches what we see: the topic layer only became the most valuable one after about a hundred pages.

The honest boundary: when index.md stops fitting comfortably in context, adopt a search layer rather than building one. QMD (local markdown search over BM25 plus vectors with an LLM re-rank, shipping as both a CLI and an MCP server) is the off-the-shelf answer. Notably, the most complete third-party implementation of this pattern also refuses embeddings and uses Personalized PageRank over the wikilink graph instead. The graph you already wrote is a better retrieval signal than a vector of the text.

Why this beats RAG at personal scale#

Retrieval-augmented generation does its sorting work on every single question, over raw data that was never cleaned, then hopes the top-k chunks contain the answer. The LLM wiki does that work once, at ingest time, and produces a clean, condensed, cross-linked artifact that fits in a modern long-context window. Pre-processing beats re-processing when the corpus is small enough to pre-process.

The failure mode that kills naive RAG is well documented: ask your vault how a note on burnout contradicts your Q1 goals and pure vector similarity hands you notes sharing the word "tired". Mathematically correct, intellectually useless, because contradiction is a relationship, not a keyword overlap. The wiki captures that relationship at ingest, when the model actually reasons about how a new source sits against the old ones.

Be honest about the boundary. At enterprise scale - millions of documents, granular access control, real-time freshness - RAG keeps all its advantages and compile-everything stops being feasible. The pattern also lacks RBAC and ACID entirely, which is where it fails at org scale. This is the same buy-versus-build judgement we apply everywhere: match the architecture to the scale. If you want the retrieval side done properly, our RAG is an architecture post is the companion to this one.

What actually breaks#

Two things, and neither is hallucination.

1. The documents about the system drift away from the system#

This one is worth telling precisely, because it happened here and it is dated. While drafting a post about this wiki, a planning document in the same repository was quoted as the source of truth for what had been built. It said the idempotent ingest was "not started". The repository said otherwise: the dispatcher described above had shipped ten days earlier, with a real run already recorded in the changelog. The planning doc was ten days stale, and it was what everything else kept citing.

The rule that came out of it: re-derive any claim about your own system from the artifact, never from the document that describes it. Grep the repo, not the roadmap. The correction now sits in that planning doc's own line 130, along with the lesson - a roadmap that is not re-derived from the repo becomes a fiction that other work quotes.

This is not a one-off, and it is not folklore. Three separate research results measure the mechanism.

Repeated maintenance corrupts documents, and it never plateaus. Microsoft Research's DELEGATE-52 (April 2026) put 19 models through reversible edit pairs across 310 simulated work environments in 52 professional domains. Because every edit has an exact inverse, a round trip should return the document byte-for-byte, so corruption is measurable without human annotation. The frontier models corrupted roughly 25% of document content within 20 interactions. The average across all 19 was near 50%. Nothing plateaued, even at 100 interactions, and two-interaction performance did not predict long-horizon behaviour at all. Worst of the findings for anyone automating this: giving the model an agentic tool harness made degradation worse, by about 6%.

Rewriting pulls text toward the model's own attractors. The transmission-chain study presented at ICLR 2025 ran 600 chains of 50 generations each and found text properties converging on model-specific attractor states, undetectably per-edit and statistically certain in aggregate. The useful detail is the ordering: drift was worst under open-ended instructions ("continue"), weakest under constrained ones ("rephrase"). Tell the model to restate, never to improve.

Indexed summaries out-compete the sources they came from. This is the one that should change your architecture. Neural retrievers are measurably biased toward LLM-written text over semantically equivalent human text - up to a 67% relative NDCG@1 penalty against the original, with rerankers amplifying it, because generated prose has more focused semantics and less noise for an embedding to match. Feed that back into a loop and you get the "spiral of silence": within about ten write-read cycles, human-authored text falls below 10% of top-50 results. Your summary does not sit politely beside your source in the index. It replaces it.

Notably, BM25 shows no such bias. Lexical search is one of the reasons a plain catalog holds up better than it has any right to.

What actually protects you#

The mitigations are unglamorous, and one of them turns out to be load-bearing in a way we did not originally appreciate.

Keep the originals, always. Recursive training collapses when generated data replaces real data, but when originals are kept and derived data merely accumulates alongside, test error is provably bounded. That is the formal argument for the immutability rule at the top of this guide. Sources being read-only is not tidiness. It is the property that keeps drift bounded instead of compounding.

Treat the wiki as a cache, not as ground truth. A page is regenerable from its sources. It should never be cited as the origin of a fact, and it should never outrank the original.

Consolidate slowly, and know that consolidation can make things worse. Per-session rewriting is the compounding case above, and the direct measurement is worse than "diminishing returns": in one 2026 study, memory utility rises and then degrades below the no-memory baseline. On a set of problems a model solved at 100% with no memory at all, updating memory after every single item dragged it down to 52.6% by round ten - while consolidating the same material in one batched pass held it near 95% across fifty rounds. The paper's conclusion is precise and worth quoting: mandatory rewriting at every step, rather than abstraction itself, is the decisive failure mode.

The practical shape that falls out of this: append freely, rewrite rarely, and rewrite in batches over related material rather than per item. "No consolidation at all" is a legitimate answer - in the same study, appending raw trajectories beat four purpose-built memory systems in most comparisons.

⚠️ The strongest current evidence actually cuts against this pattern's core premise. A July 2026 study of filesystem-based memory for agents found that organising a store roughly halves retrieval cost, that the organisation erodes for all but the strongest management agent, and - the uncomfortable part - that no agent it measured converted organisation itself into better answers. Cheaper to search, not yet demonstrably smarter. If you build this, build it for the retrieval economics and the audit trail, and treat "better thinking" as an unproven bonus.

Keep provenance as a field, so "why do I believe this" stays answerable back to a source rather than to another page.

For detection, the cheapest mechanism is the one DELEGATE-52 used as its methodology: round-trip probes. Apply an instruction and its exact inverse, then diff against the original. Any residue is corruption, it needs no labels, and it is fully deterministic.

2. The pipeline fails quietly#

Measured on this repository today: 20 sources are sitting in the inbox unprocessed - 34 files present, 14 of their hashes in the manifest. The pending count has gone 6, then 17, then 19, then 20, and that last increment happened during the twenty-five minutes it took to write this section. It is growing faster than it is being ingested, and nothing anywhere alarms on it.

This was predicted. The note in our own roadmap flagged the inbox-flood risk months ago and specified the fix as roughly five lines: alert when the pending count crosses a threshold. It has not been built, which is precisely why the backlog is now measurable. A pipeline that fails silently looks exactly like a pipeline with nothing to do. If you build only one guardrail, build this one.

The upgrade ladder#

Ordered by value per line of code. Every rung is deterministic, and not one of them is a model call - which is the point. The expensive part of this system should be the reading, not the plumbing.

1. Backlink write-back. Extract the new page's concepts, grep the corpus for pages that mention them without linking, add the link. Prevents the orphan class instead of reporting it later. This is where aliases: finally pays off, because the mention will usually use a different name.
2. A structural validator. Frontmatter shape, resolvable links, orphan pages, index drift. Markdown pipelines do not fail loudly, they drift silently and you notice months later. Build validation before you build more automation - that ordering is the main lesson from someone who built the pattern twice, once as code and once as markdown.
3. Typed edges, zero model calls. The wikilinks are already written. Pattern-match them into typed edges (works_at, founded, supersedes) and flat notes become queryable: who works where, what superseded what. This is the trick behind GBrain, which builds its graph with regex rather than inference. Its published BrainBench figures put the graph at +31.4 points of P@5 over its own graph-disabled variant, which is the clearest available evidence that the graph, not the embeddings, produces the lift. Read it as directional rather than settled: the corpus was model-generated and the benchmark is the project's own.
4. Validity windows instead of overwrites. Store valid-from and valid-until on any fact that changes, and close the old window rather than deleting it. This is the Graphiti pattern from the agent-memory world, and it prevents the classic embarrassment of a system that still believes a client is single six months after the wedding.
5. A promotion threshold for red links. A concept mentioned across five or more pages without a page of its own has earned one. A frequency count is a deterministic answer to "what should exist next", which is otherwise a judgement call you will never get around to making.

What not to build#

This list is as load-bearing as the ladder.

No vector database. No RAG layer. No managed memory framework. No nightly daemon. Each one is a system that itself needs maintaining, and maintenance is the exact tax this design exists to avoid. Mem0, Zep and Letta are excellent and they are solving a different problem: multi-session memory for agents, not a wiki a human reads.

A note on the received wisdom here, since this guide otherwise insists on sourcing everything. "People capture enthusiastically for a few weeks and then abandon it" is repeated everywhere, including in an earlier version of this post. We went looking for the data behind it and there is none - no cohort study, no published abandonment base rate for personal knowledge systems. The nearest real numbers are generic app-retention benchmarks, which are not about this. The related finding that is documented is narrower and more interesting: people reliably revisit what they processed, and largely do not revisit what they merely captured. So the argument for keeping this small is not that everyone quits. It is that compiling is the step that makes capture worth anything.

One more: do not put the model in the read path. It should compile and synthesize on the way in. Simple search and retrieval should not need it.

Build it yourself: the short version#

1. Point a coding agent (Claude Code works well) at an Obsidian vault.
2. Create sources/, wiki/ with the four page-type folders, and SCHEMA.md.
3. Write the schema first. Page shapes, naming, the three frontmatter fields, the five-step ingest, the conflict rule, and a definition of done per operation. Treat it as an API contract, because that is what it is. When the wiki drifts, you tighten the schema rather than scolding the model.
4. Ingest ten sources by hand, through the agent, following the contract. Read what comes out. Fix the schema where the output disappointed you. Repeat until the shape is right.
5. Only now automate. Write the dispatcher with all three invariants, seed the manifest against your existing inbox so nothing is re-ingested, then put it on a timer.
6. Add the pending-count alarm before you walk away from it.

Steps 3 and 4 are the ones people skip, and skipping them is why so many of these end up as a folder of inconsistent markdown.

Takeaways#

• The architecture is write permissions, not folders: sources immutable and model-read-only, wiki model-write, schema human-write.
• Three frontmatter fields carry the system: aliases: makes dedupe possible, reviewed: true protects your hand-edits from your own automation, and a conflict callout keeps disagreements visible instead of laundering them.
• The ingest contract's step 3, resolve before you create, is the step everybody skips and the one that keeps the corpus converging.
• The dispatcher needs three invariants: hash content not paths, run sequentially, and never record a run that changed nothing.
• Skip embeddings until a maintained index genuinely stops scaling, then adopt a search layer rather than building one.
• The real failure is not hallucination. It is documents about the system drifting away from the system while everything cites them, and pipelines that fail silently. Re-derive from the artifact; alarm on the backlog.
• Every worthwhile upgrade is deterministic. If a rung needs a model call, look again.

References#

1. Karpathy's LLM wiki idea file (GitHub Gist, Apr 2026) - the primary pattern: immutable sources, an LLM-maintained wiki, schema-governed operations.
2. Karpathy's original LLM knowledge-bases post (X, Apr 2026)
3. Karpathy's instructions for building an AI-driven second brain (Techstrong.ai)
4. Karpathy's LLM wiki: a self-updating second brain with Obsidian (MindStudio)
5. What is Karpathy's LLM wiki? Building a knowledge base with Claude Code (MindStudio)
6. How to build an AI second brain with Obsidian and Claude (MindStudio) - vendor content, but the source of the backlink write-back technique, the five-mention concept-hub threshold, the inbox flood alarm, and the 100-to-200-note calibration.
7. How I took Karpathy's LLM wiki and built an AI-powered second brain in Obsidian (AI Maker) - the three-layer architecture and the ingest/process/lint command triple.
8. Adding quality control to Karpathy's LLM wiki (Mick Yates) - source pedigree scoring at ingest.
9. Building a second brain that compounds (Fabian Williams) - the compiled: false flag and the idempotent compile sweep.
10. I built Karpathy's LLM wiki twice, once as code and once as markdown (Towards AI) - why structural validation precedes unattended pipelines.
11. green-dalii/obsidian-llm-wiki - the most complete third-party implementation: entity resolution, the reviewed: true authority flag, alias generation, and Personalized PageRank retrieval with no embeddings.
12. GBrain (Garry Tan) - a production self-wiring knowledge graph; typed edges extracted by pattern-matching rather than inference.
13. LLMs Corrupt Your Documents When You Delegate (Microsoft Research, Apr 2026) - DELEGATE-52: 19 models, 52 domains, reversible edit pairs. ~25% corruption within 20 interactions for frontier models, no plateau at 100. The single best evidence for why maintenance is the hard part.
14. When LLMs Play the Telephone Game (ICLR 2025) - 600 chains of 50 generations; text drifts toward model-specific attractors, worst under open-ended instructions, weakest under "rephrase".
15. Neural Retrievers are Biased Towards LLM-Generated Content (KDD 2024) - up to 67% relative NDCG@1 penalty against human sources versus semantically equivalent LLM text. BM25 shows no such bias.
16. Spiral of Silence: How is Large Language Model Killing Information Retrieval? (2024) - derived text reaches over 80% of top-5 slots after one injection round; human text falls below 10% of top-50 within ten cycles.
17. Is Model Collapse Inevitable? Breaking the Curse of Recursion by Accumulating Real and Synthetic Data (2024) - error is provably bounded when originals are kept and derived data accumulates alongside them, rather than replacing them. The formal case for immutable sources.
18. Useful Memories Become Faulty When Continuously Updated by LLMs (2026) - memory utility rises then falls below the no-memory baseline; the regression traces to the consolidation step itself.
19. Filesystem-Based Memory for LLM Agents: Organization, Evolution, and Sustainability (Jul 2026) - organisation roughly halves retrieval cost, erodes for all but the strongest management agent, and no measured agent converted organisation into better answers.
20. The LLM wiki at scale: token costs, hallucination contamination, and the second brain graveyard (Proudfrog) - the skeptic's case, and the source of the knowledge-base-poisoning framing.
21. LLM wiki maintenance: drift, contradictions and review (Rost Glukhov) - maintenance as the real product of a compiled knowledge system.
22. Karpathy's LLM wiki and the enterprise reality check (innobu) - where the pattern fails at org scale, and why single-user is the sweet spot.
23. How we built an AI second brain for 60k knowledge workers (Analytics at Meta) - Claude Code plus markdown skills, at organizational scale.
24. How to build a company brain (Vectorize) - the four-layer model, and why consolidation is the layer everyone gets wrong.
25. Zep / Graphiti: temporal knowledge graphs for agent memory (arXiv) - the validity-window pattern behind rung 4.
26. Continuous consolidation degrades memory (arXiv) - why weekly beats nightly.
27. Introducing the Open Knowledge Format (Google Cloud) and the OKF v0.1 spec - the same pattern as a portable interchange convention.
28. The missing piece every Obsidian user needs: local RAG in 2026 (DEV)
29. obsidian-local-llm-hub and ObsidianRAG - plugin routes into the pattern if you would rather not wire the driver yourself.

Hero image via Unsplash.

We build knowledge systems that compound instead of rot, for our own research and for clients. Explore our other insights or get in touch if you want to talk through your own second brain.