Open Knowledge Format: Why a Folder Beats RAG

For two years the AI industry agreed on how to give a model memory. You chopped your documents into thousands of fragments, turned each fragment into a long list of numbers, and paid to store them in a special database. Then this spring, one of the most respected names in AI looked at the whole apparatus and said: just use a folder of text files. And it worked better.

That folder now has a name. On June 12, 2026, Google Cloud turned the loose community idea into a formal spec called the Open Knowledge Format. This piece walks through what is actually in it, why a folder can beat a vector database, and where the shine comes off. One quick disambiguation first: this OKF is Google’s agent-context spec, not the unrelated Open Knowledge Foundation.

What is the Open Knowledge Format?

The Open Knowledge Format is an open spec, published by Google Cloud on June 12, 2026, for storing the knowledge an AI agent needs as a folder of plain Markdown files. Each file is one concept. The whole thing is about 15 KB of specification, released under Apache 2.0, and Google’s own framing is that if you can open a file, you can read it.

The pitch rests on a problem every team feels. The context an agent needs is scattered: a metric’s definition lives in one database, its logic in some pipeline, the reason it changed in a six-month-old pull request, and the rest in the head of an engineer who left in March. OKF says: collect that into one bundle, keep it in version control, and hand it to any agent. No new runtime, no schema registry, no proprietary API.

Why did giving AI memory get so over-engineered?

Because the scattered knowledge had to come from somewhere, and the industry’s standard answer was expensive. The fix was a technique called RAG, retrieval-augmented generation. You take all those documents, slice them into chunks, turn each chunk into a long list of numbers that captures its rough meaning, and load them into a vector database. Ask a question, the system grabs the chunks that look closest, and hands them to the model.

It works. But it never remembers. Every query starts from zero. The model gets a fresh pile of disconnected snippets and has to work out the same connections it worked out an hour ago, and the hour before that. Retrieval is hard engineering, and for some jobs it is still the right tool. The catch is that you pay for that reasoning again on every single question.

What is Karpathy’s LLM wiki?

The respected name was Andrej Karpathy, co-founder of OpenAI and former head of AI at Tesla. In April 2026 he posted a short file to GitHub for an idea he called the LLM wiki, and it flips RAG on its head. Instead of the model re-deriving everything the moment you ask, you build the knowledge up once, into a folder of plain text files that link to each other. The gist drew thousands of stars within weeks, and searches for “llm wiki” jumped more than tenfold in April and May.

People hear “a folder of notes” and assume they are the one writing the notes. Wrong way round. You do not write the wiki. The AI does. You bring it new material and ask good questions, and it handles the summarizing, the cross-referencing, and the filing, all the upkeep nobody ever keeps up with. Karpathy’s own line for it: Obsidian is the IDE, the LLM is the programmer, the wiki is the codebase.

RAG · at every query

1. chunk the docs
2. embed each chunk
3. search the vectors
4. re-derive the links

Every question repeats the whole loop. The model gets a fresh pile of snippets and works out the same connections it worked out an hour ago.

Starts from zero

LLM wiki · once, up front

1. read the index
2. open one file
3. read the answer

The linking, the contradiction-flagging and the summaries happen once, when the bundle is built. After that, reading is free.

Built once, then read

What Google actually shipped in the spec

Google took that loose idea and pinned down a handful of rules, and the spec is almost comically small. A bundle is a folder. Every file is one concept: a table, a metric, a playbook, whatever you have. The file’s path is its name. Links between files form a graph. Two filenames are reserved, index.md to list what is in a folder and log.md to record changes.

There is exactly one hard rule: every file has to say what type of thing it is, in one field. The spec then orders any tool reading a bundle to forgive almost everything, including unknown fields, broken links, and even files it cannot parse. An enterprise standard whose defining feature is how little it demands. One thing Google quietly dropped, though: Karpathy’s instructions for how the AI maintains the wiki. They kept the folder and left out the part that keeps it alive.

sales-knowledge/ one bundle = one folder

metric revenue.md

table orders.md

playbook refunds.md

reserved · lists the folder index.md

reserved · change history log.md

THE ONE HARD RULE type: metric Every file declares what it is, in one field. Everything else is optional, and readers must forgive missing fields, unknown types and broken links.

Why does a folder beat the vector database?

For three reasons, and they stack. First, when the work happens. RAG does its thinking at question time; the wiki does it once, up front, when the bundle is built, then you just read the finished answer. Second, scale. A big company has thousands of these files, and a model can only hold so much at once. Each folder carries a short table of contents, so the model reads that, opens the one file it needs, and skips the other nine thousand.

Third, it is only text. It lives in Git exactly like code: you can diff it, review it in a pull request, zip the whole thing and hand it to a model running offline on a laptop. You do not need a database, a server, or an API key to read it. The trade-off is that all of this assumes the knowledge inside is good, which the format itself does nothing to guarantee.

When the work happens Build once

RAG does its thinking at question time, every time. The wiki does the linking and summarizing once, when the bundle is built. After that, reads are free.

Scale Skip 9,000

Each folder carries a short table of contents. The model reads that first, opens the one file it needs, and never chokes on the other nine thousand.

It's only text Lives in Git

Diff it, review it in a pull request, zip it for a laptop offline. No database, no server, no API key. If you can open a file, you can read it.

OKF vs MCP, and the SEO myth

Two mix-ups spread fast, and both are wrong. The first is that OKF competes with MCP. It does not. MCP is the pipe that moves data around live; OKF is the cargo that moves through it. An MCP server can hand an agent an OKF bundle, so the two slot together rather than fight.

The second is that OKF is an SEO trick. It is not. Nothing in it helps a search engine find you. It is private knowledge for your own agents, not a public discovery layer like llms.txt. The table below places OKF against the things it keeps getting confused with.

Not vs MCP

MCP the pipe that moves data around live

vs

OKF the cargo that rides through the pipe

Not SEO

SEO helps a search engine find your public pages

vs

OKF private knowledge for your own agents

Where OKF falls short: three catches

The pitch is that the AI does the bookkeeping humans always abandon, and that is exactly where it gets shaky. The first catch is freshness. The spec has a field for a timestamp, but a field is not a process. Nothing in the format updates itself. This works beautifully when one person owns one folder. On a shared team folder it goes stale in a month, nobody volunteers to tend it, and the agent starts answering from knowledge that expired back in spring.

The second catch is funnier. The whole idea rests on AI being a tireless, accurate librarian, but in practice language models are bad at writing clean Markdown at scale. They botch headers and invent links to files that were never created. Google’s fix for the messy-librarian problem was to change the spec so every reader has to forgive the mess. The third catch is the deepest: the format standardizes the container, not the meaning. The one required field is a freeform label, so your team writes “BigQuery Table”, mine writes “table”, and a third writes “relational asset”. All valid, none interoperable.

Goes stale Catch 1 · no upkeep

A timestamp is a field, not a process. One person keeps a folder fresh. A shared team folder rots in a month, and the agent starts answering from knowledge that expired in spring.

Messy MD Catch 2 · the librarian

The pitch rests on AI being a tidy librarian. In practice, models botch headers and invent links to files that never existed. Google’s fix was to order every reader to forgive the mess.

Just a box Catch 3 · the meaning

The one required field is freeform. Your team writes "BigQuery Table", mine writes "table", someone else "relational asset". All valid, none interoperate. The box ships; agreeing on the contents is still on you.

Is OKF a Trojan horse for Google’s stack?

Where OKF came from matters. It did not come out of Google’s AI lab; it came from the BigQuery team. Every sample dataset ships on BigQuery. The reference tool that writes the bundles runs on Gemini. And the easiest place to pour a finished bundle is Google’s own knowledge product, Dataplex, which it renamed Knowledge Catalog and repositioned for exactly this moment.

None of that makes the format bad. Giving away a free, open file format while the demand it creates flows toward the part you sell is a clean strategy, the classic move of commoditizing the complement. As one skeptical-but-fair read put it, OKF advances structural interoperability while leaving the semantic kind for later. The openness, it turns out, is the strategy.

Sample datasets → BigQuery

Reference tool → Gemini

Finished bundle → Knowledge Catalog

→

All roads Google's stack

Will OKF stick?

Hard to say. The day it launched, almost nobody outside Google was using it, and no data-catalog vendor had announced support. A standard with one user is just a suggestion, and this one could easily become the next entry in Google’s long graveyard of shut-down projects. The spec is a v0.1 starting point, and its fate turns on a number that began at zero: producers and consumers built by anyone but Google.

The idea underneath it, though, has already won. The most over-funded field in tech spent two years and a fortune convincing itself that giving a machine memory needed exotic infrastructure. Then a tidy folder of text files did the job better. If you have watched our Gemma 4 piece, you can already smell the same playbook here: give away the cheap part, own the platform underneath. Whatever happens to the format, that part is not going back in the box.