Google Open Knowledge Format (OKF): Der offene Standard, der KI-Agenten dein Unternehmenswissen gibt

TL;DR: Das Open Knowledge Format (OKF) ist eine offene, herstellerneutrale Spezifikation von Google Cloud, die Unternehmenswissen für KI-Agenten standardisiert. Veröffentlicht am 12. Juni 2026 vom BigQuery-Team als Version 0.1 (Draft), formalisiert OKF Andrej Karpathys Idee des „LLM Wiki“. Ein OKF-Bundle ist nichts weiter als ein Ordner aus Markdown-Dateien: Jede Datei beschreibt genau ein Konzept (eine Tabelle, eine Metrik, ein Runbook), der Dateipfad ist seine Identität, und das einzige Pflichtfeld ist type. Kein SDK, keine Datenbank, keine Runtime. Das Leitprinzip: „If you can cat a file, you can read OKF; if you can git clone a repo, you can ship it.“ OKF ersetzt weder RAG noch das Model Context Protocol, sondern ergänzt beide zum sogenannten AI Context Stack.

Was ist das Open Knowledge Format?

Moderne Sprachmodelle sind brillant, scheitern im Unternehmen aber regelmäßig am fehlenden Kontext. Ein Modell schreibt fehlerfreies SQL, weiß aber nicht, was deine wöchentlich aktiven Nutzer letzte Woche waren, welche Tabellen es joinen muss oder wie eine Geschäftsmetrik definiert ist. Dieses Wissen liegt verstreut: in Wikis, in Code-Kommentaren, in Metadatenkatalogen mit eigenen APIs und in den Köpfen einzelner Senior-Entwickler. Jeder neue Agent muss sich das alles von Grund auf neu zusammensuchen, was Halluzinationen begünstigt. OKF setzt genau hier an. Statt einen weiteren Dienst zu bauen, schlägt Google ein Format vor, das jeder ohne SDK erzeugen und ohne Integration lesen kann. Dieselbe Datei dient dem Menschen zum Lesen und dem Agenten zum Auswerten, ganz ohne Übersetzungsschicht. Es ist eine vendor-neutrale, agenten- und menschenfreundliche Konvention für die Metadaten, den Kontext und das kuratierte Wissen, das KI-Systeme brauchen.

Wer hat OKF entwickelt?

OKF stammt von Google Cloud, federführend aus dem BigQuery- und Data-Analytics-Team rund um Sam McVeety und Amir Hormati. Die Spezifikation wurde am 12. Juni 2026 im offiziellen Ankündigungsartikel „How the Open Knowledge Format can improve data sharing“ vorgestellt und liegt quelloffen auf GitHub als Version 0.1 Draft im Knowledge-Catalog-Repository. Binnen weniger Wochen sammelte das Repository rund 5.600 GitHub-Stars.

Der Ursprung: Karpathys LLM Wiki

OKF erfindet das Muster nicht, sondern schreibt es als Standard fest. Im April 2026 skizzierte Andrej Karpathy, Mitgründer von OpenAI und früherer KI-Chef bei Tesla, in einem GitHub-Gist die Idee des LLM Wiki. Sie dreht das klassische RAG-Prinzip um: Statt dass das Modell bei jeder Frage alles neu herleitet, baust du das Wissen einmal in einen Ordner verlinkter Textdateien, den das Modell wie eine Codebasis navigiert. Den Kern fasst Karpathy so: „Obsidian ist die IDE, das Modell ist der Programmierer, das Wiki ist die Codebasis.“ Wie dieses Muster in der Praxis aussieht, zeigt der Beitrag zum LLM Wiki als Architekturmuster.

Wie ist ein OKF-Bundle aufgebaut?

Ein OKF-„Bundle“ ist bewusst minimal gehalten und nutzt vorhandene Webstandards. Es kann auf GitHub gehostet, als Zip-Datei geteilt oder direkt neben dem Code versioniert werden.

Concept-Dateien und das type-Feld

Ein Bundle ist schlicht ein Verzeichnis aus Markdown-Dateien. Jede Datei beschreibt genau ein Konzept: eine Datenbanktabelle, einen Datensatz, eine API, eine Geschäftsmetrik, ein Runbook oder ein Playbook. Der Dateipfad ist die Identität des Konzepts, etwa tables/orders.md. Oben in jeder Datei sitzt ein kleiner YAML-Block, darunter folgt der Markdown-Text. Aus allen Frontmatter-Feldern ist genau eines verpflichtend: type, das die Art des Konzepts angibt (zum Beispiel „BigQuery Table“ oder „Metric“). Optional, aber empfohlen sind title, description, tags, timestamp und besonders resource – ein URI, der auf das reale Asset zeigt, also die echte Tabelle oder API. Der Markdown-Teil erklärt, was das Konzept bedeutet; das resource-Feld sagt, wo es lebt.

index.md, log.md und Progressive Disclosure

Konzepte verweisen mit gewöhnlichen Markdown-Links aufeinander. So wird aus dem flachen Ordner ein Graph: Eine Metrik zeigt auf ihre Tabelle, die Tabelle auf ihren Datensatz. Zwei reservierte Dateinamen helfen beim Navigieren. Eine index.md gibt einen Überblick über die Inhalte eines Verzeichnisses, damit ein Agent sich schrittweise vorarbeiten kann. Eine log.md hält Änderungen chronologisch fest. Dieses Prinzip heißt Progressive Disclosure: Der Agent muss nicht das ganze Verzeichnis blind durchsuchen. Er liest zuerst den Index, entscheidet anhand der YAML-Metadaten, welche Datei relevant ist, und öffnet nur diese eine. Bei einem Unternehmen mit tausenden Concept-Dateien spart das massiv Tokens und beschleunigt den Abruf, weil der Agent die übrigen 9.000 Dateien überspringt.

Die drei Designprinzipien

Der Standard ruht auf drei Säulen: - „If you can cat a file, you can read OKF“: Keine Datenbank, keine Runtime, kein SDK. Wer eine Textdatei lesen oder ein Repo klonen kann, kann das Format nutzen. Es lebt in Git, lässt sich diffen, im Pull Request reviewen und einem Modell offline auf dem Laptop übergeben. - Minimally opinionated: OKF definiert das Interoperabilitäts-Format, nicht das inhaltliche Modell. Lesende Tools müssen ausdrücklich tolerant sein und unbekannte Felder, kaputte Links und sogar nicht parsebare Dateien verzeihen. - Format statt Plattform: OKF ist an keine Cloud, Datenbank oder kein Agent-Framework gebunden. Der Wert eines Wissensformats kommt daraus, wie viele Parteien es sprechen, nicht daraus, wem es gehört.

Wie passt OKF zu RAG und MCP?

OKF ist kein Ersatz, sondern ein Baustein. Erst im Zusammenspiel mit Retrieval-Augmented Generation (RAG) und dem Model Context Protocol (MCP) ergibt sich das vollständige Bild.

OKF plus RAG: der 80/20-Split

Die häufigste Frage lautet, ob OKF das klassische RAG überflüssig macht. Die Antwort ist nein. Beide adressieren unterschiedliche Probleme, und die Architektur, die sich durchsetzt, kombiniert sie über einen Router. Eine treffende Faustregel ist der 80/20-Split: OKF trägt die kanonischen 80 Prozent des Wissens, also unternehmenskritische Fakten wie eine Rückgabefrist oder eine Metrik-Definition, bei denen die Antwort exakt stimmen muss. RAG übernimmt die unstrukturierten 20 Prozent, den Long Tail aus hunderttausenden Support-Tickets, Verträgen oder PDFs, den du niemals von Hand kuratieren könntest. Konkret: Ein Support-Agent beantwortet die Frage „Wie lang ist unsere Rückgabefrist?“ deterministisch aus OKF („14 Tage, Policy verlinkt“). Die Frage „Hatte schon mal jemand diesen seltsamen Abrechnungsbug?“ geht an RAG, das 40.000 alte Tickets durchsucht. OKF liefert die Präzision, RAG die Reichweite. Existiert ein kuratiertes Konzept, vertraut der Agent diesem mehr als einem unscharf abgerufenen Chunk, was Halluzinationen messbar reduziert.

OKF plus MCP: der AI Context Stack

OKF und das Model Context Protocol sind ebenfalls keine Rivalen, sondern bilden zusammen den AI Context Stack. Die Rollenverteilung: | Schicht | Rolle | Aufgabe | |---------|-------|---------| | OKF | Das Gedächtnis (die Karte) | Dauerhaftes, kuratiertes Wissen: Was bedeutet eine Tabelle oder Metrik? | | MCP | Die Hände (das Auto) | Live-Zugriff: Query ausführen, Ticket anlegen, frische Daten holen. | Im Ablauf öffnet der Agent das OKF-Konzept zu „wöchentlich aktive Nutzer“, liest die Definition und den exakten Join, greift die resource-URI ab und übergibt sie an MCP, das die Query gegen das Live-Warehouse fährt. OKF macht die Antwort korrekt, MCP macht sie aktuell. Da MCP auch lesbare Ressourcen ausspielen kann, lässt sich ein ganzes OKF-Bundle sogar über einen MCP-Server bereitstellen.

Wo liegen die Grenzen von OKF?

So elegant das Format ist, es hat klare Schwächen, die du kennen solltest, bevor du darauf setzt. OKF skaliert sich nicht selbst. Jedes Konzept ist menschliche Kurationsarbeit. Für riesige, unstrukturierte Datenberge ist das Format ungeeignet, dafür gibt es RAG. Das Wissen veraltet. Die Pointe des LLM-Wiki-Gedankens ist, dass das Modell die Buchhaltung übernimmt, die Menschen immer vernachlässigen. Doch die Spezifikation enthält keinen Mechanismus, der irgendetwas aktuell hält. Es gibt ein timestamp-Feld, aber ein Feld ist kein Prozess. In einem geteilten Team-Ordner, den niemand pflegt, antwortet der Agent nach einem Monat aus veraltetem Wissen. Das „Messy Librarian“-Problem. Sprachmodelle schreiben in der Praxis kein fehlerfreies Markdown im großen Maßstab. Sie erfinden Links zu nicht existierenden Dateien oder verhauen Überschriften. Googles „Lösung“ ist, dass lesende Tools diese Fehler tolerieren müssen, also Schadensbegrenzung mit nettem Namen. OKF standardisiert den Container, nicht die Bedeutung. Das einzige Pflichtfeld type ist freier Text. Schreibt Team A „BigQuery Table“ und Team B nur „Table“, sprechen sie semantisch verschiedene Sprachen. Die inhaltliche Einigung bleibt an dir hängen.

Welche Tools gehören zu OKF?

Den Werkzeugkasten hält Google bewusst offen, liefert aber Referenzimplementierungen mit: - Knowledge Catalog: Googles eigener Datenkatalog wurde so erweitert, dass er OKF importieren und Agenten ausspielen kann. - Enrichment Agent: Ein Referenzwerkzeug für BigQuery, das Datenbanken analysiert, OKF-Dateien automatisch generiert und sie via Gemini mit Schema-Infos und Zitaten anreichert. - Statischer HTML-Visualizer: Ein Tool ohne Backend, das ein Bundle lokal als interaktiven Wissensgraphen darstellt. - Beispiel-Bundles: Referenz-Bundles für GA4-E-Commerce, Stack Overflow und öffentliche Bitcoin-Datensätze. Diese Werkzeuge sind ausdrücklich als Proofs of Concept gedacht. Nichts am Format verlangt ein bestimmtes Agent-Framework, ein bestimmtes LLM oder eine HTML-Ansicht.

Ist OKF relevant für SEO und GEO?

Kurz: noch nicht direkt. OKF ist aktuell ein rein internes Format, das im Repo oder Data Warehouse lebt. Weder der Googlebot noch der GPTBot crawlen OKF-Bundles, und es ist kein SEO-Trick, um Zitate in KI-Antworten zu erzwingen. Konzeptionell steht OKF der Generative Engine Optimization aber sehr nah. Beide belohnen maschinenlesbares, sauber strukturiertes und mit Quellen belegtes Wissen. Auf öffentlichen Websites existiert mit der llms.txt-Datei bereits ein nach außen gerichtetes Pendant. OKF ist im Grunde dessen interne Variante. Manche Experten spekulieren, dass Websites künftig zusätzlich OKF-Bundles bereitstellen könnten, damit Such-Agenten ihre Inhalte effizienter abfragen, auch wenn das vorerst Zukunftsmusik ist. Für SEO-Teams gibt es schon heute einen praktischen Nutzen: Du kannst Kundenbriefings, Keyword-Maps oder Redaktionsrichtlinien als OKF-Bundle bündeln, damit deine internen KI-Agenten konsistent auf demselben Wissensstand arbeiten. Wer das Prinzip weiterdenkt, landet schnell bei verwandten Ansätzen wie dem Wissensgraphen fürs KI-Coding.

Wie startest du mit OKF?

Die Einstiegshürde ist niedrig, weil keine Infrastruktur wie eine Vektordatenbank nötig ist. 1. Ordner anlegen. Ein OKF-Bundle ist ein normales Verzeichnis. 2. Konzepte als Markdown schreiben. Eine .md-Datei pro Konzept; der Dateipfad ist die Identität. 3. YAML-Frontmatter ergänzen. Pflicht ist nur type; empfohlen sind title, description, resource, tags und timestamp. 4. Dateien verlinken. Mit normalen Markdown-Links, sodass ein Wissensgraph entsteht. 5. index.md und log.md anlegen. Als Inhaltsverzeichnis und Änderungshistorie pro Ordner. 6. In Git versionieren. Das Bundle wird gepflegt wie gewöhnlicher Code. Den Bundle-Build kannst du an ein Modell delegieren, ganz im Sinne der Obsidian-Second-Brain-Methode von Karpathy. Die Pflege bleibt aber eine bewusste, menschlich verantwortete Aufgabe.

FAQ: Häufig gestellte Fragen zum Open Knowledge Format

Was ist das Open Knowledge Format (OKF)? OKF ist eine offene, herstellerneutrale Spezifikation von Google Cloud, die Unternehmenswissen als Ordner aus Markdown-Dateien für KI-Agenten strukturiert. Jede Datei beschreibt ein Konzept, das einzige Pflichtfeld im YAML-Frontmatter ist type. Wann wurde OKF veröffentlicht und in welcher Version? Google Cloud hat OKF am 12. Juni 2026 als Version 0.1 (Draft) vorgestellt. Die Spezifikation liegt quelloffen im GitHub-Repository GoogleCloudPlatform/knowledge-catalog. Ersetzt OKF RAG? Nein. OKF und RAG ergänzen sich. OKF trägt die kanonischen, hochkritischen Fakten (rund 80 Prozent), RAG durchsucht den unstrukturierten Long Tail (rund 20 Prozent). Ein Router entscheidet pro Anfrage, welche Schicht antwortet. Was ist der Unterschied zwischen OKF und MCP? OKF ist das Gedächtnis des Agenten: dauerhaftes, kuratiertes Wissen darüber, was Dinge bedeuten. MCP ist der Live-Zugriff auf Tools und Daten. Zusammen bilden sie den AI Context Stack: OKF macht Antworten korrekt, MCP macht sie aktuell. Hilft OKF beim SEO oder bei der Sichtbarkeit in KI-Suchen? Aktuell nicht direkt. OKF ist ein internes Format und wird von Suchmaschinen-Crawlern nicht ausgewertet. Konzeptionell ähnelt es aber GEO und der llms.txt-Logik, weil es maschinenlesbares, strukturiertes Wissen belohnt. Aktualisiert sich ein OKF-Bundle von selbst? Nein. Die Spezifikation bietet außer einem timestamp-Feld keinen Mechanismus zur automatischen Aktualisierung. Ohne klare Verantwortlichkeit veraltet das Wissen in geteilten Ordnern schnell. Brauche ich Google Cloud, um OKF zu nutzen? Nein. Das Format ist vendor-neutral und besteht nur aus Textdateien in Git. Du kannst es ohne Google-Cloud-Projekt, ohne SDK und ohne Datenbank erzeugen und lesen.

Fazit

Das Open Knowledge Format gießt ein bewährtes Community-Muster in einen offenen Standard: Unternehmenswissen als kuratierter Ordner aus Markdown-Dateien, den Mensch und Agent gleichermaßen lesen. Seine Stärke ist die radikale Einfachheit, seine Grenze die fehlende Selbstpflege. Wer KI-Agenten produktiv einsetzt, sollte OKF nicht als RAG-Killer verstehen, sondern als kuratiertes Rückgrat im AI Context Stack, ergänzt durch RAG für die Reichweite und MCP für den Live-Zugriff. Tiefer einsteigen kannst du über das LLM Wiki als Architekturmuster, die Obsidian-Second-Brain-Methode und die Grundlagen der Generative Engine Optimization. Verifizierte Quellen: Open Knowledge Format Spec v0.1 (GoogleCloudPlatform/knowledge-catalog), Google-Cloud-Blog „How the Open Knowledge Format can improve data sharing“ (12.06.2026), Andrej Karpathy LLM-Wiki-Gist.