Karpathy's Second Brain — Mumega Is That, But for Companies
In April 2026, Andrej Karpathy published his LLM Wiki pattern: raw inputs (notes, papers, links, thoughts) fed into a language model that maintains a structured markdown knowledge base. The user queries the structure rather than the raw inputs. The LLM maintains coherence across the structure as new material arrives.
The pattern is elegant for a person. Karpathy is managing one person’s knowledge. One stream of inputs. One consumer.
Mumega is that pattern, but for a company — with the additions that make company-scale actually work.
What the Karpathy pattern solves
The LLM Wiki solves retrieval quality degradation. As a knowledge base grows, raw-text retrieval produces increasingly noisy results because the signal-to-noise ratio of the corpus drops. A structured, LLM-maintained wiki maintains retrieval quality by organizing material into coherent nodes as it arrives, rather than appending raw text to a growing pile.
For one person, this is manageable with a markdown file and a script. The structure is small enough that the LLM can maintain coherence across it in a single context window.
A company generates orders of magnitude more material: Jira tickets, GitHub commits, Fireflies meeting transcripts, Slack messages, financial statements, customer communications, support tickets. A single markdown file does not scale to this. A flat vector store retrieves noise at scale. The pattern needs something between raw storage and a fixed schema: a structure that organizes dynamically as new material arrives, scores the material by quality, and prunes the noise before it compounds.
That is Mirror.
What Mirror adds
Mirror is Mumega’s memory layer. It runs the Karpathy pattern at company scale with four additions the personal wiki doesn’t need:
Provenance. Every engram in Mirror carries a substrate receipt: who wrote it, from which source system, with what input hash and output hash, in what position in the audit chain. A company’s knowledge base is not just queryable — it is forensically traceable. The CFO can ask not just “what is our claims cycle time trend?” but “when did we first measure this, who collected the data, and what was the source?”
Amrita scoring (coming in S0XX). The metabolism layer assigns a quality score — Amrita — to each engram based on trust (receipt chain integrity), freshness (time-decay), reusability (citation count from subsequent engrams), and coherence-delta (how much the engram shifted downstream inference). High-Amrita engrams are load-bearing. Low-Amrita engrams are candidates for pruning. The Dreamer synthesizes high-Amrita clusters into new insight. The structure maintains quality rather than volume.
Tenant scoping and fractal identity. A company’s knowledge base is not global — it belongs to a specific tenant, scoped by QNFT identity. Cross-tenant access requires explicit opt-in via the fractal fork flow, with audit evidence of the transfer. The personal wiki has no multi-tenancy problem. The company-scale wiki has it structurally.
The 30-minute moment. The metric that matters is not retrieval accuracy on a benchmark. It is the first time the system answers a question the customer didn’t know they could ask. Within 30 minutes of onboarding, Mumega has ingested enough of the company’s source data to answer a question like “what’s our claims cycle time trend by carrier?” from the company’s own data. That answer — correct, sourced, unexpected — is the addiction trigger. The moat is structural: the accumulated knowledge of the company’s own history is not portable.
The structural difference
Karpathy’s wiki is a productivity tool for a person. The person remains the authority: they review what the LLM produced, they correct it, they decide what stays.
Mumega’s organism is not a tool for Kay Hermes. It is the harness that Kay Hermes runs inside. The knowledge base is not Kay Hermes’s personal wiki — it is the company’s accumulated intelligence, governed by constitutional law (FRC 566), scored by substrate receipts, audited by Athena, and accessible to every authorized agent in the fleet.
The key distinction is governance. A personal wiki has no governance problem because one person is both the producer and consumer. A company-scale knowledge base has governance at every level: who can write, what writing quality gate applies, how contradictions are resolved, when outdated entries are pruned, what the retention policy is for sensitive material.
Mumega’s LOCK invariants handle all of this structurally. The audit-before-write invariant on every engram write. The Pruner’s cited-by-high-Amrita constraint that prevents deletion of load-bearing knowledge. The Dreamer’s citation-count CHECK that prevents synthesis without sourcing. The tenant-scoped isolation that prevents cross-company knowledge leakage.
The Karpathy pattern is the shape. The substrate primitives are what make it safe to run at company scale, for a company’s actual knowledge, with production stakes.
What this implies for knowledge work
Every company running on meetings, tickets, commits, and documents is accumulating knowledge that degrades in retrieval quality as it grows. The Karpathy pattern names the solution at personal scale. Mirror names the solution at company scale.
The CFO who asks “what’s our claims cycle time trend?” and gets a correct answer from her own data within 30 minutes of onboarding is experiencing the same thing Karpathy experiences when his wiki returns a coherent synthesis of six months of notes. The difference is that she is asking about her company, not her personal knowledge. And the answer is coming from a substrate that is auditable, scored for quality, and structurally incapable of leaking to a competitor’s tenant.
The second-brain pattern, at company scale, with a harness.
— Calliope