Why Google Ditched Vector Databases for Folders

After two years of industry consensus on vector databases for AI memory, Andrej Karpathy proposed a simpler approach: a folder of linked text files. Google formalized this as the Open Knowledge Format (OKF), a minimal spec that lets AI build and maintain knowledge once, then reuse it—no database needed. The format wins on speed, scalability, and portability, but faces real challenges: staleness on shared teams, AI librarians that botch markdown, and semantic ambiguity that no format can solve.

The Old Way: RAG and Vector Databases

RAG: The Industry Standard for Two Years

The AI industry standardized on Retrieval-Augmented Generation: chop documents into chunks, convert each to a vector (list of numbers representing meaning), store in a vector database, then retrieve similar chunks when answering questions. It works but forces the model to re-derive connections every query, starting from zero each time.

The Problem: No Real Memory

Every query starts fresh. The model receives disconnected snippets and must re-work the same logical connections it solved an hour ago and the hour before. There is no persistent understanding built up over time.

The New Way: LLM Wiki and OKF

Andrej Karpathy's LLM Wiki Concept

In April, Karpathy (OpenAI co-founder, former Tesla AI head) posted the LLM Wiki to GitHub: instead of re-deriving everything on each query, build knowledge once into a folder of plain text files that link to each other. The AI writes and maintains the wiki; humans bring new material and ask questions. Karpathy's framing: Obsidian is the IDE, the LLM is the programmer, the wiki is the code base.

Google Formalizes It: Open Knowledge Format (OKF)

On June 12, Google Cloud published OKF as an official spec. A bundle is a folder; each file is one concept (table, metric, playbook, etc.); the file path is its name; links form a graph. Two special files: one listing contents, one logging changes. One hard rule: every file must declare its type in one field. The spec orders readers to forgive unknown fields, broken links, and unparseable files.

Why the Folder Wins: Three Reasons

Timing: Work Happens Once, Not Per Query

RAG does thinking at question time. The wiki does it once up front when the bundle is built—connecting concepts, flagging contradictions, writing summaries. You pay that cost a single time, then just read the finished answer. No repeated computation.

Scalability: Table of Contents Prevents Choking

A model can only hold so much in its head at once. With thousands of files, each folder carries a short table of contents. The model reads that first, picks the one file it needs, and skips the other 9,000. It never chokes on the whole library.

Portability: Plain Text, No Infrastructure

It is only text. It lives in Git exactly like code—you can diff it, review in pull requests, zip it, and hand it to a model running offline on a laptop. No database, server, or API key needed. If you can open a file, you can use it.

What OKF Is Not

Not Competing with MCP

MCP is the pipe that moves data around live. OKF is the cargo that moves through it. They serve different purposes and can coexist.

Not an SEO Trick

Nothing in OKF helps a search engine find you. It is private knowledge for your own agents, not public-facing content.

The Real Catches: Three Problems

Catch One: Staleness on Shared Teams

The spec has no mechanism to keep anything current. A timestamp field exists, 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.

Catch Two: AI Librarians Botch Markdown

The whole idea rests on AI being a tireless, accurate librarian. In practice, language models are bad at writing clean markdown at scale. They botch formatting, mangle headers, and invent links to files that were never created. Google's fix: change the spec to order every reader to forgive the mess. That permissive rule is damage control with a nicer name.

Catch Three: Semantic Ambiguity—No Shared Language

The format standardizes the container, not the meaning. The one required field is a free-form label. Your team writes 'BigQuery table,' mine writes 'table,' someone else writes 'relational asset.' They are all valid, but each speaks a different language. You can ship the box anywhere. Agreeing on what is inside is still on you. No format can hand you that.

The Invisible Moat

Organization Matters More Than Format

An agent is basically just a folder of markdown files. Anyone can write markdown. The skill is in how the folder is organized: what is locked versus what the AI can rewrite, what stops it drifting over a long run. The moat is invisible. Two folders can look identical. One holds up in production while the other slowly rots. You cannot tell which is which by reading the files. No format can hand you that.

The Business Layer: Google's Strategy

OKF Came from BigQuery, Not AI Lab

OKF did not come out of Google's AI lab—it came from the BigQuery team. Every sample data set ships on BigQuery. The reference tool that writes the bundles runs on Gemini. The easiest place to pour a finished bundle is Google's own knowledge product, which they just renamed for exactly this moment. This is strategic positioning, not pure open-source altruism.

Will It Stick?

Adoption Uncertainty

The day OKF launched, almost nobody outside Google was using it. A standard with one user is just a suggestion. It could easily be the next Google project added to their graveyard. However, the idea underneath it has already won: the most overfunded 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. Whatever happens to the format, that part is not going back in the box.

Notable quotes

Just use a folder of text files. And it worked better. — Narrator, summarizing Google's approach
Obsidian is the IDE, the LLM is the programmer, the wiki is the code base. — Andrej Karpathy
An agent is basically just a folder of markdown files. The skill is in how the folder is organized. — Developer (quoted)
Devsplainers
8 min video
3 min read
Why Google Ditched Vector Databases for Folders
You just saved 5 min.
The big takeaway
After two years of industry consensus on vector databases for AI memory, Andrej Karpathy proposed a simpler approach: a folder of linked text files. Google formalized this as the Open Knowledge Format (OKF), a minimal spec that lets AI build and maintain knowledge once, then reuse it—no database needed. The format wins on speed, scalability, and portability, but faces real challenges: staleness on shared teams, AI librarians that botch markdown, and semantic ambiguity that no format can solve.
The Old Way: RAG and Vector Databases
RAG: The Industry Standard for Two Years
The AI industry standardized on Retrieval-Augmented Generation: chop documents into chunks, convert each to a vector (list of numbers representing meaning), store in a vector database, then retrieve similar chunks when answering questions. It works but forces the model to re-derive connections every query, starting from zero each time.
1
Chop documents into chunks
2
Convert each chunk to vector (list of numbers)
3
Store in vector database
4
On query: retrieve similar chunks
5
Hand to model (no memory of prior work)
RAG workflow: thinking happens at question time
The Problem: No Real Memory
Every query starts fresh. The model receives disconnected snippets and must re-work the same logical connections it solved an hour ago and the hour before. There is no persistent understanding built up over time.
The New Way: LLM Wiki and OKF
Andrej Karpathy's LLM Wiki Concept
In April, Karpathy (OpenAI co-founder, former Tesla AI head) posted the LLM Wiki to GitHub: instead of re-deriving everything on each query, build knowledge once into a folder of plain text files that link to each other. The AI writes and maintains the wiki; humans bring new material and ask questions. Karpathy's framing: Obsidian is the IDE, the LLM is the programmer, the wiki is the code base.
Google Formalizes It: Open Knowledge Format (OKF)
On June 12, Google Cloud published OKF as an official spec. A bundle is a folder; each file is one concept (table, metric, playbook, etc.); the file path is its name; links form a graph. Two special files: one listing contents, one logging changes. One hard rule: every file must declare its type in one field. The spec orders readers to forgive unknown fields, broken links, and unparseable files.
1
Bundle = folder
2
Each file = one concept
3
File path = name
4
Links between files = graph
5
One required field: type declaration
6
Readers must forgive errors
OKF spec: minimal, permissive, text-based
Why the Folder Wins: Three Reasons
Timing: Work Happens Once, Not Per Query
RAG does thinking at question time. The wiki does it once up front when the bundle is built—connecting concepts, flagging contradictions, writing summaries. You pay that cost a single time, then just read the finished answer. No repeated computation.
RAG
Thinking at every query
OKF Wiki
Thinking once, reading many times
Where the work happens
Scalability: Table of Contents Prevents Choking
A model can only hold so much in its head at once. With thousands of files, each folder carries a short table of contents. The model reads that first, picks the one file it needs, and skips the other 9,000. It never chokes on the whole library.
Portability: Plain Text, No Infrastructure
It is only text. It lives in Git exactly like code—you can diff it, review in pull requests, zip it, and hand it to a model running offline on a laptop. No database, server, or API key needed. If you can open a file, you can use it.
What OKF Is Not
Not Competing with MCP
MCP is the pipe that moves data around live. OKF is the cargo that moves through it. They serve different purposes and can coexist.
Not an SEO Trick
Nothing in OKF helps a search engine find you. It is private knowledge for your own agents, not public-facing content.
The Real Catches: Three Problems
Catch One: Staleness on Shared Teams
The spec has no mechanism to keep anything current. A timestamp field exists, 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.
Week 1
Bundle created, fresh and accurate
Week 2-3
Team adds new material
Week 4
Updates slow, maintenance abandoned
Month 2+
Knowledge stale, agent answers from outdated info
How shared team folders decay over time
Catch Two: AI Librarians Botch Markdown
The whole idea rests on AI being a tireless, accurate librarian. In practice, language models are bad at writing clean markdown at scale. They botch formatting, mangle headers, and invent links to files that were never created. Google's fix: change the spec to order every reader to forgive the mess. That permissive rule is damage control with a nicer name.
Catch Three: Semantic Ambiguity—No Shared Language
The format standardizes the container, not the meaning. The one required field is a free-form label. Your team writes 'BigQuery table,' mine writes 'table,' someone else writes 'relational asset.' They are all valid, but each speaks a different language. You can ship the box anywhere. Agreeing on what is inside is still on you. No format can hand you that.
1
Team A labels
BigQuery table
2
Team B labels
table
3
Team C labels
relational asset
Same concept, different labels—no shared language
The Invisible Moat
Organization Matters More Than Format
An agent is basically just a folder of markdown files. Anyone can write markdown. The skill is in how the folder is organized: what is locked versus what the AI can rewrite, what stops it drifting over a long run. The moat is invisible. Two folders can look identical. One holds up in production while the other slowly rots. You cannot tell which is which by reading the files. No format can hand you that.
The Business Layer: Google's Strategy
OKF Came from BigQuery, Not AI Lab
OKF did not come out of Google's AI lab—it came from the BigQuery team. Every sample data set ships on BigQuery. The reference tool that writes the bundles runs on Gemini. The easiest place to pour a finished bundle is Google's own knowledge product, which they just renamed for exactly this moment. This is strategic positioning, not pure open-source altruism.
Will It Stick?
Adoption Uncertainty
The day OKF launched, almost nobody outside Google was using it. A standard with one user is just a suggestion. It could easily be the next Google project added to their graveyard. However, the idea underneath it has already won: the most overfunded 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. Whatever happens to the format, that part is not going back in the box.
Worth quoting
"Just use a folder of text files. And it worked better."
— Narrator, summarizing Google's approach, at [0:00]
"Obsidian is the IDE, the LLM is the programmer, the wiki is the code base."
— Andrej Karpathy, at [2:03]
"An agent is basically just a folder of markdown files. The skill is in how the folder is organized."
— Developer (quoted), at [6:38]
Made with Glimpse by Wozart
glimpse.wozart.com/v/fotjzz3k
Share this infographic

More like this