OKF: Redefining Knowledge Bases for AI Agents

-->

OKF: Redefining Knowledge Bases for AI Agents - Analytics Vidhya

India's Most Futuristic AI Conference Is Back – Bigger, Sharper, Bolder

d

:

h

:

m

:

s

Career

GenAI

Prompt Engg

ChatGPT

LLM

Langchain

RAG

AI Agents

Machine Learning

Deep Learning

GenAI Tools

LLMOps

Python

NLP

SQL

AIML Projects

Reading list

How to Become a Data Analyst in 2025: A Complete RoadMap

A Comprehensive Learning Path to Tableau in 2025

A Comprehensive NLP Learning Path 2025

Learning Path to Become a Data Scientist in 2025

Step-by-Step Roadmap to Become a Data Engineer in 2025

A Comprehensive MLOps Learning Path: 2025 Edition

Roadmap to Become an AI Engineer in 2025

A Comprehensive Learning Path to Master Computer Vision in 2025

Best Roadmap to Learn Generative AI in 2025

GenAI Roadmap for Enterprises

Large Language Models Demystified: A Beginner’s Roadmap

Learning Path to Become a Prompt Engineering Specialist

OKF: Redefining Knowledge Bases for AI Agents

Shaik Hamzah Shareef Last Updated : 07 Jul, 2026

12 min read

In June 2026, Google introduced the Open Knowledge Format (OKF), an open specification for how AI agents organise and exchange knowledge. An OKF bundle is just Markdown files, lightweight YAML metadata, and links between concepts, yet it challenges the assumption that every AI application needs embeddings and vector databases.

Because the knowledge base is plain text, it can be version-controlled in Git and navigated by following links rather than retrieving disconnected chunks. In this article, we’ll explore how OKF works and when it beats a traditional retrieval pipeline.

Table of contents

Why Traditional RAG Has Limitations

What is the Open Knowledge Format (OKF)?

Structure of an OKF Bundle

A Typical OKF Folder Structure

Building an OKF Bundle

Creating an OKF Concept File

Understanding the YAML Metadata

Linking Related Concepts

Another Example: Hospital Metric

How AI Agents Traverse an OKF Bundle

Why This Works Well for AI Agents

Where RAG Still Excels

Hybrid Knowledge Architecture: Combining OKF and RAG

Conclusion

Frequently Asked Questions

Why Traditional RAG Has Limitations

Over the past few years, Retrieval-Augmented Generation (RAG) has become the standard approach for providing external knowledge to Large Language Models. Instead of relying solely on the model’s training data, RAG retrieves relevant information from external documents during inference. A typical pipeline looks something like this:

This approach works remarkably well for searching millions of documents. By comparing the semantic meaning of embeddings instead of exact keywords, RAG allows an AI system to answer questions using information that was never part of the model’s original training data.

However, there is an important trade-off. Before a document can be indexed, it must first be divided into smaller chunks. While chunking improves retrieval efficiency, it also breaks apart the original structure of the document. Relationships that were naturally connected inside a single document become distributed across multiple independent chunks.

Consider the following hospital protocol.

Patient Admission Policy

Patients arriving through the Emergency Department must complete an initial triage before admission.

Admission Requirements

• Valid patient identification
• Initial clinical assessment completed
• Emergency cases receive immediate priority

Recording and Bed Allocation

Patient information is recorded in the Electronic Health Record (EHR) system before a bed is assigned.

Bed allocation follows the Bed Occupancy guidelines maintained by the Operations team.

A typical RAG pipeline may split this document into several smaller chunks before indexing.

1st Chunk

Patients arriving through the Emergency Department must complete an initial triage.

Admission Requirements:

• Valid patient identification
• Initial clinical assessment
• Emergency cases receive immediate priority

2nd Chunk

Patient information is recorded in the Electronic Health Record (EHR) system.

3rd Chunk

Bed allocation follows the Bed Occupancy guidelines maintained by the Operations team.

Visually, the process looks like this:

When a clinician asks,

“What is the patient admission process?”

The vector database retrieves the chunks that seem most relevant, but the logical relationships between the admission policy, emergency triage, the EHR system, and bed allocation are lost. The model has to reconstruct them on every query. This isn’t a flaw in RAG. It remains one of the best techniques for searching large, unstructured collections like PDFs, research papers, support tickets, and historical records.

Curated organisational knowledge is different. Policies, procedures, APIs, and runbooks aren’t just text, they’re interconnected concepts. Rebuilding those links from fragmented chunks on every query adds needless complexity, and that is exactly the problem OKF was designed to solve.

What is the Open Knowledge Format (OKF)?

The ideas behind OKF did not originate with Google. Earlier in 2026, Andrej Karpathy introduced the concept of an LLM Wiki: instead of repeatedly retrieving raw documents, an AI agent maintains a curated knowledge base it can continuously read, update, and improve. His analogy caught on quickly in the AI community:

Obsidian is the IDE. The LLM is the programmer. The wiki is the codebase.

The idea is simple. Humans provide source material like documentation, policies, schemas, and runbooks, and the agent organises it into a structured wiki by writing summaries, connecting related concepts, and maintaining links. Those relationships become part of the knowledge base instead of being rediscovered on every query.

Google turned this community idea into an open specification. Rather than shipping another framework or SDK, it focused on standardising the knowledge itself. The result is OKF, a lightweight format that stores knowledge as ordinary Markdown files with minimal metadata and explicit links between concepts.

An OKF bundle is just a directory of Markdown documents, each representing one concept such as a policy, API, department, runbook, database table, or metric, connected through standard Markdown links. Unlike a vector database that infers relationships through embedding similarity, OKF preserves them explicitly, so an agent follows links rather than guessing.

Because everything is plain text, it fits existing developer workflows: version-controlled in Git, reviewed via pull requests, and searchable with standard tools. Next, we’ll build a bundle from scratch to see how it is organised.

Structure of an OKF Bundle

Now that we’ve understood the motivation behind OKF, let’s look at how an OKF bundle is actually organised. At its core, an OKF bundle is simply a directory of Markdown files. Each Markdown file represents one concept, such as a hospital policy, department, procedure, system, or operational metric. Every concept contains lightweight metadata followed by structured Markdown content. Related concepts are connected using standard Markdown links, allowing both humans and AI agents to navigate the knowledge base naturally.

The specification itself is intentionally minimal. It defines only a few conventions and avoids enforcing a rigid directory structure. This gives organisations the flexibility to organise knowledge in a way that best fits their domain while still producing bundles that can be understood by any OKF-compatible agent.

A typical OKF bundle contains the following components.

Component

Purpose

index.md Serves as the primary entry point into the knowledge base. It provides an overview of the available concepts and helps agents navigate the bundle.

CHANGELOG.md (Optional) Records changes made to the knowledge base over time, making updates transparent and traceable.

Concept Files (.md) Each Markdown file represents a single concept such as a policy, procedure, API, department, metric, or system.

YAML Front Matter Stores metadata including the concept type, title, description, tags, ownership, and last updated timestamp.

Markdown Links Explicitly connect related concepts, transforming the knowledge base into a navigable graph instead of isolated documents.

A Typical OKF Folder Structure

Although the OKF specification does not mandate a particular directory layout, following a consistent folder hierarchy makes the knowledge base significantly easier to maintain and navigate. The same organisational principles apply regardless of the domain.

The following examples demonstrate how different organisations can structure their knowledge while following the same OKF conventions.

1: Hospital Knowledge Base

2: Software Engineering Knowledge Base

3: Manufacturing Knowledge Base

Although these examples belong to completely different industries, the underlying organisation remains remarkably similar. Every bundle begins with an index.md file that serves as the entry point, an optional CHANGELOG.md for tracking revisions, and a set of directories that group related concepts together.

This consistency is one of OKF’s biggest strengths. Once an AI agent understands how one OKF bundle is organised, it can navigate another bundle built using the same conventions with little or no additional adaptation.

Building an OKF Bundle

Now that we’ve explored the overall structure of an OKF bundle, let’s build one from scratch.

For the remainder of this article, we’ll use a fictional hospital called CityCare Hospital. Imagine we’re building an AI assistant that helps doctors, nurses, and hospital administrators answer operational questions. The assistant should understand admission policies, emergency procedures, hospital departments, internal systems, and operational metrics. Instead of storing this information inside a vector database, we’ll organise it as an OKF bundle.

We’ll begin by creating the root directory.

The index.md file acts as the entry point for both humans and AI agents.

CityCare Hospital Knowledge Base

Policies

• [Patient Admission Policy](policies/patient-admission.md)
• [Discharge Policy](policies/discharge-policy.md)

Procedures

• [Emergency Triage](procedures/emergency-triage.md)
• [Blood Transfusion](procedures/blood-transfusion.md)

Systems

• [Electronic Health Record](systems/ehr-system.md)

Metrics

• [Bed Occupancy](metrics/bed-occupancy.md)

Departments

• [Emergency Department](departments/emergency.md)

Rather than searching the entire repository, an AI agent can first read the index to understand what concepts exist before navigating to the relevant files. This simple design keeps the bundle organised while reducing unnecessary context during retrieval.

In the next section, we’ll create individual concept files and examine how YAML metadata, Markdown content, and links work together to make the knowledge base understandable for both humans and AI agents.

Creating an OKF Concept File

The building blocks of an OKF bundle are concept files. Each concept represents exactly one piece of knowledge, such as a policy, procedure, department, system, metric, or API. Keeping concepts focused makes them easier to maintain while allowing AI agents to retrieve only the information they need.

Every concept file consists of two parts:

YAML Front Matter, which stores metadata about the concept.

Markdown Content, which contains the actual knowledge along with links to related concepts.

Let’s create a concept file for the hospital’s patient admission policy.

--- type: policy title: Patient Admission Policy description: Guidelines for admitting patients into CityCare Hospital tags:

• admissions
• patient-care

updated: 2026-06-15 ---

Patient Admission Policy

Patients arriving through the Emergency Department must complete an initial triage before admission.

Admission Requirements

• Valid patient identification
• Initial clinical assessment com

[truncated for AI cost control]