Every team building AI agents eventually hits the same wall. The model is capable enough — it can write SQL, draft a workflow, summarize a document — but it doesn’t know which table holds “active users,” why the finance team’s revenue number excludes refunds, or that the checkout API changed last sprint. That knowledge exists somewhere. It’s just scattered across a wiki, a Slack thread, a senior engineer’s head, and a comment in a repo nobody opens anymore.
- What the Open Knowledge Format actually is
- Why Google built it: the fragmented-context problem
- The pattern it formalizes: Karpathy’s “LLM wiki”
- How OKF works, structurally
- Bundle structure
- The two reserved filenames
- Cross-linking turns the tree into a graph
- Conformance is deliberately loose
- Worked example: an OKF bundle for a UiPath automation program
- OKF vs. RAG: different tools for different knowledge
- OKF vs. llms.txt vs. AGENTS.md/CLAUDE.md
- What ships alongside the v0.1 spec
- Limitations and open risks
- What this means for RPA and agentic automation teams
- Key Takeaways
- FAQs
- References
On June 12, 2026, Google Cloud’s Data Cloud team — led by Sam McVeety and Amir Hormati — published a proposed fix: the Open Knowledge Format (OKF), an open, vendor-neutral specification for packaging organizational knowledge so both humans and AI agents can read it without translation.[^1] It’s not a database, not a new model, and not a Google product you sign up for. It’s a file format — plain markdown with YAML frontmatter — and that plainness is the entire pitch.
This guide covers what OKF actually is, how the v0.1 spec works down to the file structure, how it stacks up against RAG and adjacent conventions like llms.txt and AGENTS.md, and what it means if you’re building or documenting automation programs on UiPath, LangGraph, or any agent stack in between.
What the Open Knowledge Format actually is
OKF represents knowledge as a bundle: a directory of markdown files, each one a self-contained unit called a concept. A concept can be anything worth capturing — a database table, a metric definition, an incident runbook, an API endpoint, a business process. Each concept file has two parts: a short YAML frontmatter block with structured metadata, and a markdown body with the actual explanation, schema, or steps.
Here’s the entire idea in one file, taken directly from the v0.1 spec:
---
type: BigQuery Table
title: Customer Orders
description: One row per completed customer order across all channels.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, orders, revenue]
timestamp: 2026-05-28T14:30:00Z
---
# Schema
| Column | Type | Description |
|---------------|-----------|-------------------------------------------|
| `order_id` | STRING | Globally unique order identifier. |
| `customer_id` | STRING | Foreign key into [customers](/tables/customers.md). |
# Joins
Joined with [customers](/tables/customers.md) on `customer_id`.
Only one field is required: type. Everything else — title, description, resource, tags, timestamp, or any custom key a producer wants to add — is optional. Google’s stated design goal was to standardize the smallest possible set of conventions needed for interoperability, and leave everything else to the people actually writing the knowledge.[^2]
Three properties make this different from “just another docs folder”:
- It’s just files. No SDK, no API, no runtime. If a tool can read a directory of
.mdfiles, it can consume an OKF bundle. - It’s diffable and versionable. Because a bundle is plain text, it lives naturally in Git — pull requests, code review, and blame history apply to your knowledge the same way they apply to your code.
- Producers and consumers are decoupled. A human can hand-write a concept file. A pipeline can auto-generate one from a database schema. An LLM can draft one and a different LLM, from a different vendor, can consume it — because the contract is the file format, not an integration.
Why Google built it: the fragmented-context problem
Google’s announcement frames the motivation plainly: in most organizations, the knowledge an agent needs to be useful — schema definitions, business logic behind a metric, join paths between two systems, the reason an API was deprecated — is spread across metadata catalogs with their own APIs, wikis and shared drives, code comments and docstrings, and “the heads of a few senior engineers.”[^1]
When an agent needs to answer something like “how do we compute weekly active users from the event stream,” it has to reassemble that answer from scattered, mutually incompatible surfaces — every single time, for every single agent, at every single company independently solving the exact same problem. Google’s bet is that the fix isn’t a better retrieval pipeline or another vendor catalog. It’s a shared format that lets knowledge itself become portable.
The pattern it formalizes: Karpathy’s “LLM wiki”
OKF didn’t appear from nowhere. It’s an explicit formalization of a pattern AI researcher Andrej Karpathy described in a widely-circulated gist: instead of having a model re-search the same raw documents for the same facts on every run, give it a persistent markdown wiki it reads from and writes back into, the way a human maintains a personal knowledge base — except the model doesn’t get bored or forget to fix a stale cross-reference.[^3] Karpathy’s framing, quoted directly in Google’s post: “LLMs don’t get bored, don’t forget to update a cross-reference, and can touch 15 files in one pass.”
That pattern had already been reinvented independently and informally — Obsidian vaults wired to coding agents, the AGENTS.md/CLAUDE.md family of repo convention files, ad hoc index.md/log.md pairs inside data teams’ “metadata as code” repos. They all rhyme (markdown, frontmatter, cross-links), but none of them agree on what fields a document should carry or what a filename means. OKF’s contribution is narrow but useful: it’s the same idea, specified enough that a bundle produced by one team’s tooling is legible to another team’s agent without a translation layer.
How OKF works, structurally
Bundle structure
A bundle is a directory tree. Producers organize it however fits the domain — there’s no fixed taxonomy:
sales/
├── index.md
├── datasets/
│ ├── index.md
│ └── orders_db.md
├── tables/
│ ├── index.md
│ ├── orders.md
│ └── customers.md
└── metrics/
├── index.md
└── weekly_active_users.md
A concept’s concept ID is just its file path with the .md stripped — tables/orders.md has the concept ID tables/orders. The filesystem location is the identity.
The two reserved filenames
Two filenames carry special meaning at any level of the tree and can’t be used for ordinary concepts:
| Filename | Purpose |
|---|---|
index.md | A directory listing that supports progressive disclosure — an agent reads the index first to decide what’s worth opening, instead of loading an entire directory into context at once. Contains no frontmatter, just grouped links with short descriptions. |
log.md | An append-only, date-grouped changelog for that scope (## 2026-05-22 followed by **Update**:, **Creation**:, or **Deprecation**: entries). Optional but recommended for anything an agent maintains over time. |
Cross-linking turns the tree into a graph
Concepts link to each other with ordinary markdown links — either bundle-root-relative (/tables/customers.md, the recommended form) or path-relative (./customers.md). A link asserts a relationship; the kind of relationship (join, dependency, reference) lives in the surrounding prose, not in the link syntax itself. Consumers that render a graph view treat every link as a directed edge. Notably, the spec requires consumers to tolerate broken links — a dangling reference isn’t malformed, it’s just knowledge that hasn’t been written yet.
Conformance is deliberately loose
A bundle is v0.1-conformant if every non-reserved .md file has parseable YAML frontmatter with a non-empty type field, and reserved files follow the index.md/log.md conventions when present. That’s it. Unknown type values, missing optional fields, unknown extra frontmatter keys, and broken links are all things a compliant consumer must tolerate rather than reject.[^2] This permissiveness is intentional — the format needs to stay useful as bundles are partially generated by agents and grow messier over time.
Worked example: an OKF bundle for a UiPath automation program
To make this concrete for an automation team, here’s what a small OKF bundle might look like for a UiPath Orchestrator estate — the kind of tribal knowledge that normally lives in a wiki nobody keeps current:
automation-coe/
├── index.md
├── processes/
│ ├── index.md
│ └── invoice-processing.md
├── queues/
│ ├── index.md
│ └── ap-exceptions.md
└── runbooks/
├── index.md
└── orchestrator-robot-offline.md
runbooks/orchestrator-robot-offline.md might read:
---
type: Playbook
title: Unattended robot shows Offline in Orchestrator
description: Triage steps when a robot goes offline mid-job.
resource: https://orchestrator.acme.com/robots
tags: [uipath, orchestrator, oncall]
timestamp: 2026-06-30T09:00:00Z
---
# Trigger
Robot status flips to Offline while a job from
[invoice-processing](/processes/invoice-processing.md) is In Progress.
# Steps
1. Check the machine's connectivity to Orchestrator (port 443).
2. Confirm the UiRobot service is running on the host.
3. Requeue the affected item in
[ap-exceptions](/queues/ap-exceptions.md) rather than resubmitting the job.
# Citations
[1] UiPath Orchestrator troubleshooting guide — https://docs.uipath.com
Nothing here requires UiPath tooling to understand — it’s readable in any editor and parseable by any agent, which is exactly the point. An agent handling an on-call alert, a coding agent generating a new dispatcher workflow, or a new hire’s onboarding bot can all read the same file without a bespoke integration into Orchestrator’s API.
OKF vs. RAG: different tools for different knowledge
It’s tempting to read OKF as a RAG replacement. It isn’t, and Google doesn’t frame it that way — but the comparison is useful because it clarifies what each approach is actually for.
| RAG | OKF | |
|---|---|---|
| Core approach | Search and retrieve on demand from a vector index | Maintain a persistent, curated wiki agents read and update |
| Knowledge shape | Unstructured chunks / embeddings | Structured markdown + YAML |
| Portability | Low — tied to a vector DB and embedding model | High — plain files, vendor-neutral |
| Version control | Rarely versioned directly | Native — lives in Git |
| Setup complexity | High (embeddings, vector store, retrieval pipeline) | Low (a directory of files) |
| Best for | Large, unstructured document corpora | Curated, repeatedly-needed organizational knowledge |
| Knowledge growth | Static — re-retrieved every query | Cumulative — the wiki gets better over time |
| Maturity (as of mid-2026) | High, years of tooling (LangChain, LlamaIndex) | Very early — v0.1, published June 2026 |
RAG still wins when you have millions of raw, unstructured documents and no pre-existing structure to lean on — support tickets, contracts, research papers. OKF wins for the smaller, denser layer of knowledge an agent needs reliably and repeatedly: schema definitions, metric logic, runbooks, join paths — the stuff currently being re-retrieved, re-explained, or re-guessed on every single agent run. Think of RAG as a library and OKF as a well-maintained team handbook. Most agentic systems will eventually want both, with OKF as the always-loaded core context and RAG handling the long tail.
OKF vs. llms.txt vs. AGENTS.md/CLAUDE.md
OKF also sits inside a broader, informal stack of conventions for making a system legible to machines, and it’s worth knowing where each layer stops:
| Format | What it is | Scope | Who reads it |
|---|---|---|---|
robots.txt / sitemap.xml | Tells a crawler which URLs exist | A site | Crawlers |
llms.txt | A single pointer file at a site root | A handful of pages worth reading | Web crawlers, LLMs |
AGENTS.md / CLAUDE.md | Instructions for how a coding agent should behave | One repo or agent | The coding agent in that repo |
| OKF | A directory of typed, cross-linked markdown concepts | A whole knowledge base | Any agent or tool, across organizations |
llms.txt points; AGENTS.md instructs; OKF hands over the actual knowledge, structured as a traversable graph. They’re complementary rather than competing — a repo can ship an AGENTS.md for behavior and an OKF bundle for domain knowledge at the same time.
What ships alongside the v0.1 spec
Google published reference implementations at both ends of the pipeline, explicitly as proofs of concept rather than the only valid way to build one:[^1]
- An enrichment agent that walks a BigQuery dataset, drafts an OKF concept for every table and view, then runs a second LLM pass to enrich each concept with citations, schemas, and join paths pulled from documentation.
- A static HTML visualizer — a single self-contained file that turns any OKF bundle into an interactive graph, with no backend and no data leaving the page.
- Three sample bundles (GA4 e-commerce, Stack Overflow, Bitcoin public datasets) committed to the repo as working examples of conformant OKF.
The spec, sample bundles, and reference agent are all in the public GoogleCloudPlatform/knowledge-catalog repository on GitHub, and Google has already wired its own Knowledge Catalog product to ingest OKF bundles.[^1] Independent tooling is already appearing outside Google — including a free WordPress plugin that auto-generates a bundle from published posts, and third-party OKF conformance validators.[^4]
Limitations and open risks
A few things are worth being honest about before adopting this on a live system:
- It’s genuinely early. Google calls v0.1 “a starting point, not a finished standard.” Field conventions, tooling, and even the reserved-filename list may change in future minor or major versions.
- Curation isn’t free. Unlike RAG, which can point at raw documents as-is, OKF’s value comes from someone — human or agent — actually writing typed, cross-linked concepts. A bundle where every file has the same generic
typeand no real relationships is barely more useful than a folder of loose notes; several early guides flag exactly this failure mode with auto-generated bundles.[^4] - It’s a new attack surface if agents write into it. A bundle that an agent updates from untrusted input is a plausible vector for indirect prompt injection — what’s allowed to write into a shared, always-loaded knowledge base matters as much as what’s allowed to read from it.
- It is not an SEO or ranking signal. Despite some early coverage implying otherwise, Google’s search systems don’t fetch a public OKF bundle from a website to rank it. It’s an internal knowledge format for agents, not a web publishing signal.[^4]
What this means for RPA and agentic automation teams
For readers building or running automation programs, OKF is worth watching for a specific reason: it targets exactly the knowledge layer that agentic automation keeps tripping over — the gap between “the model can generate a workflow” and “the model knows your schema, your queue-retry policy, and why the checkout API changed last sprint.” That gap is a recurring failure mode in agentic rollouts (see our breakdown of why agentic automation programs fail, where undocumented tribal context shows up repeatedly as a root cause).
Automation Centers of Excellence already maintain a version of this knowledge informally — process documentation, Orchestrator runbooks, queue definitions, exception-handling playbooks. The pitch of OKF is that turning that material into a typed, linked, Git-versioned bundle costs little more than writing it down properly once, and it pays off the moment you’re feeding context to a coding agent building a new dispatcher workflow, a triage agent responding to Orchestrator alerts, or an onboarding assistant for a new automation developer. It’s also a natural complement to MCP-based agent architectures: MCP servers expose actions an agent can take, while an OKF bundle can supply the context the agent needs to decide which action is correct.
Whether OKF specifically becomes the standard, or gets superseded by something else in the next year of iteration, the underlying discipline — curated, versioned, agent-readable knowledge instead of scattered tribal memory — is worth adopting regardless of which file format wins.
Key Takeaways
- OKF is a file format, not a service. A knowledge bundle is a directory of markdown files with YAML frontmatter — no SDK, database, or proprietary runtime required.
- Only one field is mandatory:
type. Everything else (title,description,resource,tags,timestamp, custom keys) is optional, keeping the barrier to producing a bundle low. - It formalizes Karpathy’s “LLM wiki” pattern — a persistent, agent-maintained markdown knowledge base instead of re-retrieving the same facts on every run.
- It doesn’t replace RAG. RAG still wins for large, unstructured corpora; OKF wins for curated, repeatedly-needed organizational knowledge like schemas, metrics, and runbooks.
- It’s genuinely v0.1. Treat it as an early, evolving spec — useful to pilot now, not yet something to bet a production architecture on wholesale.
- For automation teams, OKF maps directly onto the process documentation, runbooks, and queue definitions that Centers of Excellence already maintain — formalizing that material is low-cost and pays off the moment agents need to reason about it.
FAQs
What is the Open Knowledge Format (OKF)? OKF is an open specification from Google Cloud, published June 12, 2026, that represents organizational knowledge as a directory of markdown files with YAML frontmatter. It’s designed to be readable by humans and parseable by AI agents without a translation layer or SDK.
Who created OKF? Google Cloud’s Data Cloud team created OKF. The announcement was authored by Sam McVeety (Tech Lead, Data Analytics) and Amir Hormati (Tech Lead, BigQuery), and the spec is published as an open standard in the public GoogleCloudPlatform/knowledge-catalog GitHub repository.
Does OKF replace RAG? No. OKF and RAG solve different problems. RAG is best for large, unstructured document corpora searched on demand. OKF is best for curated, structured knowledge — schemas, metric definitions, runbooks — that an agent needs reliably and repeatedly. Most systems will end up using both.
Is OKF an SEO or Google ranking signal? No. Google’s search systems do not fetch a public OKF bundle to rank a website with it. OKF is an internal knowledge format for AI agents, not a web publishing or SEO signal.
How do I create an OKF bundle? Write the knowledge worth capturing as individual markdown files, each with a YAML frontmatter block containing at least a type field. Cross-link related concepts with markdown links, add an index.md per directory for navigation, and host the bundle in a Git repo (recommended) or as a tarball. Google’s reference enrichment agent and third-party validators can help automate and check the output.
Is OKF only for BigQuery or Google Cloud data? No. The reference implementations Google shipped happen to target BigQuery, but the format itself is domain-agnostic — it works equally well for runbooks, API documentation, RPA process libraries, or any knowledge a team wants an agent to read.
References
[^1]: Sam McVeety and Amir Hormati, “Introducing the Open Knowledge Format,” Google Cloud Blog, June 12, 2026 — https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing
[^2]: “Open Knowledge Format (OKF), Version 0.1 — Draft,” GoogleCloudPlatform/knowledge-catalog, GitHub — https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
[^3]: Andrej Karpathy, “LLM Wiki,” GitHub Gist — https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f [^4]: WitsCode, “Open Knowledge Format (OKF): The Complete 2026 Guide,” published June 18, 2026, updated June 21, 2026 — https://witscode.com/open-knowledge-format
Further industry commentary consulted: “Google’s New Knowledge Standard: What Is the Open Knowledge Format (OKF)?”, Medium, June 19, 2026 — https://medium.com/@aristojeff/googles-new-knowledge-standard-what-is-the-open-knowledge-format-okf-f044ddf5b6bd;
“Google’s Open Knowledge Format (OKF) vs. RAG,” AlphaMatch, June 30, 2026 — https://www.alphamatch.ai/blog/google-open-knowledge-format-okf-vs-rag-2026
