{"id":354652,"date":"2026-07-08T07:14:16","date_gmt":"2026-07-08T07:14:16","guid":{"rendered":"https:\/\/peraltafinancing.com\/analytics\/okf-redefining-knowledge-bases-for-ai-agents\/"},"modified":"2026-07-08T07:14:16","modified_gmt":"2026-07-08T07:14:16","slug":"okf-redefining-knowledge-bases-for-ai-agents","status":"publish","type":"post","link":"https:\/\/fivemor.com\/?p=354652","title":{"rendered":"OKF: Redefining Knowledge Bases for AI Agents"},"content":{"rendered":"


\n<\/p>\n

\n

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. <\/p>\n

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\u2019ll explore how OKF works and when it beats a traditional retrieval pipeline.<\/p>\n

Why Traditional RAG Has Limitations<\/h2>\n

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

\n
\"Traditional<\/figure>\n<\/div>\n

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\u2019s original training data.<\/p>\n

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.<\/p>\n

Consider the following hospital protocol.<\/p>\n

# Patient Admission Policy
Patients arriving through the Emergency Department must complete an initial triage before admission.<\/p>
## Admission Requirements<\/p>
- Valid patient identification- Initial clinical assessment completed- Emergency cases receive immediate priority<\/p>
## Recording and Bed Allocation<\/p>
Patient information is recorded in the Electronic Health Record (EHR) system before a bed is assigned.<\/p>
Bed allocation follows the Bed Occupancy guidelines maintained by the Operations team.<\/p><\/pre>\n
A typical RAG pipeline may split this document into several smaller chunks before indexing.<\/p>\n
1st Chunk<\/h4>\n
Patients arriving through the Emergency Department must complete an initial triage.
Admission Requirements:<\/p>
- Valid patient identification- Initial clinical assessment- Emergency cases receive immediate priority<\/p><\/pre>\n
2nd Chunk<\/h4>\n
Patient information is recorded in the Electronic Health Record (EHR) system.<\/pre>\n
3rd Chunk<\/h4>\n
Bed allocation follows the Bed Occupancy guidelines maintained by the Operations team.<\/pre>\n
Visually, the process looks like this:<\/p>\n
\n
\"Chunking<\/figure>\n<\/div>\n
When a clinician asks,<\/p>\n
\u201cWhat is the patient admission process?\u201d<\/em><\/strong><\/p>\n
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\u2019t 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.<\/p>\n
Curated organisational knowledge is different. Policies, procedures, APIs, and runbooks aren\u2019t just text, they\u2019re 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.<\/p>\n
What is the Open Knowledge Format (OKF)?<\/h2>\n
The ideas behind OKF did not originate with Google. Earlier in 2026, Andrej Karpathy introduced the concept of an LLM Wiki<\/a>: 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:<\/p>\n
Obsidian is the IDE. The LLM is the programmer. The wiki is the codebase.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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\u2019ll build a bundle from scratch to see how it is organised.<\/p>\n
Structure of an OKF Bundle<\/h2>\n
Now that we\u2019ve understood the motivation behind OKF, let\u2019s 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.<\/p>\n
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.<\/p>\n
A typical OKF bundle contains the following components.<\/p>\n
\n
\n\n\n\n\n\n\n\n\n
\n            Component<\/strong>\n          <\/td>\n\n            Purpose<\/strong>\n          <\/td>\n<\/tr>\n
index.md<\/td>\nServes as the primary entry point into the knowledge base. It provides an overview of the available concepts and helps agents navigate the bundle.<\/td>\n<\/tr>\n
CHANGELOG.md (Optional)<\/em><\/td>\nRecords changes made to the knowledge base over time, making updates transparent and traceable.<\/td>\n<\/tr>\n
Concept Files (.md)<\/td>\nEach Markdown file represents a single concept such as a policy, procedure, API, department, metric, or system.<\/td>\n<\/tr>\n
YAML Front Matter<\/td>\nStores metadata including the concept type, title, description, tags, ownership, and last updated timestamp.<\/td>\n<\/tr>\n
Markdown Links<\/td>\nExplicitly connect related concepts, transforming the knowledge base into a navigable graph instead of isolated documents.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<\/div>\n
A Typical OKF Folder Structure<\/h2>\n
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.<\/p>\n
The following examples demonstrate how different organisations can structure their knowledge while following the same OKF conventions.<\/p>\n
1: Hospital Knowledge Base<\/h3>\n
\n
\"Hospital<\/figure>\n<\/div>\n
2: Software Engineering Knowledge Base<\/h3>\n
\n
\"Software<\/figure>\n<\/div>\n
3: Manufacturing Knowledge Base<\/h3>\n
\n
\"Manufacturing<\/figure>\n<\/div>\n
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<\/code> for tracking revisions, and a set of directories that group related concepts together.<\/p>\n
This consistency is one of OKF\u2019s 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.<\/p>\n
Building an OKF Bundle<\/h2>\n
Now that we\u2019ve explored the overall structure of an OKF bundle, let\u2019s build one from scratch.<\/p>\n
For the remainder of this article, we\u2019ll use a fictional hospital called CityCare Hospital<\/strong>. Imagine we\u2019re 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\u2019ll organise it as an OKF bundle.<\/p>\n
We\u2019ll begin by creating the root directory.<\/p>\n
\n
\"CityCare<\/figure>\n<\/div>\n
The index.md file acts as the entry point for both humans and AI agents.<\/p>\n
# CityCare Hospital Knowledge Base
## Policies<\/p>
- [Patient Admission Policy](policies\/patient-admission.md)- [Discharge Policy](policies\/discharge-policy.md)<\/p>
## Procedures<\/p>
- [Emergency Triage](procedures\/emergency-triage.md)- [Blood Transfusion](procedures\/blood-transfusion.md)<\/p>
## Systems<\/p>
- [Electronic Health Record](systems\/ehr-system.md)<\/p>
## Metrics<\/p>
- [Bed Occupancy](metrics\/bed-occupancy.md)<\/p>
## Departments<\/p>
- [Emergency Department](departments\/emergency.md)<\/p><\/pre>\n
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.<\/p>\n
In the next section, we\u2019ll 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.<\/p>\n
Creating an OKF Concept File<\/h2>\n
The building blocks of an OKF bundle are concept files<\/strong>. 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.<\/p>\n
Every concept file consists of two parts:<\/p>\n
    \n
  1. YAML Front Matter<\/strong>, which stores metadata about the concept.<\/li>\n
  2. Markdown Content<\/strong>, which contains the actual knowledge along with links to related concepts.<\/li>\n<\/ol>\n
    Let\u2019s create a concept file for the hospital\u2019s patient admission policy.<\/p>\n
    ---type: policytitle: Patient Admission Policydescription: Guidelines for admitting patients into CityCare Hospitaltags:- admissions- patient-careupdated: 2026-06-15---
    # Patient Admission Policy<\/p>
    Patients arriving through the Emergency Department must complete an initial triage before admission.<\/p>
    ## Admission Requirements<\/p>
    - Valid patient identification- Initial clinical assessment completed- Emergency cases receive immediate priority<\/p>
    ## Related Concepts<\/p>
    - [Emergency Triage](..\/procedures\/emergency-triage.md)- [Electronic Health Record](..\/systems\/ehr-system.md)<\/p><\/pre>\n
    Notice that the file contains much more than plain text. The YAML section describes what kind of knowledge this file represents, while the Markdown body explains the concept in detail. Most importantly, the concept links to other related concepts inside the knowledge base. These links transform isolated documents into an interconnected knowledge graph that an AI agent can navigate.<\/p>\n
    Although OKF only requires the type field, adding additional metadata makes the bundle easier to organise and maintain.<\/p>\n
    \n
    \n\n\n\n\n\n\n\n\n
    \n            Field<\/strong>\n          <\/td>\n\n            Description<\/strong>\n          <\/td>\n<\/tr>\n
    type<\/td>\nIdentifies the type of concept, such as policy, procedure, system, or metric. This is the only required field in the current specification.<\/td>\n<\/tr>\n
    title<\/td>\nHuman-readable title of the concept.<\/td>\n<\/tr>\n
    description<\/td>\nSummary describing the concept.<\/td>\n<\/tr>\n
    tags<\/td>\nKeywords that help organise related concepts.<\/td>\n<\/tr>\n
    updated<\/td>\nIndicates when the concept was last modified.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<\/div>\n
    Since the metadata is stored in YAML, both humans and AI agents can quickly understand what a document represents before reading its full content.<\/p>\n
    One of the biggest differences between OKF and traditional document storage is that concepts are explicitly connected using Markdown links.<\/p>\n
    For example, the admission policy references the emergency triage procedure and the Electronic Health Record (EHR) system.<\/p>\n
    \n
    \"Explicit<\/figure>\n<\/div>\n
    These relationships are intentionally created by the author. The agent does not have to infer them through semantic similarity because they already exist inside the knowledge base.<\/p>\n
    Another Example: Hospital Metric<\/h2>\n
    Concept files are not limited to policies. The same structure can describe operational metrics, internal systems, departments, APIs, or runbooks.<\/p>\n
    Below is a concept describing the hospital\u2019s Bed Occupancy Rate<\/strong>.<\/p>\n
    ---type: metrictitle: Bed Occupancy Ratedescription: Percentage of inpatient beds currently occupiedtags:- operations- hospitalupdated: 2026-06-15---
    # Bed Occupancy Rate<\/p>
    The Bed Occupancy Rate measures the percentage of inpatient beds currently occupied.<\/p>
    ## FormulaOccupied Beds \/ Total Available Beds \u00d7 100<\/p>
    ## Data Source<\/p>
    Hospital Information System<\/p>
    ## Owner<\/p>
    Operations Department<\/p>
    ## Related Concepts<\/p>
    - [Emergency Department](..\/departments\/emergency.md)- [Patient Admission Policy](..\/policies\/patient-admission.md)<\/p><\/pre>\n
    Because every concept follows a consistent structure, an AI agent can quickly understand what the metric represents, how it is calculated, where the data comes from, and which other concepts are related to it.<\/p>\n
    How AI Agents Traverse an OKF Bundle<\/h2>\n
    Once the knowledge base is organised into interconnected concept files, retrieval becomes much simpler than traditional document search.<\/p>\n
    Instead of searching thousands of document chunks, an AI agent follows a structured navigation process.<\/p>\n
      \n
    1. Read the index.md file to understand the overall knowledge base.<\/li>\n
    2. Identify the most relevant concept based on the user\u2019s question.<\/li>\n
    3. Open that concept file.<\/li>\n
    4. Follow links to related concepts whenever additional context is needed.<\/li>\n
    5. Generate the final response using only the relevant concepts.<\/li>\n<\/ol>\n
      The traversal process can be visualised as follows.<\/p>\n
      \n
      \"How<\/figure>\n<\/div>\n
      Unlike a RAG pipeline, the agent does not begin by searching an embedding index. It starts from a curated entry point and progressively explores only the concepts that are relevant to the current task.<\/p>\n
      This approach preserves the relationships between concepts while keeping the amount of context sent to the language model relatively small.<\/p>\n
      Why This Works Well for AI Agents<\/h2>\n
      The biggest advantage of OKF is that it allows developers to organise knowledge in the same way humans naturally think about it. A doctor reading the hospital\u2019s documentation does not randomly jump between unrelated paragraphs. They begin with a policy, follow references to procedures, consult the relevant systems, and then arrive at the information they need. OKF enables AI agents to follow this same workflow.<\/p>\n
      Instead of reconstructing relationships from fragmented document chunks every time a question is asked, the agent navigates an explicit knowledge graph where those relationships have already been defined. This makes the retrieval process more deterministic, easier to audit, and significantly simpler to maintain.<\/p>\n
      Where RAG Still Excels<\/h2>\n
      At this point, OKF sounds like an ideal solution for organising knowledge. It preserves relationships between concepts, keeps everything version-controlled, and allows AI agents to navigate curated documentation without relying on semantic search.<\/p>\n
      However, OKF has an important limitation. Someone has to curate every concept.<\/p>\n
      Every policy, procedure, system, metric, and department must be written, reviewed, and maintained. This works well for authoritative organisational knowledge, but it becomes impractical when the knowledge base grows to millions of documents.<\/p>\n
      Consider a hospital that has accumulated years of operational data.<\/p>\n