okf context-engineering ai-agents documentation llm

Ihr KI-Agent benötigt keinen weiteren Kontext. Er braucht ein Gehirn, dem er vertrauen kann.

Wie das Open Knowledge Format Dokumente in einen abfragbaren Zustand mit Ablaufdaten, Überprüfungsmöglichkeiten und schrittweiser Ladenfunktion umwandelt, damit Agenten veraltete Dokumentationen nicht mehr vertrauen.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 23. Okt. 20269 Min. Lesezeit2162 Wörter

Quellen: **Your AI Agent Doesn’t Need More Context. It Needs a Company Brain It Can Trust**

Stellen Sie sich vor, ein Pager geht um 02:14 los. Sie öffnen das Handbuch – es sieht hervorragend aus, mit nummerierten Schritten, einem Diagramm und deutlichen Anzeichen dafür, dass sich jemand darum gekümmert hat. Sie befolgen Schritt 4 – doch es funktioniert nicht. Am unteren Rand der Seite entdecken Sie das Datum der letzten Bearbeitung: vor vierzehn Monaten.

Jeder Satz darin war zum Zeitpunkt der Erstellung korrekt. Doch es gab keinerlei Anzeichen dafür, dass er veraltet war.

Das ist das eigentliche Problem. Es fehlen nicht die Dokumente oder sie sind schlecht – es sind Dokumente, die selbst an ihrem schlechtesten Tag genauso vertrauenswürdig erscheinen wie am ersten Tag. Vierzig Jahre lang wurde Software unter der Annahme bereitgestellt, dass Dokumentation Prosa ist und der Leser selbst beurteilt. Dann wurden die Repositorien Agenten übergeben, die nichts beurteilen können und jedes Wort mit völligem Vertrauen lesen.

Was hat sich geändert

Ein KI-Agent hat kein eigenes Gedächtnis. Er ist zustandslos, und bei jedem Schritt wird das gesamte Gespräch von vorn gesendet. Anthropics Dokumentation formuliert es unverblümt: Jedes Mal muss die vollständige Gesprächshistorie übermittelt werden.

Wenn also eine Architekturdokumentation mit 4.000 Tokens in die Datei eingefügt wird, die ein Agent stets lädt, wird sie nicht einmal gelesen. In einer Sitzung mit vierzig Schritten wird sie vierzig Mal gelesen. Und das Laden kann die Leistung des Agents verschlechtern.

Chromas Forschung zu Kontextverlust prüfte 18 führende Modelle, darunter GPT, Claude, Gemini und Qwen, und stellte fest, dass die Genauigkeit mit zunehmender Länge der Eingabe abnimmt – in einigen Fällen von 95 % auf 60 %. Entscheidend ist, dass es sich hierbei nicht um einen Effekt am Limit handelt. Die Leistungsabnahme trat bei jedem von ihnen gemessenen Längenwert auf. Wenn diese Erkenntnisse zutreffen, leidet bereits bei fünfzigtausend Tokens eine Fenstergröße von einer Million Tokens, denn der Feind ist Rauschen und nicht die Kapazität.

Anthropic bezeichnet dies als Aufmerksamkeitsbudget: Der Kontext ist eine begrenzte Ressource mit abnehmenden Grenznutzen, und das Ziel ist die kleinste mögliche Menge an hochwertigen Tokens. Das lässt nur zwei schlechte Optionen übrig.

Alles laden. Der Agent kennt das System, ist aber bei jeder Aufgabe messbar langsamere, und jede Änderung an einem Dokument macht den gesamten Prompt-Cache ungültig und erzwingt eine Neuberechnung.
Nichts laden. Der Agent bleibt schnell, weiß aber nichts und muss improvisieren. Er erfindet einen BereitstellungsSchritt oder führt einen Befehl aus, der bereits im März zurückgezogen wurde.

Teams wählen eine Option, erleben die negativen Folgen und wechseln anschließend zur anderen. So sieht die Situation in der Branche derzeit ungefähr aus.

Es gibt bereits eine Diagnose in einem Satz

Im April 2026 veröffentlichte Andrej Karpathy einen kurzen Überblick, den er als Ideendatei bezeichnete. Es handelte sich dabei weder um ein Produkt noch um eine Bibliothek. Darin wurde ein Ansatz skizziert: Das Modell verarbeitet Rohmaterialien zu einer übersichtlichen, strukturierten Markdown-Wiki, und ab dann werden Fragen an diese Wiki statt an die ursprünglichen Quellen gerichtet.

Der entscheidende Satz darin hat nichts mit KI zu tun: Menschen geben Wikis auf, weil die Wartungsaufwände schneller zunehmen als der Nutzen.

Jeder, der schon gesehen hat, wie ein Confluence-Raum verschwindet, wird das erkennen. Die Leute haben nicht aufgegeben, weil das Schreiben schwierig war. Sie haben aufgegeben, weil die Wartung schwierig war – und Wartung besteht hauptsächlich aus administrativen Aufgaben: Den Link aktualisieren, die Zusammenfassung erneuern, markieren, dass diese Seite nun im Widerspruch zur anderen steht, den Index reparieren. Genau diese Arbeiten sind nicht mehr aufwendig, weil ein LLM sich nicht langweilt, keine Verweisen vergisst und in einem Durchgang fünfzehn Dateien bearbeiten kann. Seine Aufgabenteilung ist einfach: Man liest den Text, das LLM schreibt ihn.

Die Idee verbreitete sich schnell. Zwei Monate später veröffentlichte Google Cloud eine Spezifikation, die laut eigener Ankündigung das LLM-Wiki-Muster in ein portables, interoperables Format überführt. Die zugrundeliegende Diagnose stammt weiterhin von Karpathy – und das ist der Grund, warum all das heute funktioniert und 2019 nicht.

OKF in einer halben Minute

OKF, das Open Knowledge Format, wurde im Juni 2026 vom Data Cloud-Team von Google Cloud als Entwurf (v0.2) veröffentlicht und stellt ausdrücklich eine Formalisierung dieses Formats dar. Technisch gesehen handelt es sich um ein Verzeichnis von Markdown-Dateien mit YAML-Frontmatter – und das ist auch schon alles.

Die Spezifikation fasst ihre Vorzüge wie folgt zusammen: Alles, was eine Datei mit cat anzeigen kann, kann auch OKF lesen, und jeder, der in der Lage ist, ein Repository mit git clone zu kopieren, kann es verbreiten.

Nur ein Feld ist erforderlich: type. Eine Datei, die nur type enthält, gilt bereits als konform. Es werden weder ein Schema-Registry noch eine Datenbank, kein Embedding-Pipeline, kein Vendor-Lock noch ein SDK benötigt.

okf/
  index.md                  ← table of contents
  billing/
    index.md
    invoice-retries.md      ← one file, one answerable question
  flows/
    customer-offboarding.md

Falls Ihre Reaktion lautet „Also ein Ordner mit Markdown“, dann ist das zutreffend. Das Format ist nicht der interessante Teil, und es ist berechtigt, einzuwenden, dass ein Ordner keine Spezifikation benötigt. In Googles Ankündigung gibt es eine Antwort: Karpathys Wiki, das Wiki eines Teams sowie die Exportdatei eines Anbieters können alle ähnlich aussehen – mit Markdown, Frontmatter und Verknüpfungen –, doch keines davon wurde dafür konzipiert, miteinander zu arbeiten. Genau das ist der Grund für eine Spezifikation. Jeder hat unabhängig voneinander zu derselben Struktur gefunden, was in der Regel bedeutet, dass diese Struktur richtig ist; anschließend hat jede Implementierung ihre eigenen Feldnamen erfunden. Ein Format verwandelt mehrere private Konventionen in etwas, das ein Agent überall lesen kann.

Die Kernidee: Dokumentation wird zu Zustand

Hier ist ein Beispieldokument:

---
type: Playbook
title: Invoice retry policy
status: stable                      # draft | stable | deprecated
stale_after: 2026-11-01             # stale when today >= this date
generated: { by: "human:dana", at: 2026-08-10 }
verified:  [{ by: "human:sam",  at: 2026-08-11 }]
sources:
  - resource: services/billing/retry.go
    last_modified: 2026-07-15
not:
  - term: "restart the worker to clear the queue"
    why: "in-flight jobs are lost, they are not re-queued"
    instead: "drain first, then restart"
---

Fünf der angezeigten Felder stammen aus der Spezifikation. Das sechste ist am wertvollsten und kommt weiter unten erneut vor.

Ein Aktenschrank speichert einfach nur Dokumente. Ein Gehirn weiß ebenfalls, was es enthält, wie zuverlässig es ist und welche Fehler ihm etwas beigebracht haben. Die unten aufgeführten Elemente entsprechen diesem Prinzip:

Element	Was es für das Gehirn tut
index.md	Aufruf: Es weiß, was es bereits weiß, bevor es etwas öffnet
concept docs	Erinnerung: Jedes Dokument enthält eine Information
stale_after	Vergessen: Es weiß, wann eine Erinnerung ungenau geworden ist
verified	Vertrauensgrad: Es weiß, wessen Aussage eine Behauptung stützt
sources	Aufmerksamkeit: Es weiß, von welchen Dokumenten etwas abhängt
not:	„Narbengewebe“: Was auf die harte Tour gelernt wurde

Lesen Sie nun diesen Frontmatter so, wie es eine Maschine tun würde. stale_after ist ein Ablaufdatum. Es handelt sich dabei nicht um ein „letztes Update“-Zeichen, das von Menschen interpretiert werden muss. Es ist ein absolutes Datum, das die Veraltetheit in einen einfachen Vergleich verwandelt – today >= stale_after. Jeder kann diese Überprüfung durchführen: der Agent, der die Datei liest, ein geplanter Job oder Ihr CI-System.

Bleiben Sie dabei stehen. Die Veraltung von Dokumentation ist seit der Erfindung von Wikis ein kulturelles Problem. Ständige Erinnerungen, regelmäßige Dokumentations-Tage, quartalsweise Audits – dazu eine „Dokumentationsstandards“-Seite, die selbst bereits veraltet ist. All das beruht auf sozialem Druck, und nichts davon kann durchgesetzt werden. Mit stale_after wird die Veraltung zu einem fehlgeschlagenen Test, in derselben Kategorie wie ein fehlerhafter Build. Entweder es besteht der Test oder nicht – niemand muss sich schlecht fühlen.

Andere Felder funktionieren auf dieselbe Weise. sources listet die Codepfade auf, die ein Dokument beschreibt, sodass ein Skript schließlich eine Frage beantworten kann, die Wikis niemals beantworten konnten: Diese Pull-Request-Änderung betraf eine Datei, die von drei Dokumenten als erläuternd angegeben wird – hat jemand diese Dokumente aktualisiert? verified dokumentiert, wer ein Dokument bestätigt hat, getrennt davon, wer es geschrieben hat, denn laut den Spezifikationen muss nicht unbedingt dieselbe Person ein Konzept schreiben wie jemand, der es bestätigt. Ein Entwurf durch einen Agenten und die Freigabe durch einen Senior-Engineer sind zwei getrennte Vorgänge, eine Unterscheidung, die die meisten Dokumentationswerkzeuge nicht erfassen. Vertrauensstufen werden aus dem Akteursprefix abgeleitet und nicht gespeichert, da eine gespeicherte Bewertung subjektiv ist, nicht zwischen verschiedenen Nutzern übertragbar und mit der Zeit veraltet.

status: deprecated ermöglicht es Ihnen, eine alte Definition beizubehalten, anstatt sie zu löschen. Wenn zwei Dashboards bezüglich von „Umsatz“ unterschiedliche Werte anzeigen, liegt die Ursache oft nicht in schlechten Daten, sondern in zwei verschiedenen Definitionen, von denen eine stillschweigend durch die andere ersetzt wurde, ohne dass eine beschriftet ist. Behalten Sie beide bei, kennzeichnen Sie eine davon – die Zahlen des Vorquartals werden weiterhin angezeigt.

Das ist der Wandel: kein schönererer Format für Texte, sondern Texte in Kombination mit abfragbarem Zustand. Dokumente können abgefragt, getestet und als fehlerhaft eingestuft werden.

Die Token-Arithmetik

Diese Werte wurden anhand von Googles veröffentlichtem Beispielpaket gemessen, sodass sie überprüft werden können:

Ebene	Was wird geladen	Kosten	Wann
0	Ein Pointer im immer aktiven Datei	etwa 60 Tokens	immer
1	index.md, die Inhaltsübersicht	etwa 134 Tokens	wenn der Agent beschließt, nachzusehen
2	Ein Dokument	etwa 656 Tokens	wenn der Agent eines auswählt

Das Verarbeiten eines Fakts von Anfang bis Ende kostet etwa 950 Tokens und wird nur für Anfragen berechnet, die dies benötigen. Der immer aktive Teil gehört zur Stufe 0: 60 Tokens, ein Satz.

Vergleichen Sie das mit dem üblichen Ansatz: Ein Leitfaden mit 1.600 Tokens wird in jede Anfrage eingefügt, obwohl vielleicht nur jede zehnte Anfrage ihn benötigt. Das Wissen bleibt dasselbe, die durchschnittliche Rechnungsumfang beträgt etwa ein Zehntel, und das Dokument kann kostenlos wachsen, da eine längere Länge keine Auswirkungen auf unverwandte Gespräche im Repository hat. Die Spezifikation basiert auf diesem Ziel und nennt es progressive Offenlegung: Zuerst wird das Vorhandene angezeigt, anschließend werden Dokumente geöffnet.

Was OKF nicht ist

OKF fungiert nicht als Schutzmaßnahme. Eine Markdown-Datei kann einen Agenten nicht daran hindern, etwas Zerstörerisches auszuführen. Tatsächliche Durchsetzung muss durch Code erfolgen, wie z. B. Blocklisten und Vorab-Ausführungshooks, die eine Aktion unabhängig von der Wahl des Modells blockieren. Was auch immer Sie sonst noch in Erinnerung haben – schließen Sie nicht daraus, dass das Aufschreiben der Gefahren Sie schützt.

Was OKF Ihnen tatsächlich bietet, ist ein Agent, der Bescheid weiß. Die Spezifikation definiert außerdem einen Typ „Attested Computation“, bei dem ein Agent Parameter übergeben kann, aber niemals die Berechnung selbst schreiben oder ändern darf – das ist das Ähnlichste, was es gibt, um eine Überarbeitung der Sicherheitsprüfung zu verbieten. Behalten Sie das im Auge, bauen Sie aber noch nicht darauf auf: Laut der Spezifikation wird diese Schnittstelle ausdrücklich auf eine spätere Überarbeitung verschoben.

Vergessen Sie nicht, dass es sich hier um einen Entwurf handelt. Der Sprung von v0.1 zu v0.2 hat bereits zwei Konstrukte umbenannt, daher sollten Sie nur die acht Felder verwenden, die Sie benötigen. Jede spätere Umbenennung erfolgt dann durch Suchen und Ersetzen.

Fangen Sie klein an und fügen Sie Überwachungsfunktionen hinzu, wenn es sinnvoll ist

Es handelt sich dabei nicht um ein Projekt – es ist nur eine Datei.

Schreiben Sie ein Dokument über das, was kürzlich jemandem einen Nachmittag gekostet hat, mit den Feldern type, title, description und stale_after.
Schreiben Sie ein index.md, das dieses Dokument auflistet, inklusive einer Spalte „Wann dieses Dokument lesen?“ und fügen Sie okf_version: „0.2“ hinzu. Der Wurzelindex ist der einzige Ort, an dem dieses Feld hingehört, und laut Spezifikation ist es das einzige Frontmatter, das ein Index enthalten darf.

Fügen Sie den Pointer zu Ihrer immer verfügbaren Datei hinzu. Er kostet etwa sechzig Tokens und enthält einen Pfad sowie einen Auslöser – niemals eine Zusammenfassung –, denn eine Zusammenfassung erhöht sowohl die Kosten für die immer verfügbare Datei als auch die Notwendigkeit, dass der Agent die Datei öffnet.

Das reicht bereits, um mit der Arbeit zu beginnen. Da today >= stale_after lediglich ein Vergleich ist, kann der Agent diese Bedingung bereits beim Öffnen der Datei prüfen. Was mit einer veralteten Datei geschehen soll, liegt bei Ihnen – was die Spezifikation absichtlich offen lässt.

Fügen Sie Automatisierung hinzu, sobald eine zweite Person Ihr Dokument ohne Lesen ungültig machen kann. Das ist die eigentliche Schwelle – und sie betrifft eher die Teamgröße als die Korrektheit. Bei nur fünf Dokumenten werden Sie es bemerken, und eine Ablaufzeitprüfung auf Agentenseite reicht aus. In einem Team ist jeder, der Ihr Dokument zerstört, per Definition jemand, der es nie geöffnet hat; daher können gute Absichten sie nicht erreichen, weshalb etwas im Pull-Request-Prozess eingreifen muss. Die günstige Variante ist eine geplante Aufgabe, die abgelaufene Dokumente meldet. Die robuste Variante ist ein Pull-Request-Check, der bei abgelaufenen Dokumenten blockiert und eine Warnung auslöst, wenn der von einem Dokument beschriebene Code geändert wurde. Beginnen Sie mit der günstigeren Variante.

Kurzfassung

Was ein Agent benötigt, ist kein größeres Kontextfenster. Er muss wissen, wo er suchen soll, und jede geöffnete Datei muss ehrlich über ihr Alter sein. Zuerst sechzig Token, der Rest auf Anfrage – und ein Dokument, das einen Build kippen kann, sobald es nicht mehr korrekt ist, was zuvor nicht möglich war.

Weitere Literatur: die OKF v0.2-Spezifikation sowie Beispielpakete, Googles Beitrag zum Format, Anthropics Artikel zu Kontextengineering, Agent-Fähigkeiten und Prompt-Caching sowie Chromas Studie zum Kontextverfall.