Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.
Ich habe bereits erzählt, warum das Gedächtnis eines LLM nicht in eine einzige Datei passt, und warum der Kontext das Kapital ist, das der PM aufbauen muss. Das waren Artikel über das Warum.
Dieser hier handelt vom Wie. Ich öffne die Haube meiner Kontext-Engine — das System, das in einem Ordner 02-CONTEXT/ meines Vaults lebt — und begleite eine echte Mission von Anfang bis Ende. Bei jedem Schritt erkläre ich den Baustein, der ins Spiel kommt: die Mission, den Fokus, die Direktiven, die todo-Datei, die Offline-Warteschlange und die drei Gedächtnistypen.
Das Ziel: dass jemand, der dieses System noch nie gesehen hat, versteht, wie es organisiert ist — und vor allem, warum es so organisiert ist. Denn jeder Ordner, jede Datei antwortet auf ein Problem, das ich beim Arbeiten mit einer KI über wochenlange Themen hinweg erlebt habe.
Das Ausgangsprinzip: die Festplatte ist das Gedächtnis
Eines muss vorab gesagt werden. In diesem System ist das Dateisystem das Hauptgedächtnis der KI. Nicht das Gespräch.
Ein Gespräch mit einem LLM ist flüchtig. Man schließt den Tab — alles ist verloren. Das Kontextfenster ist begrenzt, und je mehr man es füllt, desto mehr lässt die Aufmerksamkeit nach — das ist das Phänomen des Lost in the Middle, über das ich andernorts geschrieben habe. Also statt alles im Gespräch zu behalten, schreibt man alles auf die Festplatte, in Dateien, die nach Art der Information aufgeteilt sind. Und bei jeder Sitzung lädt man nur das absolut Notwendige neu.
Ein Kontext ist also ein Ordner. Ein Ordner = eine Mission. Es gibt kein implizites transversales Gedächtnis zwischen zwei Kontexten: Was die KI über Projekt A weiß, dringt nicht zu Projekt B durch. Jede Mission hat ihren eigenen Kopf.
So sieht ein Kontext vereinfacht aus:
<kontext>/
├── 00_mission/ ← der stabile Rahmen: warum wir hier sind, die Regeln
├── 01_active/ ← der lebendige Zustand: wo wir stehen, heute
├── 02_checkpoints/ ← die Zwischenstands-Fotos
├── 03_sources/ ← das Rohmaterial
├── 04_notes/ ← die extrahierten, miteinander verknüpften Ideen
├── 05_memory/ ← das konsolidierte Gedächtnis
├── 06_index/ ← der Maschinenindex, damit die KI sich orientiert
└── 07_outputs/ ← die Lieferbaren
Die Ablagelogik ist einfach, aber strikt: Was stabil ist (Mission, Regeln) ist getrennt von Was sich bei jeder Sitzung ändert (aktueller Zustand), das selbst getrennt ist von dem Rohmaterial (Quellen), dem, was man daraus extrahiert (Notizen) und dem, was man produziert (Lieferbaren). Nichts ist vermischt. Diese Trennung ist nicht kosmetisch: Sie ist es, die das Denken im Laufe der Zeit nachvollziehbar macht.
Um das alles konkret zu machen, begleite ich eine Mission, die ich wirklich durchgeführt habe (ein einfaches Beispiel, um die Lektüre zu erleichtern): PM016 — LinkedIn-Posts aus drei Artikeln schreiben, die ich in einer Marketingzeitschrift veröffentlicht habe. Eine Content-Produktionsmission, kurz, aber die meisten Bausteine aktivierend.
Einen Kontext öffnen: was die KI lädt, und was sie auf der Festplatte lässt
Ich starte eine Sitzung. Das Erste, was die KI tut, ist nicht, alles zu lesen. Es ist, eine Konfigurationsdatei zu lesen: das Lade-Manifest (load_manifest.json). Diese Datei sagt ihr, was zu laden ist, und was man im Gegenteil auf der Festplatte lassen soll.
Es enthält drei Listen:
always_load— der Kern, der jedes Mal geladen wird. Mission, Scope, Direktiven, Risiken, aktueller Zustand, Plan, Fokus, todo, Entscheidungen, Widersprüche, die Wiederaufnahme-Notiz, die Zusammenfassung.load_on_demand— alles, was auf der Festplatte bleibt und nur geladen wird, wenn die Aufgabe es erfordert: die Dutzenden von Quellen, die atomaren Notizen, die Sitzungstagebücher.- Sicherheitsgrenzen: nicht mehr als 12 aktive Dateien, etwa 1200 Zeilen maximal im Kontextfenster des LLM.
Das ist ein Chirurgentablett. Die wesentlichen Instrumente sind bereits herausgelegt; die anderen sind in Reichweite, aber man bedeckt nicht den ganzen Tisch. Ein menschlicher Experte liest nicht vor jedem Treffen seine gesamte Akte — er hat das Wesentliche verinnerlicht und holt ein bestimmtes Dokument, wenn er es braucht. Ein LLM kann nichts verinnerlichen: Es hat nur, was man ihm gibt. Daher die Wichtigkeit, ihm die richtige Teilmenge zu geben, nicht alles.
In der Praxis erfolgt das Öffnen eines Kontexts über einen Befehl — ich tippe /context_use pm016 — und die KI führt das Manifest aus: Sie liest den Kern, liest den letzten Checkpoint, und ist einsatzbereit. Sie weiß, wo wir stehen, ohne dass ich ihr irgendetwas neu erklären musste.
Mission und Fokus: das Ziel ist nicht dasselbe wie die Aufmerksamkeit
Zoom auf die beiden führenden Ordner — das Stabile und das Lebendige:
00_mission/ ← der stabile Rahmen
├── mission.md das Ziel (ändert sich nicht)
├── scope.md der Perimeter
├── directives.md wie die KI arbeiten soll
├── risks.md die zu beobachtenden Bedrohungen
└── glossary.md das Vokabular der Mission
01_active/ ← der lebendige Zustand (ändert sich bei jeder Sitzung)
├── focus.md die aktuelle Aufmerksamkeit
├── current_state.md wo wir stehen
├── current_plan.md wo wir hingehen
├── todo.md die zukünftigen Aktionen
├── decisions.md was entschieden wurde
├── contradictions.md was noch nicht passt
├── resume_work.md die Wiederaufnahme-Notiz
└── offline.md der Posteingang
Hier liegt die erste Feinheit — und wahrscheinlich die wichtigste.
Es gibt zwei Dateien, die wie „womit wir arbeiten" aussehen, aber nichts miteinander zu tun haben.
Die erste ist die Mission (00_mission/mission.md). Das ist das Ziel. Es ist stabil. Für PM016 lässt sich die Mission in einem Satz zusammenfassen: „LinkedIn-Posts basierend auf den drei Artikeln schreiben, die ich in der Zeitschrift Nr. 16 veröffentlicht habe." Dieser Satz ändert sich während der gesamten Lebensdauer des Kontexts nicht. Es ist der Kurs. Die Datei lebt in 00_mission/, dem Ordner der stabilen Dinge.
Die zweite ist der Fokus (01_active/focus.md). Das ist die aktuelle Aufmerksamkeit. Er ändert sich bei jeder Sitzung, manchmal mehrmals in einer Sitzung. Der Fokus ist: „Heute arbeiten wir an der Aufteilung der Ideen aus Artikel 2 in eigenständige Posts." Das ist nicht das Ziel — es ist das Teilproblem, auf das wir jetzt den Scheinwerfer richten. Die Datei lebt in 01_active/, dem Ordner der lebendigen Dinge.
Warum beides trennen? Weil Ziel und Aufmerksamkeit zu verwechseln der beste Weg ist, abzudriften. Wenn die KI den Tagesfokus für das Missionsziel hält, riskiert sie, die gesamte Mission um ein Detail neu zu definieren. Umgekehrt, wenn sie nur das Ziel vor Augen hat, ist sie zu vage: „Schreib LinkedIn-Posts" sagt nicht, worauf wir uns in diesem Moment konzentrieren. Die Mission gibt die Richtung, der Fokus gibt die Schärfentiefe. Man kann den Fokus zehnmal neu setzen, ohne je die Mission anzutasten. Genau wie ein Mensch: Deine Stelle (deine Mission) ändert sich nicht, weil du den Nachmittag mit einer bestimmten Aufgabe verbringst (dein Fokus).
Rund um die Mission, in 00_mission/, gibt es drei weitere rahmende Dateien.
Der Scope begrenzt, was im Perimeter ist und was nicht — die Barriere gegen das Abdriften des Themas.
Die Risiken (risks.md) sind das Raster der Bedrohungen, die auf der Mission lasten. Für PM016 ist das bescheiden; aber bei einer echten Produktgelegenheit folgt diese Datei den vier großen Risiken von Marty Cagan — Wert, Nutzbarkeit, Machbarkeit, wirtschaftliche Tragfähigkeit. Die Idee: die Fragen, die das Projekt scheitern lassen könnten, permanent im Blick zu behalten und jedes Risiko abzuhaken, sobald ein Element es beleuchtet oder verschärft. Ein leerer Abschnitt = ein noch nicht dokumentiertes Risiko, also ein bewusst in Kauf genommener blinder Fleck.
Das Glossar (glossary.md) legt das Vokabular der Mission fest, damit dieselben Wörter vom Anfang bis zum Ende dieselbe Bedeutung behalten. Derselbe Reflex wie in meinem Miteigentümer-Kontext, wo ich schließlich alle Fachbegriffe und Abkürzungen in eine eigene Datei ausgelagert hatte: Ohne das verwendet jeder — Mensch wie KI — am Ende dieselben Wörter mit verschiedenen Bedeutungen.
Ein wichtiger Punkt zu all diesen Dateien, und das ist vielleicht das Kontra-intuitivste des Systems: Sie füllen sich nicht auf einmal beim Start. Sie füllen sich schrittweise, im Verlauf der Austausche. Und „Austausch" bedeutet nicht nur „ein Dokument mitbringen". Meistens bedeutet es sprechen. Ich diskutiere mit der KI, denke laut, gebe ihr einen Kontext, den ich im Kopf habe — und sie ordnet diesen Fluss an die richtige Stelle: Dieser Punkt ist ein Tragbarkeitsrisiko, dieser Begriff verdient einen Glossareintrag, dieser Satz begrenzt den Scope. Ein nicht aufgeschriebenes Risiko wird zu einer Zeile in risks.md, weil ich es im Gespräch erwähnt habe, nicht weil ich die Datei geöffnet habe, um sie zu füllen. Genau da hört der Kontext auf, ein zu sortierender Ordner zu sein, und wird zu einem Privatsekretär, der aufschreibt, was ich laut denke.
Die Direktiven: ein Wissen kodieren, das die KI nicht hat
Eine weitere Datei des stabilen Kerns: die Direktiven (00_mission/directives.md).
Eine Direktive handelt nicht vom Thema der Mission. Sie handelt von der Arbeitsweise. Das ist der Unterschied zwischen den Zutaten und dem Rezept.
Ein Beispiel aus einem anderen meiner Kontexte, wo ich Hunderte von Miteigentümer-Mails bearbeiten lasse: „Wenn zwei Personen denselben Nachnamen tragen, gib den Sinn der E-Mail an, um ihren Vornamen und ihr Unternehmen zu benennen" (zwei Dienstleister hatten denselben Nachnamen). Das ist keine Information über die Miteigentümerschaft. Es ist eine Verarbeitungsregel. Sie kodiert ein Wissen, das nur ich besitze, und das die KI danach systematisch anwendet — ohne zu vergessen, ohne zu ermüden.
Für PM016 wäre eine typische Direktive: „Jeder Post muss eine einzige atomare Idee vertreten, niemals eine Zusammenfassung des ganzen Artikels." Das ist eine Produktionsbeschränkung, die ich einmal festlege, und die für die siebenundzwanzig Posts gilt.
Die Direktiven stehen im Kern always_load: Sie werden also bei jeder Sitzung neu geladen. Eine Regel, die in Woche 1 festgelegt wurde, gilt noch in Woche 6, ohne dass ich sie wiederholen muss. Das ist kumulativ. Je weiter eine Mission voranschreitet, desto mehr verfeinern sich ihre Direktiven, und desto mehr arbeitet die KI wie ich.
Nutzungsdetail: Um eine Direktive während des Gesprächs hinzuzufügen, setze ich meiner Nachricht einfach alpha directive : ... voran und die KI konsolidiert sie in der Datei. Es gibt eine Handvoll solcher Schlüsselwörter (decision :, contradiction :, todo :, checkpoint, fin de session) — Abkürzungen, um eine Information ohne explizite Ansage in der richtigen Datei abzulegen. Das sind nur Annehmlichkeiten; das Herzstück des Systems sind die Konzepte, nicht die Schlüsselwörter.
Die todo-Datei: zukünftige Aktionen verschmutzen das aktuelle Denken nicht
Die todo-Datei (01_active/todo.md) ist eine einfache Datei, die aber ein echtes Problem löst.
Wenn man an einem Thema arbeitet, tauchen ständig Ideen zu zukünftigen Aktionen auf. „Diese Zahl müsste man prüfen." „Man sollte diesen Post als Karussell weiterführen." „Daran denken, die englische Version zu überarbeiten." Lässt man diese Aktionen im Gespräch schweben, passieren zwei Dinge: Entweder vergisst man sie, oder sie verschmutzen das aktuelle Denken, indem sie die Aufmerksamkeit in alle Richtungen ziehen.
Die todo-Datei ist der Ort, wo man diese Aktionen ablegt, um sie nicht mehr im Kopf halten zu müssen. Es ist ein Backlog. Jede Aufgabe hat eine Kennung (T-NNN) und einen Status. Man speist sie mit todo : .... Und weil sie Teil des bei jeder Sitzung geladenen Kerns ist, geht zwischen zwei Sitzungen keine Aktion verloren.
Das ist dieselbe Logik wie für alles andere: eine Information aus dem flüchtigen Gesprächsgedächtnis herausnehmen und an einem stabilen, benannten Ort ablegen.
Die Offline-Warteschlange: mit dem Kontext sprechen, wenn er schläft
Hier ist ein Baustein, an den man am Anfang nicht denkt, der aber schnell unverzichtbar wird: die offline-Datei (01_active/offline.md).
Das Problem: Ideen kommen nicht nur, wenn man vor der KI sitzt, mit geöffnetem Kontext. Eine Idee zu PM016 durchzieht mich an einem Sonntagabend, wenn ich keine Lust habe, eine vollständige Sitzung zu öffnen. Wo soll ich sie ablegen?
In der offline-Datei. Sie ist ein Posteingang. Ich hinterlege dort eine Nachricht — eine Idee, eine Korrektur, eine Erinnerung — ohne eine Sitzung zu öffnen. Die Datei schläft mit dem Kontext.
Dann, beim Start der nächsten Sitzung, sieht der Workflow einen genauen Schritt vor: Wenn offline.md nicht leer ist, ihren Inhalt als eingehende Nachricht verarbeiten, dann die Datei leeren. Die KI liest meine Sonntagsabend-Nachricht, als hätte ich sie gerade getippt, berücksichtigt sie, handelt danach und setzt den Posteingang zurück auf null. Nichts geht verloren, und ich musste keine Sitzung öffnen, nur um eine Idee zu notieren.
Das ist eine asynchrone Art, mit einem Kontext zu sprechen. Der Kontext wird zu etwas, dem man eine Notiz hinterlassen kann, auch wenn er nicht „eingeschaltet" ist.
Quellen und Notizen: vom Rohmaterial zum wiederverwendbaren Wissen
Bisher haben wir über die Steuerung gesprochen. Jetzt der Inhalt.
Zoom auf die Kette vom Rohen zum Wissen:
03_sources/ ← das Rohmaterial
├── SRC-001.md die Karteikarte (nutzbare Transkription)
└── raw/ das Original so wie es ist (die PDF, von der KI nicht lesbar)
04_notes/ ← das extrahierte Wissen
├── atomic/ eine Idee = eine Notiz (NOTE-0001, 0002…)
└── thematic/ die Synthesen, die mehrere Notizen verknüpfen
Wenn ich Material mitbringe — für PM016 die PDF der drei Artikel — ergießt es sich nicht in das Gespräch. Es geht in 03_sources/, das Rohmaterial. Jede Quelle bekommt eine Karteikarte und eine Kennung (SRC-001, SRC-002…). Das PDF-Original, das von der KI nicht direkt lesbar ist, wird unverändert in einem Unterordner raw/ aufbewahrt, und eine .md-Karteikarte gibt eine nutzbare Transkription. Man weiß immer, woher jede Information stammt.
Dann kommt die Extraktionsarbeit. Aus den Quellen produziert die KI atomare Notizen in 04_notes/atomic/. Eine atomare Notiz erfasst eine einzige Denkeinheit: eine Tatsache, eine Definition, eine Hypothese, ein Muster, einen Widerspruch. Für PM016 hat die Analyse der drei Artikel zweiundzwanzig Notizen produziert. Hier ist eine, real:
NOTE-0022 — Abwägen ohne blind zu werden: der Schieberegler Rahmen vs. Autonomie Muster: Einer Verantwortung genug Autorität zu geben, um abzuwägen, schafft ein neues Risiko — die blinde Zentralisierung. […] Kohärenz ist nicht Homogenität. Beispiel Nike: sehr unterschiedliche Universen (Laufen, Fußball, Basketball…) koexistieren, ohne alles zu uniformieren.
Diese Notiz ist autonom: Man versteht sie ohne den Artikel wieder zu öffnen. Sie ist quellenbelegt (sie verweist auf SRC-001, Seite 67). Und sie ist verknüpft: Unten verbindet ein Abschnitt ## Backlinks sie mit der thematischen Notiz the-brand-man. Das ist Zettelkasten — verknüpfte Denkeinheiten, wo Intelligenz aus Verbindungen entsteht, nicht aus Anhäufung.
Es gibt eine Regel, die ich mir hier auferlege, und die subtiler ist, als sie scheint: Eine atomare Notiz ist nie vorformatiertes Material für das Lieferbare. Auch wenn das Ziel der Mission darin besteht, LinkedIn-Posts zu produzieren, darf eine Notiz kein „Aufhänger" oder keine „Punchline" sein. Die Notiz erfasst neutrales und wahres Wissen. Die Formatierung im Dienst des Ziels erfolgt erst in den Lieferbaren. Die Kette ist strikt: sources (roh) → notes (neutrales Wissen) → outputs (zielorientiertes Lieferbares). Solange man in den Notizen ist, hat das Missionsziel noch nichts zu sagen. Sonst vergiftet man seinen eigenen Rohstoff.
Diese Regel wirkt starr. In Wirklichkeit macht sie Notizen mächtig — weil neutrales Wissen agnostisch gegenüber dem Lieferbaren ist und damit für beliebige Lieferbaren wiederverwendbar.
Nehmen wir eine Produktmission statt PM016. Aus demselben Satz atomarer Notizen — ein Kundenthema, eine Adoptionsbeschränkung, ein Marktmuster — kann man sehr unterschiedliche Unterlagen erzeugen: ein Pitch für ein Lenkungsausschuss, Support-Dokumentation, einen Blogartikel, eine Sales Narrative, ein Onboarding. Jedes Lieferbare greift aus diesem gemeinsamen Korpus auf die Bausteine, die es braucht, und kombiniert sie. Hätte ich diese Notizen für den Pitch formatiert, würden sie nur dem Pitch dienen. Indem ich sie neutral halte, dienen sie den fünfen. Formatierung, Blickwinkel, Ton: All das kommt erst im letzten Moment, in 07_outputs/, wenn man weiß, welches Lieferbare man produziert.
Und die Wiederverwendbarkeit endet nicht bei der Mission. Kontexte sind keine dichten Silos. Eine für einen Kontext produzierte Notiz kann einen anderen beleuchten — weil man verwandte Kontexte miteinander verknüpfen kann. Ich kann sogar einen Kontext öffnen, um einen anderen zu auditieren: seine Notizen durchgehen und die guten Ideen aufgreifen. Ein einmal geschriebener Wissens-Baustein kann so heute ein Lieferbares nähren, morgen ein anderes und in sechs Monaten eine Entscheidung in einem dritten Kontext. Das ist genau das Ausgangsversprechen: Das Lieferbare ist wegwerfbar, die Notiz ist ein Kapital.
Wenn mehrere Notizen konvergieren, schreibt man eine thematische Notiz in 04_notes/thematic/ — eine Synthese eines Blickwinkels oder einer Spannung. Für PM016 eine pro Artikel.
Die drei Gedächtnisse: episodisch, semantisch und die Zwischenstands-Fotos
Zoom auf die drei Gedächtnisorten — drei Zeitskalen:
05_memory/
├── journal/ was passiert ist, Tag für Tag (die Geschichte)
└── synthesis.md was man daraus mitnimmt (die Lektion)
02_checkpoints/ der vollständige Zustand zu einem bestimmten Zeitpunkt T (das Wiederaufnahme-Foto)
Hier liegt die zweite große Feinheit des Systems. Ein menschliches Gehirn hat nicht ein Gedächtnis, es hat mehrere, die auf verschiedenen Zeitskalen funktionieren: das, was gerade passiert festhält, das, was erlebte Ereignisse speichert, und das, das dauerhaftes Wissen konsolidiert. Das System reproduziert diese Architektur mit drei unterschiedlichen Objekten, die man keinesfalls verwechseln darf.
Das Tagebuch (episodisches Gedächtnis). In 05_memory/journal/, eine Datei pro Arbeitstag. Sie erzählt, was passiert ist: was man an jenem Tag gemacht hat, in welcher Reihenfolge, welche Entscheidungen getroffen wurden, was nicht funktioniert hat. Es ist der chronologische Bericht. Man greift darauf zurück, wenn man sich fragt: „Was hatten wir am Dienstag beschlossen, und warum?" Es ist datiert, sequenziell, wird nie umgeschrieben.
Die Zusammenfassung (semantisches Gedächtnis). In 05_memory/synthesis.md, eine einzige Datei. Sie erzählt nicht, was passiert ist — sie verdichtet, was man daraus mitnimmt. Die stabilen Schlussfolgerungen, die validierten Überzeugungen, die aus Dutzenden von Sitzungen extrahierten Muster. Das ist das Langzeitgedächtnis, von der Chronologie befreit. Ein erfahrener Product Manager entdeckt nicht bei jedem Projekt neu, dass Nutzer in Interviews lügen: Das ist zu semantischem Wissen geworden. Die Zusammenfassung ist genau das. Sie gehört zum bei jeder Sitzung geladenen Kern, weil sie das nützlichste Destillat ist, um den Faden wieder aufzunehmen.
Die Checkpoints (die Zwischenstands-Fotos). In 02_checkpoints/, maximal eine Datei pro Tag. Ein Checkpoint ist ein vollständiger Schnappschuss des Kontextzustands zu einem bestimmten Zeitpunkt. Der Schreibwinkel ist sehr präzise, und das ist es, was seinen Wert ausmacht: „Wenn ein LLM jetzt ohne irgendetwas gelesen zu haben ankäme, was muss es wissen, um ohne Fehler und ohne neu anzufangen wieder einzusteigen?" Der Checkpoint ist das Sicherheitsnetz der Wiederaufnahme.
Die Unterscheidung Tagebuch / Zusammenfassung ist die, die am häufigsten entgeht. Das Tagebuch ist die Geschichte; die Zusammenfassung ist die Lektion. Man braucht beide, genau aus dem Grund, der mich bei meinen allerersten Versuchen dazu gebracht hatte, die Aggregation eines chronologischen Logs zu trennen: Ich wollte sowohl wissen, wo wir stehen (die Zusammenfassung), als auch den Faden zurückverfolgen können (das Tagebuch). Das eine mit dem anderen zu überschreiben bedeutet, entweder das Gedächtnis oder die Nachvollziehbarkeit zu verlieren.
Und genau das macht das System auditierbar. Ein Gehirn vergisst — das ist seine Stärke. Ein Dateisystem vergisst nichts. Von der Zusammenfassung geht man zum Checkpoint. Vom Checkpoint zu den Tagebüchern. Von den Tagebüchern zu den Notizen. Von den Notizen zu den Rohquellen. Wenn jemand fragt: „Warum diese Entscheidung?", lautet die Antwort nie „weil die KI es gesagt hat". Es ist eine Beweiskette: Quelle → Notiz → Entscheidung.
Der Ablauf einer Sitzung, von Anfang bis Ende
Jetzt, wo wir die Bausteine haben, hier der vollständige Film einer Sitzung zu PM016.
Beim Start. Die KI liest das Manifest, lädt den Kern, liest den letzten Checkpoint. Sie prüft die offline-Datei: Wenn sie eine Nachricht enthält, die ich zwischen zwei Sitzungen hinterlassen habe, verarbeitet sie diese und leert die Datei. In wenigen Sekunden weiß sie, wo wir stehen. Die Wiederaufnahme-Notiz (resume_work.md) gibt ihr sogar die erste auszuführende Aktion.
Während der Sitzung. Wir diskutieren — oft laut vor dem Bildschirm. Und im Verlauf des Gesprächs ordnet die KI kontinuierlich ein. Eine neue Quelle kommt → 03_sources/. Eine dauerhafte Idee taucht auf → eine atomare Notiz in 04_notes/. Eine Entscheidung wird getroffen → decisions.md. Ein Widerspruch taucht auf → contradictions.md (wir glätten ihn nicht künstlich, wir halten ihn sichtbar). Eine zukünftige Aktion → die todo-Datei. Jedes Mal, wenn eine Datei erstellt wird, werden der README.md seines Ordners und der Maschinenindex aktualisiert. Der Kontext hält sich ständig aktuell, ohne Aufwand meinerseits.
Am Ende der Sitzung. Ich tippe /context_close. Die KI löst das Abschlussritual aus: Sie schreibt das Tagesprotokoll, aktualisiert den aktuellen Zustand und die Wiederaufnahme-Notiz, befördert zur Zusammenfassung, was dauerhaft werden soll, und erstellt einen Checkpoint, wenn ein Schwellenwert erreicht ist. Dann committed sie alles. Die nächste Sitzung kann genau dort weitermachen, wo diese aufgehört hat.
Es gibt auch eine Kompaktierung unterwegs (/context_push): Wenn der aktuelle Zustand anschwillt, die todo-Datei unlesbar wird oder man im Kreis dreht, verdichtet man, dedupliziert, priorisiert, archiviert, was nicht mehr nützlich ist — ohne je die Nachvollziehbarkeit zu verlieren.
Aber /context_push hat eine noch vitalere Rolle — und das ist eine Falle, in die man zwangsläufig tappt, wenn man das System entdeckt. Wenn eine Sitzung lang dauert, überschreitet das Gespräch schließlich das LLM-Fenster. In diesem Moment führt das LLM seine eigene Kompaktierung durch: Es fasst still die alten Austausche zusammen, um Platz zu schaffen. Und alles, was zu diesem Zeitpunkt noch nicht auf die Festplatte geschrieben war — eine mündlich angesprochene Entscheidung, eine nebenbei geäußerte Idee, eine wichtige Nuance — wird abgeschliffen, verformt oder schlicht verloren. Das LLM warnt Sie nicht; es glaubt, das Wesentliche behalten zu haben, aber es hat entschieden, was wesentlich war.
/context_push ist die Gegenwehr: Es erzwingt die Persistenz auf der Festplatte, bevor das LLM sein Arbeitsgedächtnis kompaktiert. Indem man regelmäßig pusht, garantiert man, dass alles, was zählt, bereits in den Dateien geschrieben ist — am richtigen Ort, belegt, nachvollzogen —, also dass die LLM-Kompaktierung nichts Wichtiges mehr verlieren lässt. Das ist das Gründungsprinzip des Artikels, sitzungsweise angewendet: Was nur im Gespräch lebt, ist gefährdet; nur was auf der Festplatte ist, ist wirklich gespeichert.
Das Vergessen ohne Verlust
Ein letzter Punkt, weil er viel über die Philosophie des Systems sagt. Es gibt keine brutale Löschung.
Wenn eine Information nicht mehr nützlich ist, löscht man sie nicht. Man nimmt sie aus dem Standardladen heraus, kompaktiert sie oder archiviert sie. Wenn eine Idee eine andere ersetzt, überschreibt man sie nicht: Man markiert sie superseded, behält die alte Kennung und lässt die alte auf die neue zeigen. Man löscht wirklich nur bei offensichtlichem Fehler oder eindeutiger Duplikation.
Warum diese Vorsicht? Weil Auditierbarkeit der gesamte Wert des Systems ist. Wenn eine Produktüberzeugung verteidigt werden muss, muss ich bis zu ihrer Quelle zurückverfolgen können, auch wenn sie zwei Monate alt ist und seitdem „superseded" wurde. Ein Denken, dessen Geschichte man gelöscht hat, ist kein Denken mehr — es ist eine Meinung ohne Beweis.
Was der Kontext wirklich ist
Im Grunde ist diese Kontext-Engine kein Ablagesystem. Sie ist eine Gedächtnisarchitektur für eine Intelligenz, die nativ keine hat.
Jeder Baustein antwortet auf eine Grenze des LLM: Das Manifest antwortet auf das begrenzte Fenster; die drei Gedächtnisse antworten auf das Vergessen zwischen Sitzungen; die atomaren Notizen antworten auf das Lost in the Middle; die Trennung Quellen/Notizen/Lieferbaren antwortet auf den Bedarf an Nachvollziehbarkeit; die offline-Datei antwortet darauf, dass das Denken nicht aufhört, wenn die Sitzung endet.
Und das Ergebnis ist das, was ich in meinen vorigen Artikeln beschrieben hatte: Das Lieferbare ist nicht mehr der Ausgangspunkt der Arbeit, sondern ein Nebenprodukt. Was Wert hat, ist der Kontext selbst — dieses strukturierte, nachvollziehbare, wiederverwendbare Gedächtnis, das man Sitzung für Sitzung bereichert und das am Ende viel mehr produziert, als man von ihm verlangt.
Für PM016 war das Ziel siebenundzwanzig LinkedIn-Posts. Aber was bleibt, sobald die Posts veröffentlicht sind, ist ein Kontext: zweiundzwanzig verknüpfte atomare Ideen, drei thematische Synthesen, nachvollzogene Quellen. Ein Material, das ich in sechs Monaten für ein ganz anderes Lieferbares wieder öffnen kann. Der Post war das Ziel. Der Kontext ist das Kapital.
Weiterführendes
Von der einzelnen Datei zum Kontextsystem: Warum das Gedächtnis eines LLM nicht in ein einziges Dokument passt Der PM als Kontext-Architekt Eine Datei, ein paar Direktiven, und Claude erledigt den Rest — wie ich 500 E-Mails mühelos strukturiert habe Was ist eine atomare Notiz? Was ist eine thematische Notiz?