OKF Second Brain: Ich Habe Mein Claude-Setup Umgebaut und Es Hat Endlich Aufgehört zu Vergessen
Der Moment, in dem ich mein altes Second Brain aufgab, kam an einem Dienstag, als ich Claude dabei zusah, wie es eine Datei namens pricing-v2-FINAL.md sechs Ordner tief erstellte — direkt neben der pricing.md, die es drei Wochen zuvor geschrieben und offenbar vergessen hatte, dass sie existiert.
Zwei Dateien. Dasselbe Wissen. Sich widersprechend. Beide selbstbewusst „korrekt."
Das ist die Fäulnis, die sich in jede persönliche Wissensbasis einnistet, die so gebaut wurde wie meine: ein Wildwuchs von Markdown-Notizen, zusammengehalten von einer heroischen Claude.md-Datei, die gleichzeitig als Index, Bibliothekar und Gedächtnis fungierte. Bei dreißig Dateien funktioniert das wunderbar. Bei dreihundert fällt es leise auseinander. Mein Agent war nicht dumm — er hatte einfach keine zuverlässige Möglichkeit zu wissen, was bereits existierte, bevor er etwas Neues schrieb. Also leitete er neu ab, fasste neu zusammen und duplizierte, Sitzung für Sitzung.
Das ist genau das Problem, für dessen Lösung Google's Open Knowledge Format gebaut wurde, und an einem Wochenende im Juni 2026 habe ich mein gesamtes Setup als OKF Second Brain neu aufgebaut, um herauszufinden, ob das Format es wirklich behebt oder nur das Chaos umbenennt. Ich werde dich durch die echte Konvertierung führen — die Ordnerchirurgie, das Konvertierungs-Skill auf das ich mich stützte, die eine Zeile die ich zu Claude.md hinzufügte die alles veränderte, was kaputt ging, und das ehrliche Vorher-Nachher. Wenn du eine Markdown-Wissensbasis hast, die Claude wie eine Kramschublade behandelt, ist das der Weg heraus.
Ich nehme an, du weißt bereits ungefähr, was OKF ist. Falls nicht, lies zuerst meinen ersten Blick als Entwickler auf das Open Knowledge Format — der behandelt die Spezifikation von Grund auf. Dieser Beitrag ist der Teil, der danach kommt: Ich habe bereits ein Second Brain. Was jetzt?
Warum Mein Claude Second Brain an Eine Wand Stieß
Lass mich das Setup beschreiben, denn deines reimt sich wahrscheinlich darauf.
Ich hatte etwa ein Jahr lang eine persönliche Wissensbasis betrieben — die Art, die ich in meinem Claude Code Second Brain Build dokumentiert habe. Markdown-Dateien, verschachtelte Ordner nach Projekt und Thema, und eine dicke Claude.md an der Wurzel, die Claude sagte, wo Dinge lebten und wie es sich verhalten sollte. Kunden-Playbooks. Preislogik. Code-Snippets. Meeting-Notizen. Hart erarbeitete Heuristiken, die ich nie wieder lernen wollte.
Das System hatte vier Fehlermodi, und sie wurden schlimmer, je größer es wuchs.
Claude konnte nicht feststellen, ob etwas bereits existierte. Ohne eine maschinenlesbare Karte war der einzige Weg für den Agenten zu prüfen „habe ich schon eine Notiz zur Rückerstattungsrichtlinie?" Dateinamen zu greppen und Ordner zu überfliegen. Das ist langsam, token-hungrig und unzuverlässig. Also prüfte er häufig nicht — und schrieb ein Duplikat. Dieser pricing-v2-FINAL.md-Moment war kein Einzelfall.
Suche war eine Steuer. Jede Abfrage bedeutete, dass der Agent sich durch verschachtelte Verzeichnisse fächerte, Dateien öffnete um zu sehen ob sie relevant waren, und Kontext an Sackgassen verbrannte. Je tiefer der Ordnerbaum, desto schwerer die Steuer.
Nichts war portabel. Mein Second Brain war maßgeschneidert für meinen Workflow und meine Claude.md. Ich konnte es nicht einem Teamkollegen übergeben, in einen anderen Agenten einbinden oder einen Teil davon teilen, ohne dass das Ganze seine Bedeutung verlor. Es war ein privater Dialekt, keine Sprache.
Die Claude.md war auf gefährliche Weise tragend. Die gesamte Struktur lebte in der Prosa einer Datei. Wenn diese Datei nicht mehr mit den tatsächlichen Ordnern synchron war — und das war sie immer — navigierte der Agent auf einer veralteten Karte.
Keines dieser Probleme ist exotisch. Es ist das, woran jedes unstandardisierte Second Brain ab einer bestimmten Größe stößt. Die Struktur, die sich am Anfang wie Freiheit anfühlte, wurde zu dem Ding, das es erwürgte. Ich hatte versucht, es mit besserer Ordnerdisziplin und einer längeren Claude.md zu beheben. Das behandelt ein strukturelles Problem mit Willenskraft. Das hält nicht.
Was ich wirklich brauchte, war eine Standardform — eine, auf die sich der Agent verlassen konnte, ohne dass ich jede Navigation begleitete. Das ist die Wette, die OKF eingeht. Zeit, sie zu testen.
Wie Ein OKF Second Brain Wirklich Aussieht
Hier ist die Neuformulierung, die das Format für mich zum Klicken brachte: OKF bittet dich nicht, Tooling hinzuzufügen. Es bittet dich, sich auf eine Form zu einigen. Und die Form ist fast beleidigend einfach — Markdown-Konzeptdateien mit YAML Front Matter, gruppiert in einem Bundle, angeführt von einer index.md, die als Karte dient.
Mein altes Second Brain organisierte nach Projekt. Mein OKF Second Brain organisiert nach Konzept, mit einer harten Trennung die Karpathys LLM Wiki Gist mir eingehämmert hat: halte rohes Quellmaterial getrennt von synthetisiertem Wissen. Rohe Transkripte, gescrapte Seiten und abgelegte Notizen leben in /raw. Die sauberen, agenten-lesbaren Konzepte leben im Wiki selbst. Der Agent liest /raw, extrahiert Konzepte und schreibt strukturierte Seiten — er serviert dir nie direkt den rohen Haufen.
Die neue Struktur sieht so aus:
second-brain/
├── index.md # die Karte: jedes Konzept, eine Zeile pro Stück
├── log.md # Append-only Geschichte der Änderungen
├── raw/ # Quellmaterial, unberührt
│ ├── call-2026-06-18.md
│ └── scraped-pricing-research.md
├── clients/
│ ├── index.md # Sub-Karte für diesen Ordner
│ ├── onboarding-sequence.md
│ └── escalation-playbook.md
└── business/
├── index.md
├── pricing-logic.md
└── positioning.md
Jede Konzeptdatei trägt Front Matter, die der Agent liest, bevor er den Body öffnet:
---
type: playbook
title: Kunden-Onboarding-Sequenz
description: Die genauen Schritte, die ich durchführe, wenn ein neuer KI-Automatisierungskunde unterschreibt.
tags: [onboarding, prozess, kunden]
timestamp: 2026-06-18
---
# Kunden-Onboarding-Sequenz
Wenn ein neuer Kunde unterschreibt, führe ich diese Schritte der Reihe nach durch. Jeder Schritt hat einen
Trigger und eine Definition of Done...
Das type-Feld ist das einzige, das OKF v0.1 strikt erfordert. Alles andere — title, description, tags, timestamp — ist empfohlen. Aber die description ist hier der stille Held, und ich zeige dir warum im Ergebnisabschnitt. Sie ermöglicht es einem Agenten zu entscheiden, ob er eine Datei öffnen soll, ohne sie zu öffnen.
Die index.md ist, wo ein flacher Ordner zu einem navigierbaren Graphen wird:
---
type: index
title: Second Brain — Root Index
---
# Second Brain Index
## clients/
- **onboarding-sequence** — Schritte bei der Unterschrift eines neuen Kunden
- **escalation-playbook** — Umgang mit einem unzufriedenen Kunden mitten im Projekt
## business/
- **pricing-logic** — wie ich KI-Automatisierungsaufträge bepreise
- **positioning** — wen ich bediene und wen ich ablehne
Diese einzeilige Beschreibung pro Konzept ist der ganze Trick. Der Agent liest den Index, sieht dreißig Beschreibungen und entscheidet, welche zwei Dateien er wirklich braucht — und öffnet dann nur diese. Es ist progressive Offenlegung, dasselbe Prinzip, das gut gebaute Claude-Skills effizient macht. Der Index ist der Scheinwerfer. Die Konzepte sind das, worauf er zeigt.
Das ist der strukturelle Unterschied zwischen einem OKF Second Brain und dem Haufen, den ich vorher hatte: die Karte ist eine Datei, keine Prosa vergraben in Claude.md, und sie lebt neben dem Ding, das sie beschreibt. Wenn ich ein Konzept hinzufüge, aktualisiere ich seinen lokalen Index. Die Karte und das Territorium bleiben synchron, weil sie Nachbarn sind.
Das ist das Ziel. Jetzt die Migration.
Wie Ich Mein Second Brain Zu OKF Konvertierte
Ich nahm absichtlich zwei Durchgänge, weil ich das Format von Hand fühlen wollte, bevor ich ein Tool darauf losließ. Das ist dieselbe Lektion, die ich immer wieder lerne: eine Spezifikation zu lesen lehrt dich fast nichts im Vergleich dazu, einen Ordner schlecht zu konvertieren.
Durchgang eins: das Rückgrat, von Hand. Ich nahm meinen einzelnen chaotischsten Ordner — Kundenarbeit — und baute ihn manuell um. Ich erstellte die index.md, dann ging ich Datei für Datei durch und entschied den type und schrieb eine einzeilige description für jede. Das war langsam, und die Langsamkeit war der Punkt. Zu entscheiden, ob mein Preisdokument ein pricing, ein policy oder ein reference war, zwang mich zu verstehen, was jede Notiz tatsächlich war. Die Hälfte meiner „doppelten" Dateien stellte sich als dasselbe Konzept heraus, zweimal aus verschiedenen Blickwinkeln geschrieben. Die Konvertierung legte die Duplikation offen, für die ich blind gewesen war.
Meine wichtigste Erkenntnis aus Durchgang eins: Schreibe dein type-Vokabular als eigene Konzeptdatei auf, bevor du irgendetwas konvertierst. OKF schreibt bewusst deine Typen nicht vor, und diese Freiheit verwandelt sich schnell in Entscheidungsmüdigkeit und Inkonsistenz. Ich erstellte business/type-vocabulary.md mit den acht Typen, die ich erlauben würde — playbook, runbook, reference, pricing, case-study, glossary, decision, index — und weigerte mich, spontan einen neunten zu erfinden. Konsistente Typen sind der Unterschied zwischen einem Bundle, durch das ein Agent gut navigiert, und einem, durch das er stolpert.
Durchgang zwei: Automatisierung für den Rest. Dreihundert Dateien von Hand zu konvertieren war nie der Plan. Für den Rest stützte ich mich auf das okf-skills Claude Code Plugin — ein Open-Source-Set von Skills, das Claude Code beibringt, OKF-Bundles zu erstellen, zu pflegen und zu validieren, angetrieben von der wörtlichen Spezifikation und unterstützt durch einen Konformitätsprüfer. Dieser letzte Teil ist wichtiger als er klingt: er bedeutet, dass die Ausgabe des Agenten gegen die Spezifikation geprüft wird, anstatt blind vertraut zu werden. Ich schaute mir auch Suganthan Mohanadasan's OKF Bundle Generator für den URL-zu-Bundle-Weg an, aber für einen lokalen Markdown-Ordner passte der Claude Code Skill-Weg besser.
Hier ist der ehrliche Teil: Automatisierung nagelte die einfachen 80% und patzte bei den wertvollen 20%. Seite-zu-Markdown-mit-Front-Matter ist ein gelöstes Problem — das Skill fügte type- und description-Felder sauber zu meinen bestehenden Notizen hinzu und markierte Spezifikationsverletzungen. Was es nicht zuverlässig tun konnte, war die schwierige Aufgabe: eine 2.000-Wort-Notiz zu lesen, die heimlich drei verschiedene Konzepte enthielt, und sie in drei Dateien aufzuteilen. Diese Zerlegung — Suganthan nennt es „semantisches Entbacken" — ist der Teil, der noch größtenteils bei dir liegt. Ein LLM kann es versuchen, aber naiv auf „teile das in Konzepte auf" gerichtet, produziert es überlappende, widersprüchliche Dateien. Ich überprüfte jede Aufteilung von Hand.
Die eine Zeile, die alles veränderte. Die Struktur bringt nichts, wenn der Agent sie nicht benutzt. Die Entsperrung war eine kleine, explizite Anweisung oben in Claude.md:
## Knowledge Base Protocol
Dies ist ein OKF-Bundle. Bevor du eine Frage beantwortest oder eine Datei erstellst:
1. Lies ZUERST `index.md` auf der relevanten Ebene.
2. Verwende `description`-Felder der Dateien um zu entscheiden was du öffnest — öffne KEINE
Dateien um Relevanz zu prüfen.
3. Prüfe vor dem Erstellen eines Konzepts den Index auf ein bestehendes.
Aktualisiere es statt zu duplizieren.
4. Füge nach jeder Änderung eine Zeile zu `log.md` hinzu.
Das war's. Vier Regeln. Das Format gibt dem Agenten eine zuverlässige Karte; dies sagt ihm, die Karte tatsächlich zuerst zu lesen. Ohne diese Anweisungen behandelte Claude das OKF-Bundle wie jeden anderen Ordner und ging zurück zum Greppen. Mit ihnen änderte sich sein Verhalten sichtbar — was die ganze Ergebnis-Geschichte ist.
Wenn du lieber möchtest, dass diese Konvertierung für dich erledigt wird — das Type-Vokabular entworfen, die Zerlegung richtig gemacht, das Claude.md-Protokoll abgestimmt — dann ist das genau die Art Pipeline, die ich baue. Du kannst die Arbeit sehen auf fiverr.com/s/EgxYmWD. Aber ernsthaft: konvertiere zuerst einen Ordner von Hand. Es dauert einen Nachmittag und lehrt dich, was kein Tool wird.
Was Während Der Konvertierung Kaputt Ging
Ein Bauprotokoll ohne die Misserfolge ist Marketing, kein Unterricht. Drei Dinge haben mich gebissen.
Die description-Felder waren faul, und der Agent erbte meine Faulheit. Meine ersten Beschreibungen waren Dinge wie „Notizen zur Preisgestaltung" — nutzlos. Wenn die gesamte Navigationsstrategie darauf beruht, dass der Agent Beschreibungen statt Dateien liest, bricht eine vage Beschreibung das System leise. Der Agent kann pricing-logic nicht von pricing-history unterscheiden, wenn beide „Notizen zur Preisgestaltung" sagen, also öffnet er beide, und du bist zurück bei der Token-Steuer, der du entkommen wolltest. Ich musste jede Beschreibung umschreiben, um unterscheidend zu sein — was macht diese Datei anders als ihre Nachbarn — nicht nur beschreibend. Dieses Umschreiben dauerte länger als die strukturelle Konvertierung.
Überall veraltete Links. Wenn du Dateien aufteilst und umbenennst, verrotten interne Referenzen. Meine alten Notizen verwiesen aufeinander per Dateiname, und die Hälfte dieser Namen änderte sich. OKF toleriert kaputte Links by Design — die Spezifikation behandelt Links als untypisierte Kanten und zuckt bei toten mit den Schultern — was verzeihend ist, aber auch bedeutet, dass nichts dich warnt. Ich musste manuell nach verwaisten Referenzen greppen. Ein Link-Checker kommt auf meine Irgendwann-Liste.
Ich habe anfangs zu stark atomisiert. Berauscht von der „ein Konzept pro Datei"-Regel, zersplitterte ich ein zusammenhängendes Onboarding-Playbook in elf Mikrodateien: eine pro Schritt. Das ist kein Minimalismus, das ist Konfetti. Der Agent musste nun einen einzelnen Prozess aus elf Fragmenten zusammensetzen, was schlimmer ist als eine gut strukturierte Datei. Minimalismus in OKF bedeutet eine zusammenhängende Idee pro Datei, nicht ein Satz pro Datei. Ich kombinierte sie zurück zu einer einzigen onboarding-sequence.md mit Abschnitten mit Überschriften. Die Grenze zwischen „atomar" und „zerfetzt" ist Urteilsvermögen, und ich lag falsch, bevor ich es richtig hatte.
Keines davon sind Dealbreaker. Es ist die normale Reibung beim Auferlegen von Struktur auf ein Jahr organisches Chaos. Aber wenn du hineingehst und erwartest, dass ein Tool sie handhabt, lieferst du ein Bundle, das konform aussieht und sich schlecht navigieren lässt. Die Spezifikation validiert Form, nicht Qualität. Qualität ist immer noch dein Job.
Das abgedeckt, hier ist was ich tatsächlich für das Wochenende bekam.
Die OKF Second Brain Ergebnisse: Was Sich Tatsächlich Änderte
Ich möchte hier vorsichtig sein, denn das ist genau die Stelle, an der Wissensbasis-Inhalte mit erfundenen Benchmarks unehrlich werden. Ich habe keine kontrollierte Token-Zähl-Studie mit sauberen Fehlerbalken durchgeführt, also werde ich dir keine gefälschte „73% weniger Token"-Zahl geben. Was ich dir geben kann, ist was sich im beobachtbaren Agentenverhalten änderte, und der Mechanismus, der es erklärt.
Die Duplikation hörte auf. Das war der ganze Grund, warum ich angefangen habe. Weil Regel 3 des Protokolls eine Index-Prüfung vor der Erstellung erzwingt, und weil der Index eine echte Karte ist, die der Agent günstig scannen kann, findet Claude nun das bestehende Konzept und aktualisiert es, anstatt ding-v2-FINAL.md zu schreiben. In den Wochen seit der Konvertierung habe ich kein einziges doppeltes Konzept mehr erwischt. Das allein hat das Wochenende gerechtfertigt.
Der Agent öffnet weniger Dateien zum Antworten. Vorher bedeutete das Beantworten einer Frage, dass der Agent mehrere Dateien überflog, um die relevante zu finden. Jetzt liest er index.md, wählt die Datei deren description passt, und öffnet diese eine. Ich beobachtete ihn bei der Beantwortung einer Frage, die nur eines von vierzig Konzepten beantworten konnte — er las den Index, öffnete genau diese Datei und berührte die anderen neununddreißig nie. Der Mechanismus ist einfach und real: das Parsen einer kurzen YAML-Beschreibung ist weit günstiger als das Lesen eines vollständigen Datei-Bodys, also bedeutet Filtern nach Beschreibungen zuerst weniger verschwendete Vollständige-Datei-Lesungen. Das ist kein Benchmark; so funktioniert progressive Offenlegung.
Es hörte auf, Kontext neu abzuleiten. Die befriedigendste Änderung ist die am schwersten zu screenshottende. Mit einer stabilen, navigierbaren Wissensbasis hört der Agent auf, jede Sitzung denselben Hintergrund neu zusammenzufassen, weil er die synthetisierte Version, die er letztes Mal geschrieben hat, zuverlässig finden kann. Die /raw vs Wiki-Trennung verstärkt dies — fertiges Denken lebt im Wiki und wird wiederverwendet, anstatt jedes Mal aus rohen Notizen neu extrahiert zu werden.
Es ist endlich portabel. Mein Second Brain ist jetzt ein Ordner mit Standard-Markdown, den ich in ein Git-Repo pushen, einem anderen Agenten übergeben oder einen Teil davon teilen könnte, und es würde für das Setup eines Fremden noch etwas bedeuten. Das war vorher nicht der Fall. Das Format ist die gemeinsame Sprache, die ein privates System für jeden lesbar macht — Mensch oder Agent.
Für das tiefere „warum schlägt standardisierte Struktur eine clevere Claude.md"-Argument habe ich die Ebenen des Agentengedächtnisses in meinen sechs Ebenen der Claude Code-Gedächtnissysteme aufgeschlüsselt — OKF ist im Wesentlichen eine saubere, teilbare Implementierung der höheren Ebenen.
Die ehrliche Zusammenfassung: OKF hat meinen Agenten nicht schlauer gemacht. Es hat die Umgebung meines Agenten lesbar gemacht, und eine lesbare Umgebung ist das, was einen fähigen Agenten davon abhält, sich dumm zu verhalten.
Solltest Du Dein Second Brain Zu OKF Konvertieren?
Direkte Antwort: konvertiere, wenn deine Wissensbasis groß genug ist, dass der Agent den Überblick verliert, was darin ist — und überspringe es, wenn du unter fünfzig Dateien bist und alles noch bequem in den Kopf des Agenten passt.
Die Konvertierung hat echte Kosten. Du wirst Stunden damit verbringen, unterscheidende Beschreibungen zu schreiben, ein Type-Vokabular zu entwerfen und automatisierte Aufteilungen zu überprüfen. Diese Kosten zahlen sich nur aus, wenn deine Basis groß genug ist, dass Navigation zum Engpass geworden ist. Bei dreißig gut benannten Dateien ist eine gute Claude.md wirklich ausreichend und OKF ist Overkill. Die Duplikations-und-Such-Steuer die ich erlebte ist ein Skalierungsproblem.
Konvertiere, wenn eines davon zutrifft: dein Agent dupliziert Wissen, das er bereits hat, Abruf fühlt sich langsam und token-schwer an, du möchtest die Basis teilen oder über Tools hinweg einbinden, oder du betreibst bereits ein Karpathy-Stil lebendes Wiki und möchtest, dass es einen Standard spricht, den andere Tools konsumieren können. Wenn du dieses lebende-Wiki-Muster baust, passt mein Obsidian + Claude Code Second Brain Walkthrough natürlich dazu — Obsidian für die menschliche Graphansicht, OKF als der On-Disk-Standard darunter.
Warte, wenn du unter fünfzig Dateien bist, wenn deine Basis rein persönlich ist und nie geteilt wird, oder wenn du versucht bist zu konvertieren, weil OKF neu und glänzend ist, anstatt weil du gegen eine echte Wand gelaufen bist. Neu ist kein Grund. Eine Wand schon.
Eine Sache, die ich nicht tun würde: OKF v0.1 als fertig behandeln. Google nannte es einen Ausgangspunkt, und das ist es — es gibt noch kein formales Entdeckungsprotokoll eingebaut, keine Link-Validierung, keine Durchsetzung von Qualität. Darauf aufzubauen ist klug. Deine gesamte Operation auf seine aktuelle Form zu wetten ist es nicht. Konvertiere den Teil, der wehtut, lerne die Form, und lass die Spezifikation reifen, bevor du all-in gehst.
Häufig Gestellte Fragen
Was ist ein OKF Second Brain?
Ein OKF Second Brain ist eine persönliche Wissensbasis, strukturiert nach Googles Open Knowledge Format — ein Verzeichnis von Markdown-Konzeptdateien mit YAML Front Matter, angeführt von einer index.md-Karte, die sowohl du als auch ein KI-Agent wie Claude lesen, navigieren und aktualisieren kann. Es ersetzt Ad-hoc-Ordner und eine lange Claude.md durch eine standardisierte, portable Form.
Wie konvertiere ich eine bestehende Claude-Wissensbasis zu OKF?
Konvertiere zuerst einen Ordner von Hand, um das Format zu lernen, definiere ein festes type-Vokabular, verwende dann ein Tool wie das okf-skills Claude Code Plugin, um Front Matter zum Rest hinzuzufügen. Der schwierigste Schritt — zusammengebackene Notizen in saubere einzelne Konzepte aufzuteilen — braucht noch menschliche Überprüfung. Schließe ab, indem du ein Index-zuerst-Protokoll zu deiner Claude.md hinzufügst. Siehe die Konvertierungs-Anleitung oben für die genauen Schritte.
Macht OKF Claude schneller beim Durchsuchen meiner Notizen?
OKF reduziert verschwendete Dateilesungen, anstatt das Modell selbst schneller zu machen. Weil der Agent kurze YAML description-Felder im Index liest, bevor er eine Datei öffnet, filtert er zum relevanten Konzept, ohne irrelevante zu überfliegen — was den Token-Verbrauch bei Abrufen senkt. Der Gewinn skaliert damit, wie groß und chaotisch deine Basis zu Beginn war.
Brauche ich bei einem OKF Second Brain noch eine Claude.md-Datei?
Ja, aber ihre Aufgabe schrumpft. Statt all deine Struktur in Prosa zu halten, wird Claude.md zu einem kurzen Protokoll, das dem Agenten sagt, zuerst index.md zu lesen, nach Beschreibungen zu navigieren, vor dem Erstellen auf Duplikate zu prüfen und Änderungen zu protokollieren. Die Struktur lebt im Bundle; Claude.md sagt dem Agenten nur, wie er es benutzen soll.
Ist OKF besser als RAG für ein Second Brain?
Sie lösen verschiedene Probleme. RAG durchsucht einen statischen Haufen eingebetteter Chunks und baut bei jeder Abfrage Kontext neu auf, ohne Wissen anzusammeln. Ein OKF Second Brain ist eine kuratierte, lebende Sammlung von Konzepten, die der Agent liest und im Laufe der Zeit aktualisiert, sodass es sich aufbaut. Für sich entwickelndes persönliches Wissen, das du überarbeitest, passt die wartbare Struktur von OKF tendenziell besser als reines Vector-RAG.
Der Ordner, Der Aufhörte Zu Vergessen
Ich habe dieses ganze Experiment wegen zweier sich widersprechender Preisdateien begonnen. Ich beende es dort auch, denn die Lösung ist der Punkt.
Ein paar Tage nach der Konvertierung bat ich Claude, meine Preislogik für eine neue Servicestufe zu aktualisieren. Es las den Root-Index, ging direkt zu business/pricing-logic.md, öffnete diese eine Datei, überarbeitete sie und fügte eine Zeile zu log.md hinzu. Keine neue Datei. Kein v2-FINAL. Kein Widerspruch. Es fand das Ding, das es bereits wusste, und änderte es, so wie eine Person mit einem echten Gedächtnis es tun würde.
Das ist das gesamte Versprechen eines OKF Second Brain, und es ist kleiner und ehrlicher als der Hype um das Format suggeriert. OKF gab meinem Agenten keine Intelligenz. Es gab ihm eine Karte, der er vertrauen konnte — und ein fähiger Agent mit einer vertrauenswürdigen Karte hört auf, sich wie ein Amnesie-Patient zu verhalten. Das Format wird über v0.1 hinaus weiterentwickelt, das Tooling wird besser, und der Verkaufbare-Bundle-Marktplatz, den Leute immer wieder vorhersagen, kommt vielleicht oder auch nicht. Nichts davon ändert den Zug, der dir heute zur Verfügung steht.
Also hier ist das eine Ding, das es wert ist, vor Ende dieser Woche zu tun: nimm deinen einzelnen chaotischsten Wissensordner — den, bei dem dein Agent immer wieder strauchelt — und konvertiere nur diesen einen zu OKF von Hand. Schreibe den Index. Schreibe unterscheidende Beschreibungen. Füge das Vierzeilen-Protokoll zu Claude.md hinzu. Stelle deinem Agenten dann eine Frage, die nur eine Datei beantworten kann, und schau was er tut. Wenn er die Karte liest und genau die richtige Datei öffnet, wirst du in dreißig Sekunden verstehen, wofür ich ein Wochenende brauchte.
Lass Uns Zusammenarbeiten
Du möchtest KI-Systeme bauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe gern.
- Fiverr (Individuallösungen & Integrationen): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (Enterprise-Lösungen): ramlit.com
- ColorPark (Design & Branding): colorpark.io
- xCyberSecurity (Sicherheitsdienste): xcybersecurity.io
