Video summary

Google's OKF: Why a Folder Beats the Vector Database

Main summary

Key takeaways

Technology

Core claim / thesis

The AI industry has long relied on RAG (Retrieval-Augmented Generation)—chunking documents, embedding them into vectors, and storing them in a vector database.

But Google (via a respected AI figure’s idea) argues that a simpler approach can work better: a “folder” of linked text files. This idea has been formalized as a standard: Open Knowledge Format (OKF).

Problem with traditional RAG

1. No persistent memory

Each query starts “from zero,” so the model receives disconnected snippets and must re-derive connections every time.

2. Knowledge is scattered across systems

Definitions might live in one database, logic in pipelines, and so on—meaning retrieval doesn’t fully restore the connected structure of real knowledge.

Karpathy’s “LLM Wiki” concept (reverses RAG)

Instead of doing “thinking” at question time, the idea is to build knowledge once up front into a folder that behaves like a living encyclopedia / codebase.

  • The AI maintains the wiki: summarizing, cross-referencing, filing, and upkeep.
  • Humans provide new material and good questions.
  • Analogy: “Obsidian is the IDE, the LLM is the programmer, the wiki is the code base.”
    • The human owns the folder
    • The AI does the work maintaining it

Google’s OKF standard (Open Knowledge Format)

OKF was published as a formal spec by Google Cloud (June 12) based on the community idea.

“Small spec” (key concepts)

  • A bundle = a folder
  • Each file = one concept (e.g., table, metric, playbook)
  • A file’s path names it
  • Links form a graph
  • Two special filenames:
    • one for a folder index/listing contents
    • one for logging changes

One hard rule

Every file must declare its type in a required field.

Permissive compatibility rules

Tool readers should forgive:

  • unknown fields
  • broken links
  • files they can’t parse

The goal is to reduce brittleness for enterprise usage.

Why the folder approach “wins” (as argued in the video)

  1. Time of work

    • RAG computes relevance at query time
    • OKF/LLM-wiki computes structure at build time (once), so queries just read finished material.

  2. Model efficiency / scaling

    • A folder can include a table of contents
    • This lets the model select only the needed file(s) instead of processing thousands of chunks.

  3. Plain text portability

    • It’s text-only and lives in Git like code
    • Easy diff/review/PR workflows
    • Can be zipped and read offline
    • Doesn’t require a database/API key just to interpret

Two important mix-ups / limitations

1. Not competing with MCP

  • MCP is described as a data pipe for moving information live.
  • OKF is the cargo/container—not an SEO/search trick—aimed at private knowledge for agents.

2. No built-in freshness mechanism

  • The format may include timestamps, but it doesn’t automatically update itself.
  • Shared folders can go stale quickly if nobody maintains them.

“Messy librarian” problem (formatting quality)

LLMs can produce messy markdown at scale, such as:

  • bad formatting
  • mangled headers
  • invented links

Google “fixes” this not by improving the AI, but by making the spec’s reader behavior intentionally permissive to tolerate mess.

Deep limitation: “container vs meaning”

OKF standardizes the structure/container, but not the semantic labels.

  • Even though there’s a required type field, it’s free-form
  • Teams can label the same thing differently:
    • “BigQuery table” vs “table” vs “relational asset”

So interoperability of meaning still requires human agreement/process.

Developer takeaway (agent framing)

  • An agent is basically a folder of markdown files.
  • The real “moat” is:
    • how it’s organized
    • what content the AI can rewrite vs what must be locked
    • how drift/staleness is prevented

Google’s motivation / ecosystem angle

OKF is tied to Google internals:

  • Originated with the BigQuery team
  • Sample datasets ship on BigQuery
  • A reference bundle tool runs on Gemini
  • The easiest place to generate bundles is a Google knowledge product (noted as a renamed product for this moment)

The video also suggests this aligns with prior Google model/product direction (e.g., “Gemma 4” mentioned).

Will it stick? Uncertainty

  • At launch, few outsiders were using it.
  • A standard with one vendor may fade without broader adoption.
  • Still, the underlying idea—a folder of text files as memory—is positioned as a strong winner compared to exotic vector-db infrastructure.

Main speakers / sources mentioned

  • Andrej Karpathy (co-founder of OpenAI; former Tesla head of AI)
  • Google Cloud / BigQuery team (plus Gemini referenced as the bundle-writing environment/tool)

Original video