Your agent is smart. Your company knowledge is scattered. Here is the small, plain-text standard that tries to fix the gap.
The brilliant intern with no map
Imagine hiring the sharpest intern you have ever met. Day one, you ask: “What counts as an active customer in our reports?”
They freeze. Not because they are slow, but because the answer lives in a spreadsheet note, a five-year-old wiki page, a code comment, and one senior colleague’s memory.
That intern is your AI agent. Models keep getting better, yet agents still stumble on one boring thing: knowing what your organization actually means. Google Cloud published a lightweight open specification for exactly this problem in June 2026, on the Google Cloud blog and in its open-source GitHub organization. It is called the Open Knowledge Format (OKF), and this post covers the current version, v0.2.
Why smart agents still get it wrong
Before an agent can do useful work, it must gather context: definitions, table meanings, business rules, “how we do things here.” In most companies that context is spread across wikis, READMEs, data catalogs, specs and chat threads, each in its own shape.
Every new agent or tool needs a custom connection to every source. That is slow, fragile, and gets worse as you add more tools. Better prompts will not fix it. Better organized knowledge will.
Quick detour: what is RAG?
RAG stands for Retrieval-Augmented Generation. Think of an open-book exam.
- Ask: you pose a question.
- Retrieve: the system searches your documents and pulls out the most relevant snippets.
- Generate: the AI reads those snippets and writes an answer grounded in them.
RAG is great because the model does not need to memorize your data. But it has a catch: retrieval is only as good as the material it searches. If your documents are messy, outdated or contradictory, RAG happily retrieves messy, outdated, contradictory snippets.
That is where OKF fits. RAG is the search step. OKF is about how the knowledge is written and packaged in the first place. They are teammates, not rivals.
So what is OKF?
OKF is a vendor-neutral, open specification for representing knowledge as a folder of Markdown files, each with a little YAML metadata at the top. It is a format, not a product. There is no platform to sign up for and no lock-in. If you can open a text file, you can read OKF.
- Just Markdown: readable in any editor, on GitHub, or in a static viewer.
- Just files: store them in Git, version them, mount them anywhere.
- Just one required field: every page needs a type. Fields such as title, description, resource and tags are recommended, not mandatory. You do not have to learn a big schema to start.
What one OKF page looks like
Each page describes one concept. This example is original, written for this post.
A human can read this in ten seconds, and an agent can read the exact same file. Ordinary Markdown links let an agent walk from one concept to the next, like a lightweight knowledge graph with no database. The spec recommends links that start with / and are relative to the bundle root, because they keep working when files move. A folder can hold an index.md that acts as a table of contents, and a log.md can appear at any level to record changes to that part of the bundle.
Many scattered sources become one readable bundle that every agent, pipeline and person can use.
The real story in v0.2: knowledge you can trust
Portability is nice. Trust is the reason a data leader should care.
Once agents help write and maintain your knowledge base, four questions get urgent: Where did this definition come from? Who confirmed it? Is it still current? Was this number produced by the approved calculation? Version 0.2 makes each of them answerable from a page’s metadata:
- Provenance: pages can list their sources, with per-source signals about how credible each one is.
- Trust: a page records what generated it and who verified it. From that, a reader can work out a trust tier: unverified, machine-confirmed, or human-reviewed. A machine-written draft is easy to tell apart from a fact a person has signed off on.
- Lifecycle: status and a stale_after date tell readers when to stop relying on a page.
- Attested Computation: a new concept type for numbers that come from a sanctioned calculation rather than someone’s best guess.
That turns OKF from a file-format story into a governance story. Your wiki can say what it knows. An OKF bundle can also say how sure it is.
OKF vs RAG vs MCP: who does what?
These three get mixed up constantly. They solve different problems:
| Piece | Its job | Simple analogy |
|---|---|---|
| OKF | How knowledge is written and packaged | A well-organized library shelf |
| RAG | How relevant pieces are found and fed to a model | The librarian who fetches the right pages |
| MCP | How agents connect to tools and live systems | The phone line to other departments |
OKF does not replace RAG or MCP. It gives them cleaner material to work with. It is reasonable to expect a search system to do better on structured, linked, clearly labeled pages than on a pile of raw exports, but that is an expectation, not a benchmarked result. Test it on your own content.
What you get that a wiki cannot give you
1. No vendor lock-in
Your knowledge is plain files in your own repository. Change AI tools and your content comes with you.
2. One source, two audiences
You stop maintaining human wikis and separate machine prompts. One set of pages serves both, which reduces documentation drift.
3. Governance with tools you already use
Because knowledge lives as files in Git, you can add link checkers, validators and pull-request reviews to your existing CI/CD pipeline before an update goes live.
Where this lands in real enterprise data work
The pattern is familiar to anyone who has worked on analytics at scale. The same metric is defined slightly differently in two BI tools. A semantic layer captures the “official” logic, but nobody documents why. A data catalog holds descriptions that were accurate two reorganizations ago. Analysts learn to ask a colleague instead of trusting the documentation.
Now add AI agents to that picture. They will read all of it, confidently, and they cannot tell which version is right. This is why definition drift matters more, not less, in the agent era. A small, versioned, reviewable set of pages for your most-argued-about definitions is a low-cost way to give people and agents one place to check first.
Try it in an afternoon
- Pick one domain: sales metrics, or developer onboarding.
- Write 10 to 20 concept pages: one idea per file, a type on each, and links between related pages.
- Add an index.md: a friendly map of the folder.
- Test with real questions: point your agent or RAG setup at the folder and see whether answers improve.
If it helps, expand. If not, you have lost an afternoon and gained tidier documentation.
Honest limits, and when not to use it
- OKF is young and evolving. Verify syntax details against the official spec before you build on them.
- It is not a database, search engine or security layer. A neat format cannot fix inaccurate content.
- If you already run a governed catalog with enforced lineage, OKF is best seen as an export target, a portable way to hand that knowledge to agents, not a replacement for the catalog.
- It is independent of the Open Knowledge Foundation (OKFN), which shares the acronym.
The takeaway
The next leap in useful AI may not come from a bigger model. It may come from something almost embarrassingly simple: writing down what you know, clearly, with a record of where it came from, in a format everyone can read. OKF bets on exactly that, and the bet costs you a folder of text files.
Further reading: the OKF v0.2 specification and samples are in Google Cloud’s open-source repository: GoogleCloudPlatform/open-knowledge-format. See also the Google Cloud Blog post “How the Open Knowledge Format can improve data sharing.”
