# Wissen, das die Session überlebt

URL: https://www.mikebild.dev/de/blog/wissen-das-die-session-ueberlebt/

Dienstagvormittag, dritte Session in dieser Woche. Ich tippe zum dritten Mal denselben Absatz: dass unser Fehlermodell zwischen erwartbaren und unerwarteten Fehlern unterscheidet, dass erwartbare Fehler als Werte zurückkommen und nicht geworfen werden, und dass die KI bitte keine try/catch-Kaskaden um jeden Serviceaufruf legen soll. Die Session davor wusste das. Die Session davor hatte es verstanden, angewendet, sogar einen Grenzfall sauber gelöst, auf den ich selbst nicht gekommen wäre. Und jetzt sitze ich wieder vor einem leeren Kontextfenster und erkläre es noch einmal, mit anderen Worten, etwas ungeduldiger als beim letzten Mal.

*Teil 9 der Serie „Von der Session zum System“ – hier geht es [zum Auftakt](https://www.mikebild.dev/de/blog/von-der-session-zum-system-auftakt/).*

Das ist die Session-Amnesie als Alltagserfahrung. Nicht als theoretisches Problem von Kontextfenstern und Token-Budgets, sondern als das leise Ärgernis, dass ich mit einem Werkzeug arbeite, das jeden Morgen zum ersten Mal von mir hört. Die Anbieter arbeiten daran – seit Ende 2025 gibt es Memory-Funktionen in den großen Assistenten, Claude Code legt sich inzwischen selbst Notizen zwischen Sessions an. Das lindert das Problem für mich allein. Aber es löst nicht die Variante, die mich wirklich beschäftigt.

Denn die Team-Variante ist schlimmer. Mittwoch erzählt mir ein Kollege, er habe „seiner“ Session unser Fehlermodell erklärt. Ich frage nach, wie. Er hat es anders erklärt als ich. Nicht falsch – anders. Andere Begriffe, andere Beispiele, eine Nuance, die ich weglassen würde, eine, die mir fehlt. Ein dritter Kollege hat es gar nicht erklärt, weil er nicht wusste, dass es da etwas zu erklären gibt; seine Session hat try/catch-Kaskaden gebaut, und der Pull Request sah entsprechend aus. Vier Leute, vier private Erklärungen derselben Konvention, vier leicht verschiedene Ergebnisse. Das ist exakt das Varianzproblem, das ich in [„Mein Erfolg lässt sich nicht kopieren“](https://www.mikebild.dev/de/blog/mein-erfolg-laesst-sich-nicht-kopieren/) beschrieben habe – nur dass es hier nicht um Arbeitsweisen geht, sondern um Wissen. Jeder von uns füttert seine Sessions mit einer eigenen, mündlichen Überlieferung dessen, was das Team eigentlich gemeinsam wissen sollte.

Die Kernfrage dieser Folge ist also: Wie wird aus Session-Wissen Team-Wissen – und irgendwann Unternehmenswissen? Wie kommt das, was in einer guten Session entsteht, in die nächste Session eines anderen Menschen?

## Zwei Sorten von Wissen

Um darüber vernünftig zu reden, hilft mir eine Unterscheidung, die ich lange nur implizit mit mir herumgetragen habe: kuratiertes Wissen und emergentes Wissen.

Kuratiertes Wissen ist bewusst destilliert. Jemand hat sich hingesetzt, eine Erfahrung oder eine Entscheidung in Worte gefasst, jemand anderes hat es gegengelesen, und das Ergebnis steht an einem Ort, an dem es gefunden wird. Architektur-Entscheidungen in ADRs, Konventionen in einer CLAUDE.md oder AGENTS.md, ein Runbook für den Deployment-Sonderfall, der alle sechs Monate zuschlägt. Kuratiertes Wissen ist teuer – es kostet die Zeit eines Menschen, der es aufschreibt, und die eines zweiten, der es prüft. Dafür ist es adressierbar: Ich kann darauf zeigen, es verlinken, es einer Session mitgeben.

Emergentes Wissen entsteht nebenbei. In der Session vom Dienstag ist ein halbes Dutzend kleiner Erkenntnisse angefallen: dass unser Test-Setup eine Eigenheit beim Mocken des Message-Brokers hat, dass eine bestimmte Bibliothek in Version 4 ein anderes Default-Verhalten hat als in unserer Doku steht, dass mein Prompt-Zuschnitt für Refactorings besser funktioniert, wenn ich das Zielbild vor die Einschränkungen stelle. Nichts davon habe ich aufgeschrieben. Die Session endete, und mit ihr verdampfte alles, was nicht in Code oder Commit-Message gerann. Emergentes Wissen ist billig in der Entstehung und flüchtig wie Atem an einer kalten Scheibe.

Das Gefälle zwischen beiden ist das eigentliche Problem. Teams produzieren in KI-Sessions heute mehr emergentes Wissen als je zuvor – jede Session ist ja ein kleines Labor, in dem jemand ausprobiert, formuliert, scheitert, nachjustiert. Und fast nichts davon überlebt. Was überlebt, ist der Code. Aber der Code enthält nur das Ergebnis, nicht die Begründung, nicht den verworfenen Irrweg, nicht die Formulierung, die den Knoten gelöst hat.

## Wissen wie Code behandeln

Das destillierte Arbeitswissen eines Teams verdient dieselbe Behandlung wie sein Code. Versioniert. Reviewt. Mit Ownership. Und mit einem Lebenszyklus, der auch das Sterben vorsieht. Darauf läuft diese Folge hinaus.

Das klingt erst einmal nach einer Banalität – „Docs as Code“ predigen Leute seit über einem Jahrzehnt. Aber im KI-Kontext bekommt jede dieser vier Eigenschaften eine neue Schärfe:

- Versioniert, weil das Wissen jetzt maschinell konsumiert wird. Wenn eine Instruktionsdatei sich ändert, ändert sich das Verhalten jeder Session, die sie liest. Das ist eine Verhaltensänderung des Systems – und Verhaltensänderungen gehören in die Historie, mit Diff und Datum und der Möglichkeit, zurückzugehen.
- Reviewt, weil eine falsche Konvention jetzt nicht mehr nur einen Leser in die Irre führt, sondern hundert Sessions. Ein Mensch, der einen schlechten Wiki-Artikel liest, merkt oft, dass etwas nicht stimmt. Eine Session merkt das nicht – sie wendet es an, überzeugt und fleißig, wie ich es in [„Sauberes Grounding II: Antworten erden“](https://www.mikebild.dev/de/blog/sauberes-grounding-antworten-erden/) beschrieben habe: Was im Kontext steht, wird zur Realität der Session, ob es stimmt oder nicht.
- Mit Ownership, weil herrenloses Wissen niemand pflegt. Jede Konventionsdatei, jedes Runbook braucht einen Menschen, der sich zuständig fühlt. Das ist keine Bürokratie – es ist die schlichte Antwort auf die Frage „Wen frage ich, ob das noch gilt?“.
- Mit Lebenszyklus, weil veraltetes Wissen schlimmer ist als keins. Das ist der Punkt, den ich am häufigsten unterschätzt sehe. Eine Session ohne Grounding rät wenigstens erkennbar; eine Session mit veraltetem Grounding rät mit Quellenangabe. Sie zitiert die Konvention von 2024, die wir im Herbst gekippt haben, und klingt dabei so belegt, dass niemand nachprüft.

Der letzte Punkt verdient einen eigenen Absatz, weil er kontraintuitiv ist. Wir sind darauf trainiert, Dokumentation als „besser als nichts“ zu betrachten. Im KI-Kontext stimmt das nicht mehr. Falsches, altes, halbgares Wissen im Grounding einer Session ist aktiv schädlich, weil es die Ratlosigkeit des Modells in falsche Sicherheit verwandelt. Ein leeres Verzeichnis zwingt mich, nachzudenken, was die Session wissen muss. Ein volles, nie ausgemistetes Verzeichnis gaukelt mir vor, das sei erledigt.

## Der Kreislauf

Wenn man die Sortierung ernst nimmt – emergentes Wissen entsteht ständig, kuratiertes Wissen wirkt – dann ergibt sich fast zwangsläufig ein Kreislauf. Ich habe ihn in den letzten Monaten in kleinem Maßstab im Team erprobt, und er hat vier Stationen.

Erstens: aus echten Läufen lernen. Nicht aus Meinungen, nicht aus Blogposts, sondern aus dem, was in unseren Sessions tatsächlich passiert ist. Welche Erklärung hat funktioniert? An welcher Stelle ist dieselbe Rückfrage zum dritten Mal aufgetaucht? Welcher Fehler kam in drei Pull Requests unabhängig voneinander vor? Das Rohmaterial liegt herum – man muss es nur als Rohmaterial erkennen.

Zweitens: ein Mensch kuratiert und gibt frei. Das ist die entscheidende Station, und sie ist bewusst nicht automatisiert. Destillieren heißt auswählen, verdichten, wegwerfen. Aus zehn Beobachtungen wird ein Absatz; aus einem Absatz wird vielleicht eine Zeile in der Konventionsdatei; acht der zehn Beobachtungen werden verworfen, weil sie Einzelfälle waren. Diese Urteilskraft ist genau das, was ein Team hat und ein Modell nicht: Wir wissen, was bei uns gilt, was eine Ausnahme war und was ab morgen Regel sein soll. Und die Freigabe – ein zweites Paar Augen, ein echtes Review – macht aus einer privaten Notiz eine geteilte Verbindlichkeit.

Drittens: das Destillat fließt ins Grounding der nächsten Session. Es steht in der Datei, die jede Session liest, oder in der Wissensquelle, die beim Arbeiten herangezogen wird. Ab diesem Moment erklärt nicht mehr jeder Kollege „seiner“ Session das Fehlermodell mündlich und verschieden – die Erklärung ist dieselbe, für alle, geprüft.

Viertens: die nächste Arbeit wird besser. Nicht dramatisch, nicht auf einen Schlag. Aber die Rückfrage, die letzte Woche dreimal kam, kommt nicht mehr. Der Fehler aus den drei Pull Requests taucht nicht wieder auf. Und die nächsten Läufe produzieren neues Rohmaterial – auf einem etwas höheren Niveau.

```mermaid
flowchart LR
    A["Echte Läufe<br/>und Erfahrungen"] --> B["Beobachten und<br/>Rohmaterial sammeln"]
    B --> C["Mensch kuratiert,<br/>Review gibt frei"]
    C --> D["Destillat im Grounding<br/>der nächsten Session"]
    D --> A
```

Das ist kein Framework und keine Zeremonie. In unserem Fall ist es eine halbe Stunde pro Woche, in der wir durchgehen, was hängen geblieben ist, plus die Disziplin, Änderungen an den Wissensdateien wie Code-Änderungen zu behandeln: Branch, Review, Merge. Der Aufwand ist real, aber überschaubar – und er verzinst sich.

## Nicht das Modell wird schlauer

Die Pointe dieses Kreislaufs ist mir erst mit der Zeit klar geworden, und sie hat meinen Blick auf die ganze Modell-Debatte verändert: In diesem Kreislauf wird nicht das Modell schlauer. Die Organisation lernt.

Das Modell ist am Ende des Quartals dasselbe wie am Anfang. Es hat nichts von uns behalten, es kennt unser Fehlermodell nicht, es wird beim nächsten Anbieter-Release ausgetauscht wie eine Glühbirne. Was sich verbessert hat, ist die Schicht darum herum: unser kuratiertes Wissen, unsere Erklärungen, die Qualität dessen, was wir jeder Session mitgeben. Und – das ist der entscheidende Unterschied – diese Schicht gehört uns. Wir können sie lesen, prüfen, korrigieren, zurückrollen. Wir können sie steuern. Das Modell können wir nicht steuern; wir können nur darauf warten, dass es besser wird, und hoffen, dass es dabei nicht anders wird.

Wer die Lernfähigkeit seiner KI-Arbeit im Modell verortet, hat deshalb ein Steuerungsproblem: Er wartet auf Fortschritt, den er nicht beeinflussen kann. Wer sie in der Kuratierung verortet, hat ein Arbeitsproblem – anstrengender, aber lösbar. Ich halte das für die nüchternste Antwort auf die Frage, wo ein Team investieren sollte: in den Teil, den es besitzt.

## Die Anti-Muster

Was ich an Versuchen gesehen habe, Session-Wissen festzuhalten, ist überwiegend gescheitert. Und zwar auf drei wiedererkennbare Arten.

Die Prompt-Sammlung im Wiki. Irgendwer legt eine Seite an: „Unsere besten Prompts“. Drei Wochen lang wird eingezahlt, dann nie wieder. Nach einem halben Jahr ist die Seite ein Friedhof – Prompts für Modelle, die keiner mehr benutzt, für Probleme, die keiner mehr hat, ohne Kontext, wann sie funktionieren und wann nicht. Niemand traut sich zu löschen, niemand mag pflegen. Der Fehler steckt schon in der Form: Ein Prompt ohne die Situation, für die er destilliert wurde, ist kein Wissen, sondern ein Souvenir.

Die Instruktionsdateien-Halde. Das habe ich in [„Vergebliche Versuche: Skills, AGENTS.md und die Grenze der Empfehlung“](https://www.mikebild.dev/de/blog/vergebliche-versuche-instruktionsdateien/) schon von einer anderen Seite beleuchtet: Konventionsdateien, in die jeder mal etwas hineinschreibt und aus denen nie etwas herausfällt. Nach einem Jahr sind es zweitausend Zeilen, in denen sich Regeln widersprechen, weil die von März die von Oktober nicht kennt. Die Sessions lesen alles und gewichten irgendwie – das Ergebnis ist Lotterie. Eine Wissensdatei ohne Löschdisziplin ist keine Wissensdatei, sondern ein Sedimentbecken.

Das Einmal-Aufgeschriebene. Die dritte Variante ist die leiseste: Ein motivierter Kollege schreibt in einer guten Woche alles auf – gründlich, strukturiert, wirklich brauchbar. Dann wird es nie wieder angefasst. Kein Ownership, kein Review-Rhythmus, kein Anlass, es zu aktualisieren. Zwölf Monate später ist es zu vierzig Prozent falsch, und weil niemand weiß, welche vierzig Prozent, traut niemand mehr dem Rest. Der einmalige Kraftakt ist der natürliche Feind des Kreislaufs: Er fühlt sich wie eine Lösung an und verhindert genau die Routine, die eine wäre.

Allen drei Mustern fehlt dasselbe: der Rückweg von der echten Arbeit ins Wissen. Sie behandeln Aufschreiben als Ereignis statt als Kreislauf.

## Die Chance, die Arbeit kostet

Und trotzdem – oder gerade deshalb – halte ich diesen Moment für eine ungewöhnliche Gelegenheit. Organisationen reden seit Jahrzehnten davon, implizites Wissen zu explizieren. Wissensmanagement-Initiativen, Wikis, Communities of Practice: Die Diagnose war immer richtig, und die Therapie ist fast immer versandet. Der Grund war nie Faulheit, sondern ein fehlender Abnehmer. Wer sein Wissen aufschrieb, schrieb für ein abstraktes „später“ und ein hypothetisches „jemand“. Die Rückkopplung fehlte; das Aufschreiben blieb ein Opfer ohne sichtbaren Ertrag.

Das hat sich geändert. Zum ersten Mal hat explizites Wissen einen unmittelbaren, unersättlichen Abnehmer: die nächste Session. Wer heute eine Konvention sauber destilliert, merkt es morgen – im Verhalten der KI, in der Qualität des Pull Requests, in der Rückfrage, die ausbleibt. Die Rückkopplungsschleife, die dem Wissensmanagement immer gefehlt hat, ist plötzlich Tage kurz statt Jahre lang. KI zwingt Organisationen nicht nur, ihr implizites Wissen zu explizieren – sie belohnt es zum ersten Mal prompt.

Ich will die Kritik daran nicht unterschlagen. Kuratieren kostet die Zeit genau der Leute, die am wenigsten davon haben. Es besteht die reale Gefahr, dass aus dem Kreislauf ein Prozess-Monster wird, ein Freigabe-Gremium für jede Zeile Konvention. Und nicht jedes Wissen will eingefroren werden – manches ist absichtlich im Fluss, und wer es zu früh destilliert, zementiert einen Zwischenstand. Die Antwort darauf ist Maß, nicht Verzicht: klein anfangen, nur destillieren, was sich wiederholt hat, und das Löschen genauso ernst nehmen wie das Schreiben.

Was mich am Ende dieser Folge umtreibt, ist eine Frage, die eine Ebene tiefer liegt. Angenommen, der Kreislauf steht: Das Team kuratiert, das Wissen überlebt die Session, die Organisation lernt. Dann liegt da ein wachsender Schatz aus destillierten Konventionen, Fachbegriffen, Entscheidungen – und ich gebe ihn Session für Session einem generischen Assistenten in die Hand, der von meiner Fachdomäne nichts weiß und jedes Mal alles aus dem Kontext rekonstruiert. Irgendwann stellt sich die Frage, wem ich dieses Wissen eigentlich anvertraue: Reicht der generische Agent mit gutem Grounding – oder braucht die Fachdomäne ein Gegenüber, das für sie gebaut ist? Wo genau der generische Agent endet, ist die Frage der nächsten Folge.

## Weiterführende Quellen

- [AGENTS.md – das offene Format für Agenten-Instruktionen](https://agents.md/)
- [Anthropic: Memory Tool – Wissen über Sessions hinweg](https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool)
- [Claude Code: How Claude remembers your project](https://code.claude.com/docs/en/memory)
- [Ikujiro Nonaka: The Knowledge-Creating Company (Harvard Business Review)](https://hbr.org/2007/07/the-knowledge-creating-company)
- [Write the Docs: Docs as Code](https://www.writethedocs.org/guide/docs-as-code/)