The most consequential AI development of 2026 so far isn't a model. In April, Andrej Karpathy published a deceptively simple pattern he calls the LLM wiki: instead of pointing an agent at a pile of raw documents and making it search them again on every query, have the agent compile the knowledge once — into a persistent, cross-linked, plain-markdown wiki that it then maintains — and query the compiled result at runtime. Two months later, Google formalised that pattern into the Open Knowledge Format (OKF): a vendor-neutral spec — markdown files, YAML frontmatter, atomic entries, a clean producer/consumer contract — for the curated context that AI systems consume.
A personal note-taking trick becoming an open standard in eight weeks tells you something. The industry has quietly agreed on where the next real gains live: not in the model, but in what the model gets to know. I've been arguing this from the enterprise side for some time, so let me make the case for what I think comes next: every large organisation is going to need a second brain — a distributed knowledge base, compiled by AI, validated by humans, and governed centrally.
Enterprise knowledge is rich, and unconsumable
Everything an agent needs to be useful inside your company already exists somewhere: the real meaning of that revenue metric, the join path between two systems, the runbook for the incident, the architecture decision from 2021 and the constraint it baked in. The problem is where it lives — scattered across Confluence pages that contradict each other, wikis nobody trusts, schemas without semantics, and the heads of senior engineers. Agents fail on context before they fail on intelligence, and enterprises are context-hostile environments: the knowledge is all there, and none of it is consumable.
The standard answer for the last two years was RAG over the raw pile. That helps, but it inherits the pile's problems: stale pages retrieved confidently, contradictions surfaced without arbitration, and the same expensive re-derivation of understanding on every single query. Karpathy's compiler analogy names the flaw precisely — we've been interpreting our knowledge when we should be compiling it. Compile once, keep it current, serve the compiled artifact everywhere.
The numbers make the business case unusually easy
What makes this moment different from most architecture fashions is that the evidence arrived with it. Atlan's controlled study measured a 38% relative improvement in AI SQL accuracy when agents were given enriched, governed metadata rather than raw schemas — and more than a 2x lift on medium-complexity queries. Snowflake reported that adding a plain-text ontology to their agent stack improved final-answer accuracy by 20%, cut tool calls by 39%, reduced latency by 20% — and dropped cost per query from $1.76 to $0.59.
Read those numbers again as a triple. Accuracy rises because the model reasons over validated meaning instead of guessing from raw artifacts. Cost falls because curated context is dramatically smaller than the pile — the agent stops spelunking through source systems on every request, and you stop paying for tokens that carry no signal. And — the one almost everyone misses — evaluation becomes possible at all. You cannot systematically eval an agent whose context is a shifting heap of documents; there's no stable ground truth to test against. A versioned knowledge base is the ground truth. Every entry can carry its own eval cases; every release of the knowledge, like every release of code, can be regression-tested before agents consume it. That converts AI quality from anecdote to engineering.
The architecture: a second brain with three jobs
The phrase I use for the target state is a distributed second brain, centrally governed — and the tension in that phrase is deliberate. Knowledge must be distributed, because it's born in the domains: the payments team's constraints, the platform team's runbooks, each system's schemas and decisions. But its management must be central, because forty teams each inventing their own format, freshness rules, and quality bar just rebuilds today's Confluence swamp in a trendier syntax. The resolution is to separate three jobs that most organisations blur together:
- AI compiles. A pipeline continuously aggregates from the sources of truth — repositories, ADRs, schemas, tickets, runbooks — and drafts atomic knowledge entries in a standard format. This is the part machines are genuinely better at: Karpathy's observation is that an LLM never forgets to update the cross-references, and can sweep the whole graph in one pass when reality changes. Freshness stops depending on the documentation enthusiasm of busy engineers.
- Domain owners validate. Nothing the pipeline drafts becomes canonical until a human who owns that domain approves it. This is the same conviction I hold about agentic delivery: the gate is the point. Validation is what turns "text an AI generated" into "knowledge the organisation stands behind" — and it's what makes the accuracy gains durable rather than lucky.
- A central platform governs. One format (this is exactly what OKF is for), one pipeline, versioning, lineage from every entry back to its sources, freshness SLAs, access control — and the eval harness that runs on every change. The platform doesn't own the knowledge; it owns the contract the knowledge must meet.
Compile, validate, govern. Distributed authorship, central spine. Any agent in the organisation — coding assistant, support agent, analytics copilot — consumes the same validated brain, and the format contract means a bundle produced by one team's pipeline is consumable by any team's agent without translation. That interoperability is the quiet radicalism of OKF: it treats knowledge the way we learned to treat code — portable, versioned, reviewable, releasable.
What I'd do this quarter
If you lead engineering or data in a large organisation, you don't need a two-year programme to start. You need one domain and a discipline:
- Pick one high-leverage domain — the codebase your agents touch most, or the data model your analysts query most — and compile it into a structured knowledge base. Plain markdown with frontmatter; OKF is v0.1, but it's markdown, so adopting the shape now costs you nothing even as the spec evolves.
- Treat knowledge as code from the first day. A repository, pull requests, owners, reviews, releases. If your knowledge can't be diffed, it can't be governed.
- Wire the evals before you scale. A handful of golden questions per domain, run on every knowledge release and every agent change. This is the asset that compounds: every incident and every wrong answer becomes a new test.
- Measure the triple. Accuracy on your golden set, cost per task, and answer-level evals — the same three numbers the public studies used. If the knowledge layer is working, all three move; if they don't, you've learned that early and cheaply.
Models are rented. Knowledge is owned.
Here's the strategic frame I'd put in front of any executive team. Every competitor rents the same models you do, from the same three or four providers, at prices that keep falling. None of them can rent your compiled, validated, continuously maintained understanding of your own business. The model is a commodity on a depreciation curve; the second brain is a compounding asset — it gets more accurate, more complete, and more load-bearing with every validated entry. The organisations that internalise this in 2026 will spend the next five years answering questions their competitors are still searching for.