Knowledge Should Not Be Gated | Formaly

All articles<br>Essay/ Jul 1, 2026<br>Knowledge Should Not Be Gated<br>For years we locked context behind vector databases, SDKs, and proprietary catalogs. Then we noticed LLMs are happiest reading plain markdown. Google's Open Knowledge Format is the moment that realization became a standard.<br>8 min read

Arindam Majumder<br>Formaly

Share this article<br>HN

For most of the last few years, giving an AI system knowledge meant building infrastructure.

You wanted your agent to know things about your business, your data, your decisions. So you reached for the standard playbook. Chunk the documents. Pick an embedding model. Stand up a vector database. Tune the retrieval. Wrap it in an SDK. Maybe, if you were feeling ambitious, build a graph on top of it all.

By the time you were done, your company's knowledge was no longer a thing you could read. It was a thing you queried, through a pipeline, behind a service, owned by whichever framework you happened to pick.

I want to argue something that has been quietly true for a while and is now becoming obvious: that whole approach gated knowledge that never needed gating. And the correction is almost embarrassingly simple. It is markdown.

The era of locking knowledge behind tooling

RAG was a good idea. I am not here to dunk on it.

When context windows were small and models were expensive, retrieval-augmented generation solved a real problem. You could not fit your whole knowledge base into a prompt, so you retrieved the relevant slice and fed only that. Graph RAG pushed it further, building a structured graph of entities and relationships so the model could reason across connections instead of isolated chunks.

These techniques work. But look at what they cost.

To put knowledge into a RAG system, you have to 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.

And 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 itself ends up trapped behind whichever surface created it, in a format the next tool cannot read without a translator.

That is the gate. Not a paywall, exactly. A format wall. Your own knowledge, made unreadable by the tools meant to make it useful.

The thing we kept rediscovering

While all of that infrastructure was being built, something quieter was happening in the way people actually worked with agents day to day.

They started writing markdown.

If you have used Claude Code or Codex, you have written a CLAUDE.md or an 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 for how something should look. MEMORY.md for what an agent should remember between runs. "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 is exactly enough scaffolding for a model to navigate and exactly little enough that a human can read the same file and understand it instantly.

We spent years trying to compress knowledge into something machines could query. The machines, as it turns out, would rather just read.

Karpathy said the quiet part

Andrej Karpathy put a name on this with his LLM Wiki pattern, and it crystallized the whole thing for me.

The idea is a three-layer setup, all in plain files. A sources/ directory of raw material the model treats as immutable and never edits. A wiki/ of markdown pages the model generates and owns: summaries, concept pages, entity pages, a synthesis that ties them together. And a schema file, the CLAUDE.md or AGENTS.md, that tells the agent how to maintain the whole thing: how pages are structured, how new sources get ingested, how cross-references stay current.

The insight underneath it is the one that reframes RAG entirely. Karpathy's line is worth quoting:

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.

Personal wikis always died for the same reason. Keeping them current was tedious, and humans hate...