Google Cloud has introduced Open Knowledge Format, an open specification that aims to address one of the most common problems in projects involving AI agents: context. Models can write code, summarize documents, query data or assist with operations, but their usefulness drops sharply when they do not understand how the real knowledge of a company, project or team is organized.
The proposal, published on June 12, 2026 by Google Cloud’s Data Cloud team, does not arrive as a new closed platform or another SaaS service for documenting everything. OKF suggests something much simpler: representing knowledge as a folder of Markdown files with YAML metadata, internal links, optional indexes and change logs. A living wiki, readable by humans and usable by agents.
A small specification for a big problem
The starting point for OKF is easy for any technical team to recognize. Important information is usually spread across too many places: internal wikis, code comments, notebooks, data catalogs, spreadsheets, product documents, runbooks, old tickets or simply inside the heads of two or three senior people.
When an agent needs to answer a practical question, such as “how is weekly active user calculated?”, “which table contains valid orders?”, “which API is deprecated?” or “what steps do we follow for a data freshness alert?”, it has to rebuild the context from scattered sources and incompatible formats. Each tool has its own API, export format, internal structure and permission model.
OKF tries to offer a common contract. It does not define a rigid taxonomy or force teams to use a specific database. It also does not try to replace specialized formats such as Avro, Protobuf or OpenAPI. Its idea is more modest and, for that reason, interesting: any system should be able to produce or consume a minimal, portable and understandable knowledge base.
In practice, an OKF bundle is a directory of Markdown files. Each file represents a concept: a table, a dataset, a metric, a playbook, an endpoint, a technical reference, a business process or any unit of knowledge that deserves to exist separately. The concept identifier is its path inside the directory, without the need for a central registry.
Each document includes a YAML frontmatter block at the top. The only required field is type, which indicates the kind of concept. Other recommended fields include title, description, resource, tags and timestamp. The body of the file remains standard Markdown, with sections such as schema, examples, citations or operational notes when useful.
| OKF element | Function |
|---|---|
| Markdown file | Represents an individual concept |
| YAML frontmatter | Stores metadata that agents and tools can query |
type field | Identifies the class of knowledge being described |
index.md | Allows navigation through a folder without opening every document |
log.md | Records chronological changes |
| Markdown links | Connect concepts to one another |
# Citations | Lists external sources supporting claims |
The choice of Markdown is not accidental. It can be read in any editor, versioned with Git, reviewed in pull requests, rendered on GitHub and processed with simple tools. For agents, it also avoids an unnecessary translation layer: the same file read by a person can be read by a model.
Why developers and sysadmins should care
The most attractive part of OKF is not limited to data catalogs, even though Google presents it from that environment. Its usefulness can extend to many workflows where AI needs reliable and persistent context.
A development team could maintain an OKF folder with architectural decisions, coding conventions, critical dependencies, internal endpoints, legacy modules and deployment patterns. A system administrator could use it to document runbooks, alerts, recovery procedures, service inventories, firewall rules, sensitive configurations or relationships between infrastructure components.
For agents such as Claude Code, Gemini, Cursor or other development-oriented assistants, the value lies in documentation becoming not only text for humans, but a navigable knowledge base. An agent could read a project’s index.md, discover what concepts exist, open the right playbook, follow links to a table, API or metric, and propose changes with more context.
This connects with a trend that is accelerating: teams no longer want agents to search through the same documents again and again for the same facts. They want agents to work from a shared memory that is maintained like code. Knowledge stops being an informal collection of notes and starts behaving like a versioned repository.
OKF does not remove the need for good documentation. Nor does it guarantee that the knowledge is correct. What it provides is a common way to package it. That may sound modest, but portability matters in technical systems. If a wiki, a data catalog or an agent exports knowledge in a common format, another agent or tool can consume it without starting from scratch.
A simple example helps explain it. A company may have a metric called “net recurring revenue”. Its calculation may depend on several tables, exclusions, business rules and historical decisions. In OKF, that metric could have its own Markdown file with a description, tags, references to tables, SQL examples, internal citations and links to related concepts. An agent that needs to create a report or modify a query would not have to guess the definition or rely on a vague search.
It is not Notion or Obsidian, although it looks familiar
The comparison with Notion or Obsidian is inevitable. OKF uses Markdown, links and a wiki-like structure that resembles personal knowledge bases. It also fits patterns already being used in agent-oriented repositories, such as AGENTS.md, CLAUDE.md, index.md, decision logs or note folders that assistants read before touching the code.
But it is worth avoiding exaggeration. OKF is not a note-taking app. It does not offer a full visual interface, advanced permissions, synchronization, real-time collaborative editing, database views, rich templates or an end-user experience. It is a specification. Its strength is not in competing directly with Notion or Obsidian as a product, but in defining minimum rules so this kind of knowledge can move between tools.
In that sense, it may complement those platforms rather than replace them. A team could export part of its documentation to OKF, generate bundles from a data catalog, create a static HTML view, build an internal search tool or allow an agent to update specific documents under Git control. The interface can change; the format remains.
Google has also published reference implementations to make the proposal more concrete. These include an enrichment agent that walks through BigQuery datasets and generates OKF documents for tables and views, a static HTML visualization tool that turns a bundle into an interactive graph, and several example bundles based on public datasets such as GA4 e-commerce, Stack Overflow and Bitcoin.
That approach is reasonable. Google is not saying that everyone has to use its visualizer or its agent. The relevant point is that the format can be produced and consumed in many ways. An internal script, documentation tool, CI pipeline, AI agent or catalog export could all speak the same basic language.
The v0.1 specification is also deliberately permissive. Consumers should tolerate unknown types, additional fields, broken links or missing indexes. This detail matters because real knowledge bases are imperfect. If a format for agents breaks whenever a document is incomplete, it will not work for teams that move quickly.
Open Knowledge Format arrives at a moment when the discussion around AI agents is changing. For months, the focus has been on models, context windows, tools and benchmarks. But in real environments, the bottleneck is often different: how to give an agent reliable, up-to-date and verifiable knowledge without locking it into a specific platform.
OKF does not solve the entire problem, but it points to a necessary piece. Just as code gained a lot from version control, reviews and common formats, an organization’s operational knowledge can benefit from living in small, linked, auditable files that are easy to move.
For developers, system administrators and data teams, the idea deserves attention. Not because Google has invented Markdown with YAML, but because it is trying to turn a scattered pattern into a shared convention. If agents are going to work more and more inside our repositories, they will need something close to a project memory. OKF may be a simple way to start building it.
Frequently asked questions
What is Open Knowledge Format?
Open Knowledge Format is an open specification proposed by Google Cloud to represent knowledge in folders of Markdown files with YAML metadata. It is designed so people and AI agents can read, write and exchange context.
Does OKF replace Notion or Obsidian?
Not necessarily. It resembles them in its use of Markdown, links and a wiki-like structure, but it is not a note-taking app. OKF is a format, not a platform. It can complement tools such as Notion, Obsidian, GitHub or data catalogs.
What information can be stored in OKF?
It can document tables, datasets, metrics, APIs, runbooks, playbooks, technical decisions, internal processes or project references. Each concept lives in a Markdown file with metadata and structured content.
Why is it useful for AI agents?
Because it provides a simple and portable way to give agents context. Instead of searching across scattered documents, an agent can traverse indexes, open related concepts and work with versioned, linked knowledge.