Open Knowledge Format (OKF): Der offene Standard, der Ihr KI-Wissen aus den Silos befreit

Jeder, der 2026 einen KI-Agenten ins Unternehmen bringt, stößt früher oder später auf dieselbe Wand: Das Modell ist gut, die Werkzeuge funktionieren – aber das Wissen, das der Agent braucht, liegt verstreut in Confluence, SharePoint, Notion, Code-Kommentaren, BigQuery-Schemata und im Kopf eines erfahrenen Kollegen. Genau dieses Problem adressiert das Open Knowledge Format (OKF), das Google Cloud am 12. Juni 2026 als offene Spezifikation veröffentlicht hat. In diesem Beitrag erklären wir, was OKF ist, welchen konkreten Mehrwert es bietet und wie Sie es in Ihrem Unternehmen einsetzen.

Das Problem, das OKF löst: Context Assembly

Bevor ein KI-Agent eine Aufgabe erledigen kann, muss er Kontext einsammeln – das relevante Wissen aus all den Systemen, in denen es liegt. Google Cloud nennt das das Context-Assembly-Problem, und es ist die unsichtbare Hauptarbeit hinter jedem Agentenprojekt. Das interne Wissen, das ein Modell braucht, ist über inkompatible Systeme verteilt:

• Metadaten-Kataloge mit proprietären APIs
• Wikis, Drittsysteme und geteilte Laufwerke
• Code-Kommentare, Docstrings, Notebook-Zellen
• implizites Erfahrungswissen, das nirgends dokumentiert ist

Die Folge beschreiben die Autoren bei Google Cloud treffend: „Jeder Agenten-Entwickler löst dasselbe Context-Assembly-Problem von Neuem, jeder Katalog-Anbieter erfindet dieselben Datenmodelle neu, und das Wissen selbst bleibt hinter der Oberfläche eingesperrt, die es erzeugt hat." Es fehlt schlicht ein gemeinsames Format, in dem Wissen einmal geschrieben und von jedem Agenten gelesen werden kann.

Was ist das Open Knowledge Format?

OKF ist ein herstellerneutraler, offener Standard, der Metadaten, Kontext und kuratiertes Wissen so beschreibt, dass sowohl Menschen als auch KI-Agenten es lesen können. Die zentrale Designentscheidung: OKF ist ein Format, kein weiterer Dienst. Es gibt kein Konto, kein SDK, keine Plattform, an die man sich bindet.

Veröffentlicht wurde die Version 0.1 von Sam McVeety und Amir Hormati (beide Tech Leads im Bereich Data Analytics bzw. BigQuery bei Google Cloud) auf dem Google Cloud Blog. Spezifikation, drei Beispiel-Bundles und zwei Referenzimplementierungen liegen offen auf GitHub.

Das Prinzip lässt sich in drei Worten zusammenfassen:

• Nur Markdown – lesbar in jedem Editor, gerendert auf GitHub, indexierbar von jedem Suchwerkzeug.
• Nur Dateien – versendbar als Tarball, hostbar in jedem Git-Repository, einhängbar auf jedem Dateisystem.
• Nur YAML-Frontmatter – für die kleine Menge strukturierter Felder, die abfragbar sein müssen.

Kein Binärformat, keine Datenbank, kein Lock-in. Wer schon einmal ein Markdown-File geschrieben hat, kann OKF lesen und schreiben.

Wie eine OKF-Datei aufgebaut ist

Jedes Konzept – eine Tabelle, eine Kennzahl, ein Prozess, eine Richtlinie – ist genau eine Markdown-Datei mit zwei Teilen: einem YAML-Frontmatter-Block und einem freien Markdown-Text. Das einzige verpflichtende Feld ist type. Alles andere ist empfohlen, aber optional:

---
type: BigQuery Table
title: Orders
description: Eine Zeile pro abgeschlossener Kundenbestellung.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---

# Schema
...

# Beispiele
...

# Quellen
...

Die empfohlenen Felder sind title, description, resource (eine URI, die das zugrunde liegende Asset identifiziert), tags und timestamp (ISO 8601). Die Spezifikation erlaubt ausdrücklich beliebige weitere Felder – Konsumenten müssen unbekannte Felder erhalten und dürfen ein Bundle nicht ablehnen, nur weil ein optionales Feld fehlt oder ein type unbekannt ist. Diese Toleranz ist bewusst gewählt: Sie macht OKF erweiterbar, ohne dass es ein zentrales Register braucht.

Ein Bundle ist einfach ein Verzeichnis dieser Dateien. Zwei Dateinamen sind reserviert: index.md listet den Inhalt eines Ordners auf (für progressive Offenlegung, damit ein Agent die Hierarchie erkundet, ohne jede Datei zu öffnen), und log.md hält die chronologische Änderungshistorie fest.

sales/
├── index.md
├── datasets/
│   ├── index.md
│   └── orders_db.md
├── tables/
│   ├── index.md
│   ├── orders.md
│   └── customers.md
└── metrics/
    ├── index.md
    └── weekly_active_users.md

Konzepte verlinken sich untereinander mit gewöhnlichen Markdown-Links. Aus dem flachen Verzeichnis entsteht so ein Wissensgraph, der reicher ist als die Ordnerstruktur – die Beziehung selbst steht im Fließtext, nicht in einem starren Schema.

Welchen Mehrwert OKF bietet

Der eigentliche Wert von OKF liegt nicht in einer einzelnen Funktion, sondern in den Konsequenzen aus „nur Markdown, nur Dateien":

Portabel. Wissen überlebt den Wechsel zwischen Systemen, Teams und Werkzeugen. Wenn Sie von einem Katalog-Anbieter zum nächsten wechseln, ziehen Ihre OKF-Bundles einfach mit. Kein Export-Import-Drama, kein proprietäres Format.

Versionierbar. OKF lebt in Git – neben dem Code, den es beschreibt. Jede Änderung am Wissen ist ein Commit: nachvollziehbar, reviewbar, rückrollbar. Wissensmanagement bekommt endlich dieselbe Disziplin wie Softwareentwicklung.

Doppelt lesbar. Dieselbe Datei liest ein Mensch im Editor und ein Agent als Kontext – ohne Übersetzungsschicht. Was Ihr Team pflegt, sieht der Agent. Was der Agent nutzt, kann Ihr Team prüfen.

Interoperabel. Ein Bundle, das Team A schreibt, kann Agent B konsumieren, ohne dass jemand eine Integration baut. Produzent und Konsument sind sauber getrennt; die Werkzeuge auf beiden Seiten sind austauschbar.

Kein Vendor-Lock-in. OKF ist an keinen Cloud-Anbieter, keine Datenbank, kein Modell und kein Agenten-Framework gebunden. Das ist der entscheidende Unterschied zu proprietären Wissens-Plattformen – und für uns bei innFactory ein zentrales Argument.

Andrej Karpathy bringt im Google-Blog auf den Punkt, warum gerade Sprachmodelle dieses dateibasierte Wissen pflegen können: „LLMs langweilen sich nicht, vergessen keine Querverweise zu aktualisieren und können in einem Durchgang 15 Dateien anfassen. Genau die Buchhaltung, an der Menschen ihre persönlichen Wikis scheitern lassen, ist das, worin LLMs gut sind."

OKF im Kontext: MCP, A2A und agenticweb.md

OKF ersetzt keines der bestehenden Agenten-Protokolle – es ergänzt sie. Wer unser Agentic-AI-Whitepaper gelesen hat, kennt die Landkarte: Das Model Context Protocol (MCP) regelt, wie ein Agent auf Werkzeuge und Datenquellen zugreift. A2A regelt, wie Agenten untereinander kommunizieren. OKF beantwortet die dritte Frage: Was weiß der Agent eigentlich – und in welchem Format liegt dieses Wissen?

Anders gesagt: MCP ist die Steckdose, OKF ist der Inhalt, der durchfließt. Ein MCP-Server kann ein OKF-Bundle als Wissensquelle bereitstellen; ein Agent zieht sich daraus den Kontext, den er für seine Aufgabe braucht.

Für uns ist das keine Überraschung, sondern Bestätigung eines Trends, den wir früh adressiert haben. Mit agenticweb.md haben wir Markdown bereits als das natürliche Format beschrieben, in dem Websites ihr Wissen an KI-Agenten übergeben. OKF überträgt dieselbe Idee nach innen – auf das organisationsinterne Wissen. Markdown setzt sich als gemeinsame Sprache zwischen Menschen und Agenten durch, draußen im Web wie drinnen im Unternehmen.

Wie Sie OKF im Unternehmen einsetzen

OKF ist bewusst niedrigschwellig. Google Cloud liefert die Spezifikation nicht als trockenes Dokument, sondern mit lauffähigen Werkzeugen:

1. Enrichment Agent – ein Referenz-Agent, der ein BigQuery-Dataset durchläuft, OKF-Dokumente für Tabellen und Views entwirft und sie per LLM-Durchgang mit Beschreibungen, Schemata, Join-Pfaden und Quellenangaben anreichert. So entsteht ein erster Wissensstand automatisch, statt jede Datei von Hand zu schreiben.
2. Static HTML Visualizer – wandelt ein beliebiges OKF-Bundle in eine interaktive Graph-Ansicht um. Eine einzelne, in sich geschlossene HTML-Datei, kein Backend, keine Daten verlassen den Browser.
3. Drei Beispiel-Bundles (GA4-E-Commerce, Stack Overflow, Bitcoin Public Datasets), an denen Sie die Struktur direkt nachvollziehen können.

Für einen konkreten Einstieg im eigenen Unternehmen empfehlen wir diesen Weg:

• Klein anfangen. Wählen Sie eine einzige, klar abgegrenzte Wissensdomäne – etwa Ihr wichtigstes Daten-Dataset, einen Kernprozess oder die zentralen Kennzahlen einer Abteilung.
• Bundle generieren oder schreiben. Nutzen Sie für Datenquellen den Enrichment-Ansatz, für Prozesse und Richtlinien schreiben Sie die Konzepte als Markdown direkt nieder. Jedes Konzept eine Datei, sauber verlinkt.
• In Git versionieren. Legen Sie das Bundle neben den zugehörigen Code oder in ein dediziertes Wissens-Repository. Pflege läuft ab jetzt über Pull Requests und Reviews.
• An den Agenten anbinden. Stellen Sie das Bundle über einen MCP-Server oder direkt als Dateikontext bereit. Ihr Agent – oder Ihre CompanyGPT-Instanz mit companyRAG – nutzt es als kuratierte, geprüfte Wissensbasis statt als roher Dokumenten-Dump.
• Iterieren. Erweitern Sie das Bundle Domäne für Domäne. Weil das Format tolerant ist, wächst es mit, ohne dass Sie alles neu modellieren.

OKF, Datensouveränität und DSGVO

Dass OKF ein Format und keine Plattform ist, hat eine direkte Konsequenz für Compliance und Souveränität: Ihr Wissen verlässt nie Ihre Kontrolle. Die Dateien liegen in Ihrem Git, auf Ihrer Infrastruktur, in Ihrer Jurisdiktion. Es gibt keinen Anbieter, der zwingend mitliest, kein US-Cloud-Konto, durch das Ihre internen Definitionen laufen müssen. Genau das macht OKF anschlussfähig an einen souveränen, DSGVO-konformen KI-Stack, wie wir ihn bei innFactory bauen.

Wer Wissen ohnehin versioniert in Git hält und über eine selbst gehostete Plattform an Agenten anbindet, behält die volle Hoheit – und kann jederzeit nachweisen, welches Wissen ein Agent zu welchem Zeitpunkt genutzt hat. Für regulierte Branchen ist diese Nachvollziehbarkeit kein Nice-to-have, sondern Voraussetzung.

Fazit und Handlungsempfehlung

Das Open Knowledge Format ist kein lautes Produkt-Launch, sondern eine ruhige, kluge Infrastruktur-Entscheidung. Es löst ein Problem, das jedes Agentenprojekt hat, mit den einfachsten denkbaren Mitteln: Markdown, Dateien, ein wenig YAML. Der Mehrwert ist Portabilität, Versionierbarkeit, Interoperabilität und – für den deutschen Mittelstand entscheidend – Unabhängigkeit von jedem einzelnen Anbieter.

Unsere Empfehlung: Warten Sie nicht auf die Version 1.0. OKF v0.1 ist bewusst minimal und genau deshalb sofort einsetzbar. Wählen Sie eine Wissensdomäne, erzeugen Sie ein erstes Bundle, legen Sie es in Git – und prüfen Sie, wie viel besser Ihr Agent mit kuratiertem statt rohem Wissen arbeitet. Der Aufwand ist gering, der Lerneffekt groß.

Sie wollen Agentic AI auf eine saubere Wissensbasis stellen – DSGVO-konform und ohne Lock-in? Die KI-Strategie-Beratung von innFactory hilft Ihnen, OKF, MCP und einen souveränen AI-Stack zu einem tragfähigen Konzept zu verbinden. Sprechen Sie uns an – wir klären in einem Erstgespräch, wo in Ihrem Unternehmen das Context-Assembly-Problem am meisten kostet und wie OKF dort konkret hilft.

Häufige Fragen zum Open Knowledge Format (OKF)

Was ist das Open Knowledge Format (OKF)? OKF ist ein offener, herstellerneutraler Standard von Google Cloud (veröffentlicht am 12. Juni 2026), der organisatorisches Wissen als Verzeichnis von Markdown-Dateien mit YAML-Frontmatter beschreibt – lesbar für Menschen und KI-Agenten zugleich.

Welches Feld ist in einer OKF-Datei verpflichtend? Nur das Feld type. Empfohlen, aber optional sind title, description, resource, tags und timestamp. Konsumenten müssen unbekannte Felder und Typen tolerant behandeln.

Ersetzt OKF das Model Context Protocol (MCP)? Nein. MCP regelt den Zugriff eines Agenten auf Werkzeuge und Daten, OKF beschreibt das Wissen selbst. Beide ergänzen sich: Ein MCP-Server kann ein OKF-Bundle als Wissensquelle bereitstellen.

Ist OKF DSGVO-konform einsetzbar? Ja. Weil OKF ein reines Dateiformat ohne Anbieter-Bindung ist, bleiben Ihre Wissensdateien in Ihrem Git, auf Ihrer Infrastruktur und in Ihrer Jurisdiktion. Das macht OKF zu einem guten Baustein für einen souveränen KI-Stack.

Wie fange ich mit OKF an? Wählen Sie eine einzelne Wissensdomäne, erzeugen oder schreiben Sie ein Bundle aus Markdown-Konzepten, versionieren Sie es in Git und binden Sie es über MCP oder als Dateikontext an Ihren Agenten an. Google Cloud liefert auf GitHub einen Enrichment-Agenten, einen Visualizer und drei Beispiel-Bundles als Startpunkt.