Open Knowledge Format: Tragbare Speicherlösung für KI-Programmieragenten
Das Open Knowledge Format speichert das, was KI-Modelle lernen, als vernetzte Markdown-Dateien. Wie es sich von CLAUDE.md und MCP unterscheidet und wie man es bereits heute nutzen kann.
Quellen: Google Just Quietly Released the Missing Piece for AI Agents. It’s Called OKF.
Das Open Knowledge Format ist ein Standard, der darauf abzielt, das Gedächtnis von Agenten portabel, versioniert und für alle Tools in einem Entwicklerumfeld lesbar zu machen.
Das Problem des Neuanfangs jeden Morgen
Jeder, der einen KI-Codeagenten verwendet, ist bereits auf diese Hürde gestoßen. Die Sitzung wird beendet, und am nächsten Tag weiß der Agent nichts mehr. Er muss den Authentifizierungsablauf erneut durchlaufen, erneut über die Gründe einer vor drei Jahren getroffenen Architekturentscheidung rätseln und die gleichen fünf Dateien nochmals lesen, um den Kontext wiederherzustellen, den man am Vortag erst einmal stundenlang erklären musste.
Die gängige Workaround-Lösung sind Dateien wie CLAUDE.md oder AGENTS.md – Kontextdokumente, die zu Beginn jeder Sitzung geladen werden. Es handelt sich dabei um grobe Werkzeuge: Sie laden bei jedem Ausführungsvorgang alles hoch, egal ob es relevant ist oder nicht, sie sind für einen einzelnen Agenten auf einer einzigen Plattform konzipiert und funktionieren nicht gut. Zudem vermischen sie Verhaltensanweisungen wie „Schreibe immer Tests“ mit Fakten wie „Die Bestelltabelle wird über customer_id mit den Kunden verknüpft“, was schnell zu Unordnung führt.
Am 12. Juni 2026 veröffentlichte Google Cloud eine Spezifikation, die genau dieses Problem adressiert – das Open Knowledge Format oder OKF. Es ist bisher die ordentlichste Lösung für das Problem des Agenten-Speichers.
Wo Wissen heute gespeichert wird
Nehmen wir an, ein Agent muss beantworten, wie wöchentliche aktive Nutzer aus einem Ereignisstrom berechnet werden. Die Antwort ist auf mindestens vier Orten verteilt:
+-----------------------+--------------------------------------------+
| WHERE IT LIVES | WHAT'S THERE |
+-----------------------+--------------------------------------------+
| Metadata catalogs | Table schemas (but vendor-locked APIs) |
| Wiki / Notion | Runbooks, metric definitions |
| Code comments | Docstrings, inline notes |
| People's heads | Join paths, deprecation warnings |
+-----------------------+--------------------------------------------+
Hier bewegt sich nichts im Einklang mit dem Code, und nichts überdauert ein neues Kontextfenster. Jeder Agentenbauer löst erneut dasselbe Rätsel der Kontextzusammenstellung, und jeder Kataloganbieter entwickelt seine eigenen Schemata.
OKF ist der Ansicht, dass es an einem Format fehlt und nicht an einer weiteren Plattform.
Was das Format ist
Die Version 0.1 des Open Knowledge Formats ist eine offene, anbieterneutrale Spezifikation, die unter der Apache 2.0-Lizenz veröffentlicht wird. Wissen wird als Verzeichnis von Markdown-Dateien gespeichert, wobei jede Datei ein YAML-Frontmatter enthält. Es klingt einfach, weil es einfach ist – und das ist beabsichtigt.
Es gibt weder ein Schema-Registry noch einen Laufzeitmotor sowie kein erforderliches SDK. Alles, was eine Datei mit cat anzeigen kann, kann sie auch lesen, und alles, was einen Repository mit git clone kopieren kann, kann es auch bereitstellen. Die gesamte Spezifikation passt auf eine einzige Seite und weist genau ein erforderliches Feld auf, wobei alles Weitere optional ist oder vom Ersteller festgelegt werden kann.
Anatomie eines Bundles
Ein Bundle ist einfach nur ein Verzeichnis, und der Pfad einer Datei dient als Identifikator für ihr Konzept.
.okf/
+-- index.md <- progressive entry point
+-- log.md <- dated change history, newest first
+-- services/
| +-- index.md
| +-- auth-api.md <- one concept = one file
| +-- payments-service.md
+-- datasets/
| +-- index.md
| +-- orders-db.md
+-- metrics/
| +-- index.md
| +-- weekly-active-users.md
+-- decisions/
+-- index.md
+-- why-we-use-postgres.md
Zwei Dateinamen sind in jedem Bundle reserviert:
index.mdsteuert die schrittweise Offenlegung von Inhalten. Agenten durchlaufen ein Bundle, indem sie den Index auf jeder Ebene lesen und nur dann weitergehen, wenn die Aufgabe es erfordert. Das ist dieselbe schrittweise Ladeart, die dazu beiträgt, dass Claude Skills effizient mit Tokens umgeht.log.mdenthält eine Änderungshistorie mit ISO-Daten, wobei die neuesten Einträge zuerst angezeigt werden. Sowohl Menschen als auch Agenten, die das Bundle pflegen, fügen neue Einträge hinzu, wenn sich Konzepte ändern.
Jede andere Datei ist ein Konzeptdokument, das anhand seines Pfads identifiziert wird. Das einzige Frontmatter, das ein Konzept haben muss, ist ein nicht leeres type-Feld.
---
type: Service
title: "Auth API"
description: "Issues and verifies short-lived access tokens."
resource: https://github.com/acme/auth
tags: [auth, platform]
timestamp: 2026-06-14T10:00:00Z
---
Der Inhalt enthält anschließend gewöhnlichen Markdown, einschließlich Tabellen.
## Endpoints| Method | Path | Description |
|--------|----------|---------------------------|
| POST | /token | Exchange creds for a JWT. |
| GET | /verify | Validate a token. |## Why This ExistsSee the decision at [decisions/why-we-separated-auth.md](../decisions/why-we-separated-auth.md).
Joins with [datasets/orders-db.md](../datasets/orders-db.md) for user scoping.
Der entscheidende Gestaltungsaspekt folgt nun. Konzepte sind über standardmäßige Markdown-Links miteinander verbunden. Dadurch wird der Ordner zu einem Graphen – einer Sammlung strukturierten, gegenseitig verknüpften Wissens mit klaren Beziehungen, die man durchqueren kann – anstatt zu einem einfachen Haufen von Dokumenten.
[auth-api.md]
/ \
links links
/ \
[decisions/why-separated-auth.md] [datasets/orders-db.md]
|
links
|
[datasets/customers-db.md]
Ein Tool, das in der Lage ist, einen Markdown-Link zu verfolgen, kann das Graph durchqueren, und ein Agent mit Dateizugriff kann darin sowohl lesen als auch schreiben.
Da nur der type erforderlich ist, entscheidet der Ersteller, welche Typen vorhanden sind (Service, Dataset, Metric, Decision, Runbook usw.), welche optionalen Felder verwendet werden sollen und welche Abschnitte im Inhalt enthalten sein müssen. OKF definiert Interoperabilität und nicht Inhaltsmodelle.
Ersteller und Verarbeiter
Das Format funktioniert an beiden Enden auf dieselbe Weise, sodass ein Austausch des Erstellers oder Verarbeiters die Struktur der Daten nicht stört.
PRODUCERS CONSUMERS
--------- ---------
Human authors ----> AI agents
BigQuery pipelines ----> HTML visualizers
LLM-generated ----> Search indexes
Wiki exports ----> Other agents / tools
Es gibt kein proprietäres Konto, kein SDK und kein zentrales Register. Der Wert steigt durch die Breite der Adoption und nicht durch Vendor Lock-in. Das entspricht der Philosophie hinter Git, Markdown und JSON – Formaten, die bestehen geblieben sind, weil sie keinerlei Voraussetzungen für die Nutzung erforderten.
Beziehung zu CLAUDE.md und MCP
Die meisten Verwirrungen entstehen hier. OKF ersetzt keine bereits verwendeten Tools. Es schließt vielmehr eine bestimmte Lücke.
+---------------------+---------------------------+---------------------------+
| TOOL | PURPOSE | SCOPE |
+---------------------+---------------------------+---------------------------+
| CLAUDE.md | How the agent behaves | Per-project, one agent |
| AGENTS.md | Repo instructions | Per-repo, tool-specific |
| Karpathy LLM wiki | Agent-maintained notes | Pattern, not a spec |
| MCP | Live tool access | Runtime connections |
| OKF | What the team knows | Cross-project, any agent |
+---------------------+---------------------------+---------------------------+
Ein klares mentales Modell trennt drei Fragen voneinander:
- CLAUDE.md legt fest, wie sich der Agent verhalten soll.
- OKF gibt an, was das Team über dieses System weiß.
- MCP angibt, welche Live-Tools der Agent zu diesem Zeitpunkt aufrufen kann.
Sie bauen aufeinander auf. Eine Zeile in CLAUDE.md könnte vorschreiben, vor jeder Analysetätigkeit .okf/metrics/ zu lesen. Das OKF-Paket liefert anschließend das strukturierte Wissen, auf das CLAUDE.md verweist, und die MCP-Verbindungen stellen die Live-Datensätze bereit, die in den OKF-Dokumenten beschrieben werden.
Die Wiki-Idee, die damit verbunden ist
Andrej Karpathy, der den Begriff „Vibe Coding“ prägte und heute eher den Ausdruck „Agentic Engineering“ bevorzugt, veröffentlichte eine LLM-Wiki-Zusammenfassung, die mehr als 5.000 Sterne erhielt. Seine Argumentation ist einfach: Menschen geben Wikis auf, wenn deren Pflege zur lästigen Aufgabe wird, doch Agenten ermüden nicht daran, vergessen keine Verweise oder haben Schwierigkeiten, 15 Dateien auf einmal zu bearbeiten.
Das gleiche Muster tauchte unabhängig voneinander immer wieder auf – in Obsidian in Kombination mit Programmieragenten, in Repositorien voller AGENTS.md-Dateien sowie in index.md- und log.md-Dateien in Dutzenden von Projekten. Die Menschen erdachten dabei immer wieder dasselbe Konzept. Was OKF hinzufügt, ist eine Einigung darüber, welche Informationen jede Datei enthält und was die Dateinamen bedeuten, sodass separate Wikis sowie sogar eine Exportdatei aus BigQuery ohne Übersetzung zusammenarbeiten können.
Die Zuordnung zwischen den beiden Ebenen besteht aus drei Schichten:
KARPATHY LAYER OKF EQUIVALENT
-------------- --------------
Raw sources (immutable) --> External datasets, docs, APIs
(OKF bundles are the compiled layer)
Wiki (LLM-maintained) --> OKF bundle (*.md + frontmatter)
(OKF adds type, resource, tags, timestamp)Schema (CLAUDE.md) --> Producer/consumer conventions + okf/SPEC.md
(org-wide spec replaces per-vault bespoke rules)
Sowohl Karpathys Ansatz als auch OKF verwenden index.md und log.md für dieselben Aufgaben, und diese Übereinstimmung war kein Zufall.
Was Google dazu bereitgestellt hat
OKF ist eine Spezifikation, doch Google veröffentlichte zusammen damit drei praktische Komponenten:
- Einen BigQuery-Enrichment-Agenten. Dieser richtet sich auf ein Datensatz und erstellt für jede Tabelle sowie jeden View ein OKF-Konzeptdokument. Anschließend erfolgt eine zweite Verarbeitung durch ein LLM, das auf der Grundlage der Dokumentation Zitate, Schemata sowie Verknüpfungspfade hinzufügt. Das Ergebnis für ein Data Warehouse ist ein vollständig gefüllter
.okf/-Ordner. - Ein statischer HTML-Visualisierer. Er wandelt jedes OKF-Bundle in ein interaktives Diagramm in einer eigenständigen HTML-Datei um – ohne Backend und ohne dass etwas die Seite verlässt. Konzepte erscheinen als Knoten und Markdown-Links als Kanten; beim Klicken auf einen Knoten öffnet sich ein wikiähnliches Panel mit dargestelltem Markdown sowie Rücklinks, die als „Links zu / Zitiert von“ beschriftet sind.
- Beispieldateien. Drei echte Dateien auf GitHub verwenden öffentliche BigQuery-Datensätze:
+--------------------+----------------------------------+
| BUNDLE | WHAT IT DOCUMENTS |
+--------------------+----------------------------------+
| GA4 e-commerce | Analytics tables and metrics |
| Stack Overflow | Public dataset concepts |
| Bitcoin | Blockchain dataset structure |
+--------------------+----------------------------------+
Sie dienen sowohl als Ausgangsvorlagen zum Kopieren als auch als Beweis dafür, dass das Format über verschiedene Domänen hinweg funktioniert.
Wann OKF die richtige Wahl ist
Es eignet sich, wenn das Wissensproblem einem der folgenden Fälle entspricht:
- Die gleichen Erklärungen wiederholen sich in jeder neuen Agenten-Sitzung. Wenn ein Kontextblock immer wieder in CLAUDE.md eingefügt wird, gehört er in OKF.
- Das Wissen erstreckt sich über mehrere Projekte oder Teams. CLAUDE.md ist an ein Projekt und einen Agenten gebunden, während OKF-Bundles zwischen Repositories, Agenten und Tools übertragen werden können.
- Projektdokumente sollten versionierbar sein. OKF befindet sich im git neben dem von ihm beschriebenen Code; jede Änderung wird in einem Diff angezeigt, und ein Pull Request kann Wissensaktualisierungen zusammen mit Codeänderungen übertragen.
In einigen Fällen ist dies die falsche Wahl:
- Es werden Echtzeitdaten benötigt, wofür MCP erforderlich ist.
- Verhaltensregeln müssen kodiert werden, was zur Aufgabe von CLAUDE.md gehört.
- Das Projekt ist klein und passt in eine einzige Sitzung, wofür CLAUDE.md allein ausreicht.
Erste Schritte
Die Einrichtung ist aus Gründen der Einfachheit minimal.
Mit Claude Code
Das okf-skills-Plugin enthält drei Funktionen. /okf:okf erstellt und verwaltet Bundles, /okf:validate überprüft, ob ein Bundle den Anforderungen entspricht, und /okf:visualize erstellt das interaktive Diagramm. Installieren Sie es mit:
/plugin marketplace add scaccogatto/okf-skills
/plugin install okf@scaccogatto
Jeder Agent, einschließlich Claude Code, Cursor, Codex und mehr als zwanzig weiterer, kann stattdessen npm verwenden:
npx skills add scaccogatto/okf-skills
Dann führen Sie die Fähigkeiten aus:
/okf:okf produce .okf # create your first bundle
/okf:validate .okf --strict # check conformance
/okf:visualize .okf # generate viz.html
Um die Informationen automatisch auf dem neuesten Stand zu halten, sodass Claude vor den Aufgaben .okf/ liest und anschließend das Gelernte aufzeichnet, kopieren Sie das Template templates/CLAUDE-okf.md in das CLAUDE.md des Projekts. Es gibt nichts, was diesen Schritt erzwingt.
Manuelle Erstellung
Erstellen Sie ein Verzeichnis .okf/ und fügen Sie ein index.md hinzu. Fügen Sie anschließend ein Konzeptdatei für jede wichtige Funktion des Systems hinzu. Eine Entscheidungsprotokoll sieht so aus:
---
type: Decision
title: "Why we use Postgres over MySQL"
description: "JSONB support and row-level security were decisive."
timestamp: 2026-03-01T00:00:00Z
tags: [infrastructure, database]
---
Der Text folgt:
## ContextIn early 2026 we evaluated both options. MySQL's JSON support was insufficient for our metadata schema...## DecisionPostgres 16. See [datasets/primary-db.md](../datasets/primary-db.md) for schema docs.
Das ist alles, was benötigt wird. Jeder Agent mit Zugriff auf die Datei kann sie sofort lesen, und sie kann in einer Pull Request überprüft sowie in Git verglichen werden.
Der gesamte Stack
So steht OKF im Vergleich zu allen anderen Komponenten in einer Sitzung da:
+--------------------------------------------------+
| AGENT SESSION |
+--------------------------------------------------+
| CLAUDE.md / AGENTS.md |
| (behavioral rules - how agent acts) |
+--------------------------------------------------+
| OKF BUNDLE (.okf/) |
| (curated team knowledge - what we know) |
| - index.md: entry points per domain |
| - concepts/*.md: services, datasets, decisions |
| - log.md: change history |
+--------------------------------------------------+
| AUTO-MEMORY (memory.md) |
| (what the agent picked up implicitly) |
+--------------------------------------------------+
| MCP CONNECTIONS |
| (live tool access - what the agent can do) |
+--------------------------------------------------+
| SKILLS (.claude/skills/) |
| (reusable SOPs - how to do specific tasks) |
+--------------------------------------------------+
Jede Schicht beantwortet ihre eigene Frage. Sie überschneiden sich nicht, sondern ergänzen sich.
Was bei v0.1 ungelöst bleibt
Google bezeichnet v0.1 offen als Ausgangspunkt, wobei zunächst die Interoperabilität gelöst werden soll. Es bestehen weiterhin mehrere Designfragen:
- Widersprüche. Wenn zwei OKF-Dokumente sich bezüglich einer Tatsache nicht einigen, existieren noch keine Mergesemantiken.
- Veraltete Informationen. Da OKF auf Dateien basiert, ist ein unverändertes Dokument, wenn das System weiterentwickelt wird, ein Prozessfehler und kein Formatfehler.
- Typisierte Beziehungen. Die heutige Spezifikation verwendet einfache Markdown-Links, während umfangreichere Beziehungsarten wie „widerspricht“, „erweitet“ oder „ersetzt“ von der Community weiterentwickelt werden.
- Facettenbasierte Suche. Einige Anwender wünschen mehr Tagging als die minimale Spezifikation bietet.
V0.2 wird voraussichtlich aufgrund von Feedback mehrere dieser Probleme angehen, und das Spezifikations-Repository ist öffentlich und nimmt Issues sowie PRs entgegen.
Warum langweilige Formate gewinnen
Formate, die zur Infrastruktur werden, neigen dazu, langweilig zu sein. JSON hat gewonnen, weil es die einfachste Lösung war, die funktionierte und keine Anpassungen erforderte, nicht weil es besonders clever war. Markdown hat auf dieselbe Weise gewonnen.
OKF passt zu dieser Beschreibung. Es erfordert weder zum Lesen noch zum Schreiben etwas Besonderes und funktioniert mit jedem Tool, das mit Dateien umgehen kann. Der Wert steigt mit der Anzahl der Ersteller und Nutzer, und Entscheidungen eines einzelnen Anbieters bestimmen ihn nicht. Zudem festhält OKF ein Muster, das die Menschen bereits auf eigene Faust entwickelt hatten – durch Karpathys Gist, AGENTS.md-Habits sowie handgebaute index.md-Hierarchien – was der beste Beweis dafür ist, dass ein echtes Problem gelöst wird.
Karpathys Argument war, dass Agenten Wikis besser pflegen als Menschen, weil sie sich nicht langweilen. OKFs Argument lautet, dass ein Wiki nur dann an Wert gewinnt, wenn es sich verbreiten kann. Zusammen könnten diese beiden Ideen in einigen Jahren zu einem grundlegenden Element der agentenunterstützten Entwicklung werden. Wenn man sie jetzt aufbaut, solange sie noch neu sind, wird das später sowohl für einen selbst als auch für jeden Agenten, dem man Anweisungen gibt, Vorteile bringen.