Karpathy's LLM Wiki: The Second-Brain Pattern and the Enterprise Reality Check 2026
In early April 2026 Andrej Karpathy described on X how an LLM agent compiles and maintains a persistent wiki for him. Six weeks later the enterprise debate is hot: what works about the pattern as a personal tool, where it fails on governance, and which steps European companies can sensibly take now.
Andrej Karpathy, co-founder of OpenAI and former AI Director at Tesla, published an architecture pattern on April 3, 2026, that is reshaping the enterprise knowledge management debate. Instead of re-retrieving sources on every question, an LLM agent compiles a persistent markdown wiki from raw sources, with a clean split between Raw, Wiki, and Schema. His example research wiki on a single topic spans around 100 articles and 400,000 words, with each ingest updating 10 to 15 wiki pages. Several enterprise architects published between April and May 2026 why the pattern works as a personal knowledge weapon and fails as a corporate platform: no role-based access control, no ACID transactions, no compliance-grade audit logs, scalability limits at a few hundred pages. Y Combinator named the missing primitive in its Spring 2026 Requests for Startups: a company brain. European vendors such as EconLab AI have already launched managed GDPR variants on Hetzner DE for around 4,900 euros setup.
What Karpathy triggered
On April 3, 2026, Andrej Karpathy described a workflow on X that has shifted his own use of large language models. Instead of using LLMs mainly for code generation, he has been pushing most of his token spend into building personal knowledge bases for weeks. His example: a single research wiki on one topic has grown to around 100 articles and 400,000 words, written and maintained by an LLM agent that ingests raw sources and manages the structured wiki layer.
- Karpathy is a co-founder of OpenAI and former AI Director at Tesla; his technical statements are read and copied unusually widely in AI engineering
- On April 4, 2026, he published the full architecture as a GitHub gist, copy-pasteable as a spec for your own agents
- Within two weeks, roughly two dozen German and English how-to articles and implementations appeared
- Unlike earlier releases such as nanoGPT or nanochat, Karpathy did not publish code but a convention; the pattern is deliberately abstract
Karpathy's contribution is not a tool but a convention. The impact comes not from the code but from the clear split of responsibilities between human and LLM agent.
The architecture pattern: three layers and three operations
Karpathy's spec separates three layers strictly, with clear responsibilities between human and LLM agent. That is the actual design decision, not the choice of tool.
-
Raw sources
Folder
/raw. Immutable original documents, articles, papers, images. The agent reads, never modifies. This is the source of truth. -
Wiki
Folder
/wiki. Markdown pages generated and maintained by the LLM. Entity pages, concept pages, synthesis pages. Only the agent writes here; the human sources and reads. -
Schema
A single file, analogous to
CLAUDE.md. Defines structure, conventions, and workflows. The agent behaves like a disciplined wiki maintainer.
Three operations run across these layers and keep the system alive.
- Ingest: A new source is read, a summary page is created, the index is updated, and 10 to 15 existing wiki pages are touched in the same pass
- Query: Answers to questions are filed back into the wiki as new pages; every question grows the system
- Lint: Periodic health checks identify contradictions, stale claims, orphan pages, and gaps
Two helper files keep the system inspectable: an
index.md
with one-line summaries of every page, sized to fit a context window and read first by the agent, and a
log.md
as an append-only chronicle of all ingests, queries, and lints, parseable with grep.
Why the pattern takes on RAG
Classical Retrieval-Augmented Generation has the LLM search a vector index on every question and assemble an answer from the hits. It works, but has conceptual weaknesses that Karpathy's pattern aims to address.
This is not an incremental improvement but a different architectural decision. RAG vendors will not disappear, but from now on they compete with a pattern that moves the expensive work forward and treats knowledge as a growing artefact.
The enterprise reality check
Once the pattern moves out of Karpathy's personal vault and into a company, several properties he never promised collapse. Several enterprise architects published between April and May 2026 explaining why the pattern works as a personal knowledge weapon and fails as a corporate platform.
No RBAC
File system permissions do not cover corporate governance. Who is allowed to read which page, which source to not see, which synthesis to produce?
No ACID transactions
Multiple agents or users ingesting in parallel create write conflicts. Git versioning eases the pain but does not solve it.
Audit logs are not audit logs
A git history shows who changed what, but it is not a compliance-grade record for finance, pharma, or energy utilities.
Scaling strikes back
Beyond a few hundred pages, retrieval, ranking, reranking, and chunking return. Karpathy's 100-page vault is not proof for millions of documents.
Another weakness drowns in the initial excitement: hallucinations compound. If the agent writes a false fact into the wiki, the probability is high that later ingests build on it. Human review for critical pages becomes mandatory once the system is more than a research playground.
Y Combinator named the missing primitive directly in its Spring 2026 Requests for Startups:
If we want every company to run on AI automation, we need a new primitive: a company brain.
European and EU perspective
For European companies the pattern overlays directly with GDPR, the EU AI Act, and IT security requirements. The local nature of the original setup is both an advantage and a trap here.
- Markdown files kept locally are more GDPR-friendly than cloud RAG at US providers because data sovereignty is easier to argue
- Once LLM calls go to US models, the data transfer question returns, independent of where the files live
- EU-compliant backends such as Azure OpenAI EU or European inference providers are the obvious answer; they cost money and speed
- Vendors such as EconLab AI have already launched AuditBrain, a managed variant as a Docker container on German Hetzner servers, with setup packages from 4,900 euros
- The EU AI Act does not hit the pattern directly, but as soon as the wiki contains personal data or supports decisions, transparency and documentation obligations apply
- Anonymising sources before ingest becomes a mandatory exercise because personal references can be reconstructed from synthesis pages even when only implicit in the source
Read on: Our analysis of the Obsidian-Claude integration describes how Karpathy's pattern runs in real European setups, from MCP security concerns to token limits in larger vaults.
What companies should do now
The pattern deserves a serious look, but not as a big platform project. The entry point is small, the effort stays manageable, and the learning effect is high.
-
Start small
Begin with a personal or team setup on a concrete research topic such as a market scan, regulatory watch, or technical research. Not with the corporate knowledge base.
-
Separate the three layers cleanly
Decouple sources, wiki, and schema strictly. The three-layer discipline is the most important takeaway from Karpathy's spec.
-
Provenance at the claim level
Every wiki statement should be traceable to a specific source segment, not just to a source overall. Otherwise truth cannot be separated from hallucination.
-
Approval workflows for critical pages
Build in approvals instead of letting the agent write autonomously. A pull-request model with human sign-off is a good template here.
-
Let governance scale with wiki size
At the point where the wiki no longer fits a context window, retrieval is needed. With it the old problems return, just in a different order.
-
Decide the backend question early
EU-compliant inference, local models, or accepted residual risk at US providers. Every option has a price, every one is defensible, but not all are freely interchangeable.
Anyone already running a Glean, Confluence, or Notion setup should treat the LLM Wiki not as a replacement but as a complementary research pattern. The strength lies in compounding research, not in replacing document management.
Challenges and risks
Anyone deploying the pattern in production carries the risks Karpathy hardly has as a researcher. Five risks stand out.
- Hallucination compounding: A false fact in the wiki is treated as given by later ingests and cemented into synthesis pages.
- Token cost scales with wiki size: Every ingest touching 10 to 15 pages costs measurably. In production this becomes its own budget line.
- Lock-in to the LLM vendor: The pattern is vendor-neutral, but the quality of wiki maintenance hinges on the model. Switching is not trivial.
- Shadow knowledge: Employees may build parallel private wikis, undermining central governance.
- Half-life of truth: In fast-moving domains, synthesis pages go stale before the sources, and the lint pass does not catch it reliably.
Further reading
Frequently asked questions
Andrej Karpathy's LLM Wiki is an architecture pattern in which an LLM agent compiles and continuously maintains a persistent, interlinked markdown wiki from raw sources. Karpathy described it on X on April 3, 2026, and published the full spec as a GitHub gist one day later. His own research wiki on a single topic comprises around 100 articles and 400,000 words, all written by the agent.
RAG rediscovers knowledge on every query by searching a vector index and assembling an answer from chunks. The LLM Wiki compiles synthesis once during ingest and keeps it persistent. Cross-references already exist, contradictions are flagged in lint passes, the index is always current. This is not an incremental improvement but a different architectural decision.
Yes as a personal or team knowledge base, no as a corporate platform. It lacks role-based access control, ACID transactions, multi-user concurrency, and compliance-grade audit logs. A git history is not an audit log for regulated industries. Y Combinator named the missing primitive directly in its Spring 2026 Requests for Startups: a company brain with enterprise governance.
The local markdown files themselves are more GDPR-friendly than cloud RAG. But once LLM calls go to US models, the data transfer question returns. GDPR-compliant backends such as Azure OpenAI EU or European inference providers are the obvious answer. Vendors like EconLab AI have already launched managed GDPR variants as Docker containers on Hetzner DE. Source documents containing personal data must be anonymised before ingest.
His research wiki on a single topic has grown to around 100 articles and roughly 400,000 words. Each new source ingest updates 10 to 15 existing wiki pages. That is impressive for a personal setup but no proof of scaling to millions of documents, where retrieval, ranking, and chunking come back into play.
Start small with a concrete research topic such as a market scan or regulatory watch, not the entire corporate knowledge base. Separate sources, wiki, and schema cleanly. Implement provenance at the claim level. Add approval workflows for critical pages instead of autonomous writes. Decide the backend question early, EU-compliant inference or local models. Compare honestly with Glean, Confluence with AI, or Notion.