Every few months a new acronym shows up promising to fix how AI systems understand your data. Most of them quietly disappear. OKF might be the exception, and not because it’s clever — because it’s almost aggressively simple.
What Open Knowledge Format actually is
Google Cloud’s Open Knowledge Format is a specification, not a product. It defines a plain, portable way to represent organisational knowledge — datasets, metrics, APIs, runbooks, tables, playbooks — as a directory of markdown files with a small block of YAML frontmatter at the top of each one. Google calls the individual files “OKF documents” and a folder of them an “OKF bundle.” Think of documents as the trees and the bundle as the forest.
Structurally, there isn’t much to it. Each concept gets its own file. The file path is its identity. The frontmatter carries a handful of queryable fields — type, title, description, resource, tags, and timestamp — and everything below that is ordinary markdown, with concepts linking to each other the same way any markdown file links to another. The entire spec fits on a single page, which is unusual for something Google is positioning as infrastructure.
OKF formalises a pattern that’s already been circulating informally under the name “LLM wikis” — markdown libraries an AI agent can read, update, and maintain on its own. Google didn’t invent the idea so much as write down the rules everyone was already half-following with AGENTS.md files, llms.txt, and Obsidian vaults repurposed for agent context.
How it can actually be used
The point of OKF is that it separates who writes knowledge from who reads it. Because a bundle is just files and folders, several different producers and consumers can plug into the same knowledge base without ever coordinating with each other.
Producing bundles
Humans can hand-author documents in a text editor. Agents built on Google ADK, LangChain, or a custom framework can generate them. Export pipelines from existing catalogs, or scripts that walk a database or a BigQuery dataset, can draft one concept file per table automatically.
Consuming bundles
A static file server can host one. A knowledge tool such as Obsidian, Notion, or MkDocs can render one. An LLM can load the files straight into context. A search index or a graph viewer can browse the links between concepts.
Living documentation
Because agents can write back to the same files they read, a bundle can function as a living wiki — one that an AI system updates as it learns, rather than one that quietly goes stale the way most internal docs do.
Reference tooling
Google has published a reference enrichment agent for BigQuery and a static HTML visualiser, plus sample bundles covering GA4 e-commerce data, Stack Overflow, and Bitcoin datasets, so teams have something concrete to fork rather than building from the spec alone.
In practice, a consultant could hand a client an OKF bundle as a project deliverable instead of a proprietary export. A platform team could point Claude Code, or any file-reading agent, straight at a bundle directory and let it follow the cross-links on its own. Teams could merge, fork, and share knowledge bases the way they already share code in git, because a bundle is, structurally, just another folder in a repo.
The cost factor
OKF itself costs nothing. It’s an open specification published on GitHub, and reading or writing markdown files with YAML frontmatter requires no proprietary account, SDK, or licence. That’s a deliberate design choice on Google’s part — the value is supposed to come from adoption, not ownership.
Where cost actually enters the picture is if you plug OKF into Google Cloud’s Knowledge Catalog (the product formerly known as Dataplex, now repositioned as an “always-on context engine” for agents). Knowledge Catalog can natively ingest OKF bundles, and its pricing is pay-as-you-go:
| Layer | Typical cost |
|---|---|
| The OKF spec and reference tools | Free — open source, no account required |
| Basic data organisation in Knowledge Catalog | Free (lake, zone, asset setup, and policy propagation) |
| Standard metadata processing | Free tier of roughly 100 DCU-hours per month, then usage-based |
| Discovery scans, scheduled ingestion, managed connectors | Billed through the underlying compute — GCS, Spark, BigQuery, Dataflow |
| Gemini-powered enrichment and metadata generation | Billed separately through Gemini in BigQuery / Gemini Code Assist |
So the honest summary is: adopting the format costs nothing, and you can run OKF entirely outside Google’s ecosystem with a static file server and a git repo. Cost only shows up if you want Google’s managed cataloguing and AI enrichment layered on top, and even then there’s a genuine free tier before usage-based billing kicks in.
Is it worth replacing anything you already use?
This is the part worth being careful about, because a lot of the early commentary jumped straight to “this replaces Notion, Obsidian, or Confluence.” It doesn’t, at least not directly — and that’s actually the more interesting point.
| Tool | What it actually does | Relationship to OKF |
|---|---|---|
| Notion / Confluence | Hosted wiki platforms with UI, permissions, and search built in | OKF is a file format, not a platform — these tools could add OKF import/export rather than being replaced by it |
| Obsidian | A markdown-based personal knowledge vault | Closest existing analogue — an Obsidian vault can already be structured as a valid OKF bundle |
| Proprietary data catalogs (Collibra, Unity Catalog, etc.) | Vendor-specific metadata models and APIs | OKF offers a neutral export/interchange layer between them, not a like-for-like replacement |
| Dataplex / Knowledge Catalog | Google’s managed governance and context layer | Consumes OKF natively — complementary, not competing |
The realistic framing is that OKF is a portability layer, not a destination. It doesn’t compete with the tools you write and browse documentation in — it gives those tools a common file format to exchange, so the same knowledge base can be authored in Obsidian, versioned in git, browsed with a static viewer, and read directly by an AI agent, without four separate exports and four separate data models.
What to consider before adopting it
It’s genuinely v0.1
Google has been explicit that this is a starting point, not a finished standard, and it’s already shipped a second version within six weeks of launch. Expect the spec to keep moving.
Simplicity is the whole pitch
If your team needs rich permissions, workflow, or approval chains, OKF alone won’t give you that — it deliberately leaves integration and tooling to everyone else.
Adoption is still early
Value compounds as more producers and consumers speak the format. Right now that’s mostly Google’s own reference tools and early adopters experimenting with it.
You may already be close
Any team already keeping documentation as markdown in a git repo — including AGENTS.md-style setups — is one YAML frontmatter block away from being OKF-conformant.
OKF is worth a weekend of experimentation for any team already leaning on AI agents that need context — not because it’s a new tool to install, but because it costs nothing to try and there’s a real chance it becomes the format everyone else’s tools learn to speak.
I cover new AI and developer tooling releases like this one regularly on ToolTechSavvy — what they actually do, what they cost, and whether they’re worth your time.
Read more at ToolTechSavvy.com
