Stop Gating Knowledge Behind RAG Pipelines—Just Use Markdown

For the past few years, giving an AI system knowledge meant building infrastructure. Chunk documents. Pick an embedding model. Stand up a vector database. Tune retrieval. Wrap it in an SDK. Maybe build a graph on top. By the time you were done, your company's knowledge was no longer something you could read—it was something you queried through a pipeline, behind a service, owned by whichever framework you happened to pick.

That whole approach gated knowledge that never needed gating. The correction is almost embarrassingly simple: markdown.

RAG was a good idea—but it came with a cost

Retrieval-augmented generation solved a real problem when context windows were small and models were expensive. Graph RAG pushed it further. These techniques work. But look at what they cost. To put knowledge into a RAG system, you transform it into a shape only the system understands. Your documents become embeddings. Your relationships become edges in a database. The knowledge stops being human-readable the moment it enters the pipeline. If you want to see what your agent actually "knows," you cannot just open a file—you have to run a query against the same machinery that locked it away.

Every team rebuilds this from scratch. Every agent builder solves the same context-assembly problem. Every catalog vendor reinvents the same data models. The knowledge ends up trapped behind whichever surface created it, in a format the next tool cannot read without a translator. That's the gate: not a paywall, but a format wall.

The pattern everyone kept rediscovering

While all that infrastructure was being built, something quieter was happening. People started writing markdown. If you've used Claude Code or Codex, you've written a CLAUDE.md or AGENTS.md without thinking of it as architecture. You wrote down how your project works, what conventions to follow, what not to touch—and the agent got better. No embeddings. No vector store. Just a file the model reads at the top of every session.

The pattern kept showing up under different names: Obsidian vaults full of linked notes, DESIGN.md, MEMORY.md, "metadata as code" repositories. Every one of these is the same instinct: write the knowledge down as plain text, link the pieces together, and let the model read it directly. It turns out the format LLMs are genuinely, reliably good at is the one we were treating as too primitive to bother standardizing. Markdown has structure without ceremony—headings, lists, links, a little frontmatter. It's exactly enough scaffolding for a model to navigate and exactly little enough that a human can read the same file and understand it instantly.

Karpathy's LLM Wiki pattern

Andrej Karpathy put a name on this with his LLM Wiki pattern. The idea is a three-layer setup, all in plain files. A sources/ directory of raw material the model treats as immutable. A wiki/ of markdown pages the model generates and owns—summaries, concept pages, entity pages. And a schema file (CLAUDE.md or AGENTS.md) that tells the agent how to maintain the whole thing.

The insight: LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass. The bookkeeping that causes humans to abandon personal wikis is exactly what LLMs are good at. So the trade flips. RAG rediscovers your knowledge from scratch on every single query. A wiki compiles the knowledge once and keeps it current. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you have fed it. And it's all just files—open them, edit them, put them in git. The knowledge is not gated behind anything.

Google's Open Knowledge Format

In June, Google Cloud introduced the Open Knowledge Format (OKF), currently at version 0.1. It takes the markdown-wiki instinct everyone was already acting on and turns it into a vendor-neutral standard. An OKF bundle is a directory of markdown files, each file representing one concept: a dataset, a table, a metric, a runbook, an API. They sit in a sensible hierarchy with YAML frontmatter for structured fields like type, title, description, resource, tags, and timestamp.

Concepts link to each other with normal markdown links—a foreign key in your orders table just points at [customers](/tables/customers.md). Those links turn the directory into a graph of relationships, richer than the parent-child nesting the folders imply. You get the graph RAG benefit without standing up a graph database. The links are the graph.

The spec requires exactly one field: type. Everything else is a convention you can follow or ignore. That's the entire model. No embeddings. No vector store. No pipeline. Just files.