Folders vs Vectors: How to Give AI Knowledge

An AI model is brilliant and ignorant at the same time: it can reason beautifully, but it does not know your things — your tables, your docs, your decisions. So the central question of building useful AI is: how do you hand it your knowledge?

There are two great families of answers, and this course is about both — from the very fundamentals of what each one is, all the way to combining them into one architecture. You can arrive knowing nothing about either.

Picture giving a new colleague everything they need to do a job. You could hand them a well-organised binder — labelled sections, a table of contents, cross-references — and let them flip to what they need. Or you could give them a magic index that, for any question, instantly surfaces the most relevant paragraphs from a giant pile of documents, even if they used different words than the documents do.

Those are the two approaches, and they are not rivals so much as different tools:

• The binder is the folder way — structured, curated, navigable. Its modern form for AI is Google's Open Knowledge Format (OKF).
• The magic index is the vector way — fuzzy, semantic, scalable. Its form is Retrieval-Augmented Generation (RAG).

Before comparing them, let's be sure what each is, because the words hide simple ideas.

You already know what a folder is: files inside folders, with names, that you can open and read, and that can link to each other. That is the whole idea — and it turns out to be a surprisingly good way to store knowledge for an AI, not just for a person.

Here is knowledge stored as a folder. Click through it — open files, follow the structure:

# Schema
| Column        | Type   | Description                         |
|---------------|--------|-------------------------------------|
| order_id      | STRING | Globally unique order id.           |
| customer_id   | STRING | FK → [customers](customers.md).     |
| amount_eur    | FLOAT  | Order total, in euros.              |

# Joins
Joined with [customers](customers.md) on customer_id.

Notice three things, because they are the whole point:

• It is human-readable. Every file is just text you can open and understand. Nothing is hidden in a database.
• It has structure. Folders group things; a file has a type and named fields; files link to each other (orders → customers). Those links form a little map of how things relate.
• An agent can navigate it. It can read a file, follow a link to the next, and — importantly — write to it: fix a description, add a cross-reference. Files are as easy for a model to edit as for a human.

Start with one tiny idea. Some different words mean almost the same thing — cat, kitten, feline — and so do car, vehicle, automobile. A computer that understood meaning should treat the words in each group as basically the same. Press the button and watch it do exactly that:

Sorted by letters, "cat" lands next to "car" — nonsense. Sorted by meaning, the words that mean the same thing snap into the same place. That is the whole trick. Now zoom out: do it for every word at once and you get a giant map, where each word is a little house and similar meanings are near neighbours. Tap a word to see its closest friends:

Nobody told the computer what a cat is. It just read a mountain of text, noticed that "cat," "dog," and "tiger" tend to show up in similar sentences, and quietly placed their houses close together. That map of meaning is what "vectors" are.

Now the grown-up name. An embedding turns any piece of text into that house's address: a long list of numbers, a point in space. Similar meanings get nearby addresses, even when they share no words at all.

And here is where it gets genuinely wild. Because every word is now a point, the relationships between meanings become directions you can add and subtract. Take the point for "king", apply the very same step that turns "man" into "woman", and you land on... "queen." No one programmed that — it falls straight out of the geometry. Play with it: change the words, use a preset, and watch the two arrows stay parallel:

That parallel-arrow trick — man is to woman as king is to queen — is the famous result that first made people realise embeddings had captured real meaning, not just word-counting. Distance means similarity; direction means relationship. Real embeddings do this across hundreds of these number-dimensions at once; we flattened it to two so you can see it move.

And the magic follows for free: to search by meaning instead of spelling, you just find the nearest houses. Ask "how much time off do I get" and it walks straight to "annual leave" — no matching words required. Try it:

So what is a vector database? Just a place that stores millions of these houses and, the instant you describe what you want, points to the closest ones — like a librarian who, before you even finish your sentence, hands you the three most relevant books without either of you knowing a single title. Feed it your documents, wrap a model that answers from the nearest ones, and you have RAG — covered end to end in RAG in Production.

In June 2026, Google Cloud introduced the Open Knowledge Format to make the folder approach a real standard. It is deliberately, almost stubbornly, simple: a directory of markdown files, each with a little YAML frontmatter, plus a few conventions so different tools can read the same bundle.

The details worth knowing:

• The only required field is type. Everything else — what types exist, what fields and sections a file has — is up to you. The spec defines how tools interoperate, not what your knowledge must look like. The whole v0.1 spec fits on a single page.
• Cross-links are the graph. Ordinary markdown links between files create a web of relationships "richer than the file-system hierarchy," in Google's words. Optional index.md files let an agent discover a folder gradually; an optional log.md records changes.
• It is "format, not platform." A bundle is just files — readable in any editor, renderable on GitHub, shippable as a tarball, stored in git next to the code it describes. No SDK, no proprietary database, not tied to any cloud or model.

Google shipped it with working pieces: an enrichment agent that walks BigQuery datasets and drafts OKF documents (schemas, join paths, citations), a self-contained HTML visualizer that renders a bundle as an interactive graph, and sample bundles over real public datasets (GA4 e-commerce, Stack Overflow, Bitcoin). It has since been wired into Google Cloud's Knowledge Catalog to serve knowledge to agents.

Neither wins outright; they are good at different things.

The clearest way to feel the trade-off is to give each a job. Pick a scenario and see which fits — sometimes it's one, sometimes both:

The pattern you'll notice: vectors are for finding things by meaning; folders are for knowing things precisely. Ask "which tickets are like this one?" and you want vectors. Ask "how do these two tables join?" and you want the folder's explicit link.

Here is the punchline: you do not choose. The strongest design layers them — and OKF was explicitly built to allow it. Google's own note is that an OKF bundle can be embedded and indexed for vector search, while still preserving the structured relationships "that vector similarity alone might miss."

So the ultimate architecture uses each for what it's best at:

  question ─► embed ─► VECTOR search over the folder's files
                              │  finds the right concept, by meaning ("orders")
                              ▼
                       open that OKF file ─► follow its cross-links (FOLDER)
                              │  exact schema · joins · definitions
                              ▼
                       grounded answer, citing the actual files

In words: the vector index solves the hard problem of finding the right entry point when the question is phrased in any of a thousand ways. Then the folder takes over, giving the agent the exact schema, the precise join, the cross-linked neighbours — the structured truth a fuzzy match can't guarantee. An agent runs this as a loop: search to find the door, then read and follow links to gather what's behind it (that agentic loop is the ReAct pattern).

Sources: Sam McVeety & Amir Hormati, “How the Open Knowledge Format can improve data sharing,” Google Cloud (June 2026), and the OKF Knowledge Catalog repo; Andrej Karpathy, the “LLM wiki” note. The vector/RAG half is covered in depth in this track's RAG in Production and RAG & Tool Use.