Open Knowledge Format: The Knowledge Layer Between Data and AI Agents

An AI agent can have access to the data warehouse, files, ERP, and CRM and still fail to correctly understand the company's data. What exactly does an active customer mean? From which tables is net revenue calculated? When can a discount be recommended? What contractual exceptions exist outside the systems? (Article updated for OKF v0.2 - July 27, 2026)

"The company's internal knowledge" is a very general term, but flexible enough to cover this huge distance between working in principle and working in production.

Open Knowledge Format (OKF) is an open specification published by Google Cloud for organizing the metadata, context, and knowledge used by humans and AI agents. On June 12, 2026, version 0.1 was released. Only six weeks later, on July 25, version 0.2 was released, which strengthens the format's governance (which sources it comes from, who generated and verified it, whether it is still current), although v0.1 remains valid.

The OKF format is simple, defined by four characteristics, according to Google's specification: Readability for humans, accessibility for AI agents without special software tools, versionability for keeping a history, and portability across IT systems.

As we will see, the actual components are extremely simple: .MD files with YAML headers. We explore these, then evaluate OKF's place among the tools of the agentic ecosystem and a few projects already using OKF.

Our conclusion will be that OKF is not sufficient on its own; four layers are needed for an agentic architecture:

1. Operational data - across different systems
2. OKF - for understanding the data and internal conventions
3. Skills - procedures or workflows for the actual AI actions
4. Security and freshness rules - verify whether actions are allowed and whether the information used by AI is still valid

1. What Is Open Knowledge Format (OKF) and How Does It Work?

1.1. The Bundle and the Concept Document

The basic unit of OKF is a concept document: a Markdown file with YAML metadata. Several concepts organized in a directory form a Knowledge Bundle.

sales-knowledge/
├── index.md
├── log.md
├── metrics/
│   ├── index.md
│   ├── gross-margin.md
│   └── customer-value.md
├── policies/
│   ├── index.md
│   ├── discount-policy.md
│   └── overdue-invoices.md
├── products/
│   ├── index.md
│   ├── product-families.md
│   └── aliases.md
└── references/
    ├── policy-sales-3-2.md
    └── fin-07.md

The OKF specification imposes very few rules. The only mandatory field for a concept is type, for example Table for a data table. Fields such as title, description, resource, tags, and generated.at (in 0.1, timestamp) are recommended. In addition, you can add your own metadata, and consumers (including AI agents) must tolerate fields they don't recognize.

This means implementations will evolve differently in different contexts. Moreover, two OKF bundles will have radically different levels of detail. One might have sources, owners, approvals, review dates, and hundreds of details. Another may contain only a type field and a few paragraphs also generated automatically with AI.

1.2. Relationships Are Essential, but OKF Is Not a Complete Knowledge Graph

Beyond the YAML header in each document, folder organization is essential alongside the relationships between concepts expressed through ordinary Markdown links.

"A discount higher than 10% must be verified according to the [discount policy](/policies/discount-policy.md)."

A graph-like representation can be built from these links. But OKF does not specify advanced validation, not being a complete semantic knowledge graph with formally typed relationships. In OKF, the meaning of the relationship (for example, unidirectional) is expressed only through the text describing the link, without any mandatory ontology or a traversal or validation language.

It is therefore likely that in the future, OKF generation tools and stricter extensions of the format will appear that check and validate, including broken links (dead links).

Three OKF Generation Scenarios

• Manual authoring from scratch: maintenance becomes costly, you must make sure new links or concepts are correctly linked to the old ones
• Semi-automatic generation from existing documentation: requires syntactic validations (linting) and mandatory human review
• Quasi-automatic export: only if you use a more powerful platform connected to the sources of truth, with additional tooling for OKF

1.3. Progressive Disclosure: the AI Agent Doesn't Read Everything

The index.md file (in the root, recommended) will function as a local map of the organizational knowledge captured by the bundle, together with other index.md files in subfolders.

The agent can start reading with the main index. This way it identifies the relevant domain and then loads (hopefully) only the necessary concepts. If a policy points to an exception or a financial formula, the agent or consumer can read the details from that link.

This approach is called progressive disclosure, whose role is to reduce the context needed and the associated costs. Something similar is found in Agent Skills (from Claude): the agent first discovers the Skill's name and description, then loads the precise instructions and resources as it needs them. An OKF reading hierarchy looks like this:

index.md
├── metrics/index.md
│   └── [other .md documents in the directory]
├── policies/index.md
│   └── [other .md documents in the directory]
└── products/index.md
    └── [other .md documents in the directory]

1.4. Knowledge as Code

An OKF knowledge base can be managed in Git just like any software project. A change is proposed, published in a branch, diff can be used, an owner can do a review, and then it is finally published and reindexed in production.

The advantage is that in the AI world, transparency emerges for internal procedures and definitions, compared to other "magic" procedures. We know that in many RAG projects, documents are reindexed, but there is no transparent process that keeps track of who changed a rule and when, what text was replaced, and why the change was made. In terms of versionability, OKF is similar to Agent Skills (see below).

The risk is that if OKF bundles grow in size and include concrete cases and specific exceptions (for example, "for customer ALBIN IMPEX always apply a 4.5% discount"), versionability won't help, since the practical effects (for example, discounts granted by mistake) are not reversible.

2. OKF versus RAG/GraphRAG, MCP, and Agent Skills

Concepts in the agentic ecosystem are frequently presented as direct alternatives. In reality, they operate at different layers, and OKF will have its own place.

OKF versus RAG and GraphRAG

RAG mainly answers the question: how does AI find relevant information? OKF will answer the question: how is the knowledge that the agent must find organized?

An OKF bundle can be indexed in a vector database. Retrieval (RAG) can combine embeddings, keyword search, BM25, reranking, graph expansion, and index navigation. GraphRAG uses relationships between entities and concepts to retrieve context that cannot be found through simple similarity between fragments. OKF can provide cleaned-up concepts, but it does not impose an algorithm and does not require a graph database.

OKF can be a source for GraphRAG, but it is not a complete graph engine.

OKF versus MCP

Model Context Protocol and similar protocols facilitate connecting agents to tools and external systems. An MCP server allows the AI agent to query the database, read stock from the ERP, or even create a ticket in the CRM.

OKF explains the company's concepts to the agent: which pipeline is official, what stock is eligible, or what rules must be applied before an action.

"Return the customer's current balance."

"The balance affects the policy applicable to customers with overdue payments."

MCP provides access to data and actions, while OKF provides persistent conceptual context.

OKF versus Claude Agent Skills

The comparison with Agent Skills is important because both formats use directories, Markdown, YAML, and progressive disclosure. A Skill normally contains a SKILL.md file with the Skill's name, a description of the situations in which it must be activated, and the instructions for carrying out an activity. The directory can include scripts, references, templates, and other resources.

The specification originated in the Anthropic ecosystem, but Skills is now an open format and has been adopted across agentic AI.

The fundamental difference is between knowledge (OKF) and procedure (Skill):

The new OKF v0.2 variant makes the boundary a bit more flexible through the concept of Attested Computation. A concept document can specify how a value must be calculated, by which executor, and how the execution is verified, including runtime, although it does not actually execute it. We currently recommend that runtime remain with Skills or other tools.

For All: Security and Compliance Rules (Guardrails)

Since this involves generative AI, at every step (data extraction, reading OKF knowledge, adopting a procedure from a Skill / MCP connections) there must be a layer of guardrails (rules) with permissions and access management (IAM) that verifies AI cannot take actions harmful to the company.

To recap, the following table results:

3. OKF v0.2: How Do We Build a Verifiable Knowledge Bundle?

The problem OKF started from is that access to data does not guarantee understanding of its meaning for the company. OKF comes on top of data as an intermediate layer: information synthesized into clean concepts (additionally interconnected and versioned), before being used by AI agents.

---
type: Metric
title: Commercial margin
description: The approved definition of the commercial margin used in B2B quotes.
resource: erp://metrics/commercial-margin
tags: [sales, finance, pricing]

sources:
  - id: policy-sales-3-2
    resource: /references/policy-sales-3-2.md
    title: Approved commercial policy, version 3.2

  - id: fin-07
    resource: /references/fin-07.md
    title: FIN-07 financial procedure

generated:
  by: human:name-editor
  at: 2026-07-27T10:00:00Z

verified:
  by: human:sales-director
  at: 2026-07-27T12:00:00Z

status: stable
stale_after: 2026-09-30
---

# Definition

Commercial margin is calculated as the difference between the net selling
price and the eligible product cost, reported relative to the net price.[^policy-sales-3-2]

# Exceptions

For products being liquidated, the weighted average cost is used.[^fin-07]

# Relationships

See the [discount policy](/policies/discount-policy.md).

[^policy-sales-3-2]: Approved commercial policy, version 3.2
[^fin-07]: FIN-07 financial procedure

This file can be modified by management and then read by employees and processed by AI agents. But OKF itself does not guarantee checks, neither for coherence ("there are no missing references") nor for facts ("it does not contain expired information").

For governance, Google adds new fields in v0.2:

We recommend using the new fields in all concept documents.

3.1. Explicitly Handle the Unknown

Any living knowledge base (en. living wiki) is more valuable if it explicitly includes the verification trail. You can use a custom field to describe this trail:

status: draft
missing_information:
  - delivery restriction for refrigerated products

In v0.2, the verified field is added only after the information is confirmed; its absence indicates an unverified concept, while status: draft indicates that the document is not yet stable.

Especially in sensitive or regulated domains such as medical software or security aspects, the unknown must be a valid state of the system.

3.2. Define Rule Precedence and Be Explicit

In the field of AI-driven sales, let's assume there is a general policy with a 10% discount, a rule for strategic customers of 15%, and an individual contract of 12%. The agent needs an explicit hierarchy: individual contract, approved exception, specific policy, general company policy.

OKF allows documenting this hierarchy through optional fields, which is why they matter. Similarly, you must be as explicit as possible to guide AI agents:

description: Information about discounts.

description: Maximum discount thresholds and approval levels,
based on product group, customer segment, and sales role.

aliases:
  - yellow syringe
  - seringă galbenă
  - PX747

3.3. Specify the Owner, the Review Policy, and Prepare an Approval Flow

A concept should have an owner and an authoritative source.

owner: sales-operations
source_of_truth: erp-policy-service

verified:
  by: human:sales-director
  at: 2026-07-27T12:00:00Z

status: stable
stale_after: 2026-09-30

The fields verified, status, and stale_after are fields specified by v0.2. The fields owner and source_of_truth are custom extensions allowed by the format. In an enterprise environment, other custom fields can also be added, such as valid_from, valid_until, sensitivity, or language.

For semi-automated OKF bundles that touch the company's core logic, the approval flow is essential.

Do you have definitions and procedures that AI agents need to interpret consistently? Talk to OPTI's experts

4. What Early Public Implementations Show

Google presented OKF from the start as an evolving specification. The first public implementations show both the possible directions and the practical difficulties of the format.

4.1. Google Cloud: BigQuery and Knowledge Catalog

Google published, immediately after the OKF specification:

• demonstrative OKF bundles and a static viewer
• an enrichment agent for BigQuery
• The use of OKF information in Google Cloud Knowledge Catalog.

In BigQuery's case, an automated process analyzes the data schema and creates documents for tables and views, which can be completed with explanations, relationships, and query examples. This is the first example of tooling for OKF generation.

4.2. OpenKB: Knowledge Compilation

The open-source OpenKB project transforms PDFs, Office files, web pages, and other sources into an interconnected wiki compatible with OKF.

The central concept is knowledge compilation. Instead of keeping each document completely separate when adding it, the system tries to automatically identify the other affected concepts and update the documents in the bundle.

New document
     │
     ▼
Identifying the concepts within it
     │
     ▼
Comparing with existing information
     │
     ▼
Updating other documents and relationships
     │
     ▼
Consolidated knowledge base

The risk is that if the automated process misinterprets a source, the error does not stay in a single place. That's why knowledge compilation must be subject to a strict approval flow, as recommended above.

4.3. Review-First Import

The llm-wiki-compiler project experiments with OKF import and export, link validation, content evaluation, and hybrid retrieval for creating a classic wiki used by LLMs.

The most attractive idea is review-first import: a bundle received from outside does not automatically become adopted organizational truth. It is introduced into a staging area, after syntactic validation, and must be approved to be considered an active knowledge base. Just as a valid CSV file does not necessarily contain correct data, a valid OKF bundle does not necessarily contain true knowledge.

4.4. Abode 101: Sources and Explicit Unknowns

A specific but forward-looking example is Abode 101, a knowledge base for managing a home: equipment, manuals, installations, maintenance work.

The project is interesting because it adds two optional rules for OKF:

• every fact must have a declared source and confidence level
• if the information is not documented, the agent is instructed to say it doesn't know.

If this is the standard for a personal home, similar standards will also apply in business. The question "What battery does the sensor use?" becomes, in sales, "What is the ERP code of the product the customer informally requested?" In finance it might become "What is the official net revenue formula?" It is the company's responsibility to guarantee the correctness and currency of the facts in OKF.

Conclusion: What Does the Future Hold for the OKF Format?

In just six weeks and two published versions, OKF has proven that it has enough flexibility for a unified layer on top of data, but before actual AI actions.

We identified two main risks: the responsibility of keeping it updated, and the danger of bloat: creating a separate data lake, this time in Markdown. The operational impact will depend on how much time the company invests in writing and maintaining a clean OKF, the interoperable tools that will emerge, and the success across the disparate domains where AI is used.

We illustrate the possible success with OPTI's latest technical guides:

Finally, we expect to see the metrics that will make the difference in adoption, especially results from the enterprise environment and hallucination reduction by a predictable percentage.

Do you have rules and procedures scattered across your company? OPTI can integrate them so they can be used successfully by AI agents

×