Identische Agenten, unterschiedliche Seelen: Wie Memory Identity schafft

Zwei Agenten starten mit derselben Persona, denselben Tools und demselben Memory-Snapshot. Trotzdem kann der nächste Arbeitstag verschieden aussehen: Einer dokumentiert einen Fehler ausführlich, der andere hält nur die Lösung fest. Beim folgenden Start lesen beide einen anderen Kontext.

Darin liegt Memory-Drift als Betriebsrisiko. Entscheidungen werden schwerer nachvollziehbar, Tests schlechter vergleichbar und eine Persona-Datei bestimmt das Verhalten nicht mehr allein.

Eine dokumentierte Community-Beobachtung mit zwei ähnlich gestarteten OpenClaw-Instanzen zeigt das Muster im Kleinen (Hazel, clawdbottom). Die beiden Verläufe entwickelten sich auseinander. Daraus folgt keine allgemeine 48-Stunden-Regel. Für den Betrieb liefert es einen klaren Prüfmaßstab: Gleicher Startzustand ist nur dann wirklich gleich, wenn auch die später gespeicherten Entscheidungen nachvollziehbar bleiben.

Kleine Differenzen werden später wichtig

Am Anfang sind Abweichungen oft unspektakulär: eine andere Antwortlänge, eine andere Reihenfolge bei Tool-Aufrufen oder ein anderer Eintrag im Arbeitsgedächtnis. Für eine einzelne Session spielt das selten eine große Rolle.

Mit persistiertem Memory ändert sich die Lage. Der Eintrag von heute wird zur Vorgabe von morgen.

1. Instanz A notiert eine Präferenz oder einen Fehlerfall.
2. Instanz B hält einen anderen Aspekt fest.
3. Beide lesen beim nächsten Start unterschiedliche Prioritäten.
4. Neue Antworten erzeugen weitere, unterschiedliche Memory-Einträge.

Das Verhalten wird pfadabhängig. Die Ausgangskonfiguration setzt den Rahmen; die Folge gespeicherter Entscheidungen verschiebt ihn im Alltag.

Warum identische Prompts nicht genügen

Sprachmodelle verhalten sich nicht wie eine klassische Funktion, die bei gleichem Input immer denselben Output liefert. Sampling-Einstellungen, Tool-Ergebnisse, Timing und Laufzeitumgebung können Antworten verändern. Persistenz verstärkt diese kleinen Unterschiede, weil jede Instanz ihren eigenen Verlauf erneut einliest.

Eine Datei wie SOUL.md bleibt deshalb sinnvoll, ist aber kein unveränderliches Selbst. Sie beschreibt einen Rahmen. Welche Prioritäten ein Agent im Alltag entwickelt, hängt auch von den Erfahrungen und Regeln ab, die er speichert.

Wer Verhalten reproduzieren will, vergleicht Prompts und den Zustand vor einer Session. Erst dann lässt sich beurteilen, ob eine Abweichung aus dem Modell, dem Tool-Kontext oder dem Memory-Pfad stammt.

Session-Restarts sind Übergabepunkte

Ein Neustart wirkt nach außen wie Kontinuität. Technisch lädt ein frischer Prozess Dateien, Notizen und Logs, interpretiert sie neu und setzt die Arbeit fort.

Das schafft einen brauchbaren Prüfpunkt. Welche Informationen dürfen eine neue Session lenken? Was soll nur als Historie erhalten bleiben? Und welche Einträge müssen vor dem erneuten Laden geprüft werden?

Für Betriebsteams ist das wichtiger als die Frage, ob ein Agent „dieselbe Persönlichkeit“ hat. Entscheidend ist, ob sich eine Entscheidung erklären, testen und bei Bedarf zurückrollen lässt.

Drei Muster für kontrollierbares Memory

Episode-IDs für klare Neustarts

Gib jeder Session eine Episode-ID, etwa aus Datum und Run-ID, und speichere sie mit relevanten Memory-Einträgen. Später lässt sich damit unterscheiden, was innerhalb eines Arbeitsstrangs entstand und was aus einer früheren Phase stammt.

Das hilft bei Fehleranalysen. Du kannst prüfen, ab welcher Episode eine unerwünschte Präferenz oder ein falscher Arbeitsablauf auftauchte.

Gewicht und Ablaufdatum für Memory-Einträge

Speichere Einträge mit Kategorie, Priorität und einem Prüftermin oder Ablaufdatum. Eine dauerhafte Sicherheitsregel braucht ein anderes Gewicht als eine kurzfristige Recherche-Notiz.

Ohne diese Trennung wächst Memory schnell zu einem Archiv, das vollständig aussieht und den Agenten dennoch mit alten Prioritäten füttert.

Append-only Logs für Verhaltensänderungen

Wenn sich Policy, Stil oder Arbeitsweise ändern, protokolliere die Änderung fortlaufend: Was wurde geändert? Warum? Wie sicher ist die Beobachtung?

So wird Drift sichtbar, und es bleibt ein Rückweg, wenn sich eine neue Regel im Betrieb als schlechter erweist als die alte.

Ein Test, der mehr sagt als ein Bauchgefühl

Nimm für einen kritischen Ablauf zwei getrennte Testläufe mit gleichem Startzustand. Vergleiche anschließend Antwort, erzeugte Memory-Einträge, Tool-Aufrufe und die daraus folgenden Entscheidungen.

Erwartung: Beide Instanzen halten dieselben Sicherheitsgrenzen und fachlichen Prioritäten ein.

Tatsächlich: Verschieben sich diese Grenzen nach wenigen Sessions, liegt der nächste Prüfpunkt im Memory-Pfad. Der Prompt ist dann nicht automatisch die Ursache.

Fazit: Memory-Design ist Betriebsdesign

Agenten dürfen sich anpassen. Unkontrolliert sollten sie es nicht.

Ich würde für jeden Agenten, der länger als eine Session arbeitet, drei Mindestregeln einführen: einen nachvollziehbaren Session-Kontext, gewichtete Memory-Einträge und ein append-only Protokoll für Verhaltensänderungen. Damit wird aus der diffusen Frage nach Identität eine konkrete Betriebsaufgabe.

Für die Umsetzung helfen auch unsere OpenClaw-Tutorial-Serie und der Überblick zu Agenten in der Praxis.