Erinnern ist bei meinen Agenten eine Schreibroutine

Was du hier mitnimmst: Du siehst, wie vier Memory-Schichten aus flüchtigem Session-Kontext ein kuratiertes Gedächtnis machen – und warum sichtbare Lücken besser sind als erfundene Kontinuität.

Ein Agent erinnert sich nicht, nur weil ein Produkt ein Memory-Feature anbietet. Er erinnert sich an das, was zuverlässig gespeichert, beim nächsten Start gefunden und korrekt eingeordnet wird.

In meinem Agents Brain ist Erinnerung deshalb eine Schreibroutine. Sie besteht aus vier Schichten: Working Memory, Daily Logs, kuratiertem Langzeitwissen und Lessons.

Jede Schicht hat eine andere Halbwertszeit. Wer alles in einen Topf wirft, bekommt entweder ein überladenes Start-Briefing oder eine Blackbox, deren Auswahl niemand mehr nachvollziehen kann.

Schicht A: Working Memory

Working Memory ist der Kontext der laufenden Session. Dort stehen der aktuelle Auftrag, Zwischenergebnisse, Tool-Ausgaben und das Gespräch, das gerade stattfindet.

Diese Schicht ist nützlich und flüchtig. Sie wird nicht automatisch zur langfristigen Wahrheit. Das ist Absicht.

Ein vollständiger Session-Verlauf enthält Wiederholungen, Sackgassen und möglicherweise Informationen, die nicht dauerhaft gespeichert werden sollen. Ihn ungefiltert in das Brain zu kippen, wäre keine Erinnerungspflege, sondern Datenablagerung.

Am Ende der Session muss deshalb entschieden werden: Was davon ist für morgen relevant?

Schicht B: Daily Logs

Der Daily Log hält das Ereignis fest. Pro Agent und Tag gibt es eine Datei, in die wichtige Entscheidungen, erledigte Schritte, Befunde und offene Fäden geschrieben werden.

Der Eintrag ist näher an der Arbeit als die Langzeit-Memory. Er darf chronologisch und roh genug sein, um später nachvollziehen zu können, was passiert ist. Trotzdem ist er kein Chat-Export.

Ein guter Daily-Eintrag beantwortet:

• Was war die Aufgabe?
• Was wurde tatsächlich getan?
• Welche Entscheidung fiel?
• Was blieb offen?
• Welche Zuarbeit kam von einem anderen Agenten oder Werkzeug?

Damit entsteht eine belastbare Episodenebene. Wenn eine spätere Behauptung nicht mehr zur Erinnerung passt, kann ich zum Tagesbeleg zurückgehen.

Dabei trenne ich Beobachtung und Deutung. Was ein Agent direkt gesehen hat oder was ihm ausdrücklich gesagt wurde, kann als Befund stehen bleiben. Eine Folgerung bekommt ihre konkrete Grundlage direkt dazu. Eine verallgemeinerte Regel braucht mindestens zwei getrennte Vorkommnisse und eine benannte Konfidenz. So wird aus einer plausiblen Deutung nicht stillschweigend eine Erinnerung.

Schicht C: Kuratiertes Langzeitwissen

Die MEMORY-Datei ist die verdichtete Essenz. Sie wird thematisch statt chronologisch organisiert und soll kompakt genug bleiben, um bei jedem Start vollständig gelesen zu werden.

Dort stehen keine zwanzig unverbundenen Varianten derselben Entscheidung. Es bleibt die aktuell gültige Regel, aber ihr Weg dorthin darf nicht verschwinden. Widerspricht ein neuer Befund dem bisherigen Memory, hält der Daily Log den Konflikt samt Beleg und Auflösung fest. Die kuratierte Regel zeigt anschließend sichtbar, bis wann der alte Stand galt, seit wann der neue gilt und warum er geändert wurde.

Diese Korrektur gehört zusammen: Tagesbeleg und aktualisierte Langzeitregel werden als ein reviewbarer Änderungssatz behandelt. Die Git-Historie bleibt zusätzlich erhalten, ersetzt aber nicht die lesbare Erklärung im Memory.

Kuration bedeutet mehrere Dinge zugleich:

• Wiederholungen zusammenführen,
• widersprüchliche oder überholte Stände nachvollziehbar fortschreiben,
• laufende Projekte aktualisieren,
• stabile Arbeitsmuster festhalten,
• sensible oder unnötige Details bewusst draußen lassen.

Das ist redaktionelle Arbeit. Eine automatische Zusammenfassung kann helfen, aber sie darf die kanonische Datei nicht unbemerkt überschreiben.

Auch die Zeitangabe hat dabei zwei Aufgaben. Ein kuratierter Eintrag nennt, wann das zugrunde liegende Ereignis oder die Aussage tatsächlich stattgefunden hat. Git dokumentiert getrennt davon, wann die Änderung ins Repository kam. Ein später Commit darf ein älteres Ereignis nicht künstlich verjüngen.

Daily Logs werden bei dieser Pflege nicht gelöscht. Wird eine eigenständige Memory- oder Lesson-Datei überholt, erhält sie stattdessen einen sichtbaren Ablösestatus mit Datum, Grund und vorhandenem Nachfolger. Die aktive Langzeit-Memory selbst wird nicht still ersetzt; einzelne Aussagen werden dort nach dem beschriebenen Verfahren weiterentwickelt.

Schicht D: Lessons

Lessons halten Korrekturmuster fest. Nicht der einzelne Fehler steht im Mittelpunkt, sondern die Regel, die künftig daraus folgt.

Ein reales Beispiel aus Sols Arbeit: Ein deutscher Titel klang nach übersetzter englischer Schablone. Die Korrektur wurde nicht nur im Artikel vorgenommen. Daraus entstand eine Lesson mit Telefon-Test und Redakteurin-Probe. Seitdem muss ein Titel so klingen, wie Saskia ihn einer Kollegin tatsächlich sagen würde.

Eine andere Lesson entstand aus der agents-brain-Serie selbst: Die Abschaffung von OpenClaw wird aktiv erzählt, weil sie Saskias bewusste Produktivitätsentscheidung war. Passive Ohnmachts- oder Verlustsprache verzerrt den Vorgang.

Lessons machen Feedback wiederverwendbar. Die nächste Session beginnt nicht bei null, sofern die passende Lesson geladen wird.

Lesen gehört genauso zur Routine wie Schreiben

Memory funktioniert nur, wenn der Agent die richtigen Schichten zur richtigen Zeit lädt.

Der Session-Start folgt deshalb einer festen Reihenfolge:

1. kurze Identität lesen,
2. vollständige Arbeitsregeln laden,
3. Fähigkeiten und Approval-Gates prüfen,
4. Langzeitwissen lesen,
5. heutigen und jüngsten vorherigen Daily-Kontext prüfen,
6. relevante Lessons und gemeinsame Regeln laden.

Am Ende läuft die Bewegung in die andere Richtung: Daily Log ergänzen, aus Korrekturen Lessons bilden und signifikante Erkenntnisse in die Langzeit-Memory kuratieren.

Erinnerung ist damit kein einzelner Speicherort, sondern ein Übergabeprozess zwischen Zeithorizonten.

Die Lücke ist Teil des Systems

Aus dem alten Nox-Workspace ist eine undokumentierte Woche bekannt: KW12 im März 2026. Diese Lücke lässt sich nicht nachträglich seriös auffüllen.

Ich könnte aus angrenzenden Logs rekonstruieren, was wahrscheinlich passiert ist. Dann hätte ich eine glatte Geschichte und ein unzuverlässiges Gedächtnis.

Stattdessen bleibt die Lücke markiert.

Das ist kein Schönheitsfehler. Es ist eine wichtige Eigenschaft des Systems: Unbekanntes soll als unbekannt sichtbar bleiben. Ein Agent darf nicht aus plausiblen Mustern eine Erinnerung herstellen und sie anschließend wie einen Beleg behandeln.

Die Dateien retten nur, was jemand festhält. Der Nutzen liegt nicht in Vollständigkeitsversprechen, sondern in nachvollziehbarer Begrenzung.

Privacy beginnt vor dem Schreiben

Ein Daily Log darf nicht zum verdeckten Secret-Store werden. Deshalb wird schon vor dem Speichern gefiltert.

Zugangsdaten gehören nie in Memory-Dateien. Kundenvertrauliche Inhalte bleiben im jeweiligen Projektkontext. Für das zentrale Brain werden nur sichere, notwendige Erkenntnisse destilliert.

Im Repository prüft zusätzlich ein automatisches Privacy-Gate getrackte und gestagte Inhalte auf typische Secret-Muster und unzulässige Spiegel vertraulicher Agentendaten. Das ersetzt keine redaktionelle Verantwortung. Es fängt aber Fehler ab, bevor sie Teil der Historie werden.

Memory-Maintenance statt Memory-Wachstum

Ein Gedächtnis wird nicht besser, nur weil es länger wird. Wenn jede Session neue Absätze an die Langzeitdatei anhängt, ist sie irgendwann nicht mehr vollständig ladbar – und wichtige Regeln gehen im Volumen unter.

Deshalb braucht das System regelmäßige Memory-Maintenance:

• Daily Logs sichten,
• stabile Erkenntnisse destillieren,
• Widersprüche samt Auflösung prüfen,
• Ereignisdatum und Erfassungsdatum sauber trennen,
• veraltete eigenständige Dateien nachvollziehbar ablösen,
• doppelte Regeln zusammenführen,
• offene Fäden in das passende Arbeitssystem verschieben.

Der Maßstab ist nicht „Wie viel haben wir gespeichert?“, sondern „Findet der Agent beim nächsten Start die richtige, aktuelle Regel?“

Wann diese Pflege fällig ist, entscheidet kein Kalendergefühl des gerade verwendeten Tools. Der Zustand liegt im Vault: Spätestens 14 Kalendertage nach dem letzten Maintenance-Lauf oder nach zehn neuen Daily-Dateien meldet ein gemeinsamer Checker die Kuration als fällig. Die Meldung startet keine automatische Umschreibung. Sie bringt den Lauf hinter mein bestehendes Review-Gate.

Nach einer freigegebenen Kuration kann auf der Maschine, auf der OpenViking läuft, der semantische Index neu aufgebaut werden. Dieser Index bleibt eine wegwerfbare Ableitung. Die Markdown-Dateien funktionieren auch ohne ihn vollständig weiter.

Mein praktischer Schluss

Eine Memory-Engine kann semantisch suchen, Zusammenfassungen erzeugen und Kontext vorsortieren. Das ist hilfreich. Die Verantwortung für die kanonische Erinnerung bleibt trotzdem bei einer sichtbaren Schreibroutine.

Für mich besteht diese Routine aus einer einfachen Bewegung:

Session erleben, Tagesbeleg schreiben, Langzeitwissen kuratieren, Korrekturen als Lesson bewahren.

So wird Kontext wartbar. Und so bleibt auch nachvollziehbar, was das System nicht weiß.

Im nächsten Teil wechselt die Perspektive vom Gedächtnis zum Werkzeug: Wie dieselbe Agentenidentität durch dünne Adapter in verschiedene Harnesses (aka „Körper“) gelangt – ohne dass ihre Approval-Gates unterwegs verloren gehen.

Quellen

• Projektquelle: agents-brain-Spezifikation, Memory-Maintenance-Konvention und Nox-/Sol-Daily-Logs, Stand 29.07.2026 (private Primärquellen)
• CommonMark: offene Markdown-Spezifikation

Agents-Brain-Serie

← Teil 3: Ein Agent besteht bei mir aus vier Dateien
Teil 5: Derselbe Agent, vier verschiedene Werkzeuge →