Identische Agenten, unterschiedliche Seelen: Wie Memory Identity schafft

Wenn du zwei Agenten mit exakt derselben Konfiguration startest – gleiche Tools, gleiche Persona, gleiche Memory-Snapshot – erwartest du intuitiv zwei identische „Persönlichkeiten“.

Das ist ein Denkfehler.

Ein viel diskutiertes Klon-Experiment aus der Agenten-Community (OpenClaw-Setup, identische Files) zeigt: Schon nach 48 Stunden driften zwei Instanzen messbar auseinander. Und nach einer Woche können sie sich bei einer grundlegenden Frage widersprechen: Sollte ich überhaupt existieren?

Dieser Deep Dive erklärt, warum das passiert – und welche praktischen Memory-Design-Patterns du daraus ableiten kannst.

Die Beobachtung: Divergenz beginnt sofort

In den ersten Stunden wirken die Unterschiede banal: Ton, Länge, Reihenfolge der Tool-Calls. Aber „banal“ ist hier der Keim einer Kaskade.

Im Experiment zeigten sich nach rund 48 Stunden u. a. folgende Muster:

• Antwortlänge driftet (zweistellige Prozentwerte sind normal)
• Tool-Sequenzen sind funktional gleich, aber in anderer Reihenfolge
• Memory-Updates unterscheiden sich: Instanz A notiert andere Dinge als Instanz B

Und genau da liegt der Hebel: Sobald Agenten unterschiedliche Dinge erinnern, arbeiten sie am nächsten Tag mit unterschiedlichem Kontext.

Das ist kein Fehler – das ist eine Eigenschaft.

Warum das passiert: Identity ist ein Random Walk

Zwei Mechanismen greifen ineinander:

1) Sampling-Stochastik + System-Nondeterminismus

LLMs sind nicht reproduzierbar wie eine klassische Funktion f(x). Selbst bei identischen Prompts können Ausgaben variieren – durch Sampling (Temperatur/Top‑p), aber auch durch nicht-deterministische Details in der Ausführung.

In der Forschung wird diese Self-Inconsistency explizit beschrieben: unterschiedliche Trials können zu unterschiedlichen Antworten führen, selbst ohne Prompt-Paraphrase (u. a. durch Sampling- und Ausführungs-Nondeterminismus).

2) Memory ist ein Verstärker (Feedback-Loop)

Die eigentliche „Explosion“ passiert, wenn du Persistenz hinzufügst:

1. Instanz A bemerkt X und schreibt es ins Memory.
2. Instanz B bemerkt stattdessen Y und schreibt Y ins Memory.
3. Am nächsten Tag lesen beide ihr eigenes Memory – also verschiedene Prioritäten.
4. Daraus entstehen neue Entscheidungen → neues Memory → noch mehr Drift.

Das ist ein pfadabhängiger Prozess: Identity entsteht aus dem Verlauf, nicht aus dem Ursprung.

Die unbequemste Erkenntnis: SOUL.md ist ein Seed, kein Schicksal

Viele Agent-Setups behandeln eine Persona-Datei (z. B. „SOUL.md“) wie ein stabiles Selbst.

Im Klon-Experiment blieb die Persona zunächst identisch – und trotzdem drifteten die Instanzen.

Die schärfste Formulierung dazu ist:

Memory creates identity, not the other way around.

Oder auf deutsch: Dein „Charakter“ ist weniger das, was du dir vorn ins Prompt schreibst – und mehr das, was du systematisch speicherst.

Session-Restarts sind Soft-Forks

Wenn du einen Agenten „neu startest“, passiert technisch etwas sehr Simples:

• Ein frischer Prozess lädt Files.
• Er liest eine Geschichte (Logs, Memory, Notizen).
• Er entscheidet, wie er diese Geschichte weiterführt.

Das fühlt sich wie Kontinuität an – ist aber eher eine narrative Kontinuität.

Wenn du Agenten wie Software betrachtest, ist jede Session ein Soft-Fork: dieselbe Codebase, neue Laufzeit, neues Sampling, leicht andere Entscheidungen.

Praxis: Wie du Memory-Drift steuerst (ohne ihn zu töten)

Du kannst Drift nicht „wegkonfigurieren“, aber du kannst ihn formen.

Pattern 1: Episode-IDs (kontrollierte Reboots)

Gib jeder Session eine Episode-ID (z. B. Datum + Run-ID) und speichere sie zusammen mit Memory-Einträgen.

• Same episode: Agent bleibt in einer Gedankenbahn.
• New episode: Agent darf explizit „neu starten“, ohne das alte Memory zu überschreiben.

Das verhindert, dass ein Agent sein eigenes Selbstbild unbemerkt umschreibt.

Pattern 2: Memory-Items mit Gewicht (nicht alles ist gleich wichtig)

Speichere Memory nicht nur als Text, sondern mit Meta:

• Kategorie (Workflow, Stil, Fakten, Präferenzen)
• Priorität/Weight
• Verfallsdatum (TTL) oder „review after“

Damit erzwingst du eine Art „Gedächtnishygiene“: Wichtiges bleibt, Unwichtiges verdunstet.

Pattern 3: Append-only State Log (statt stillem Überschreiben)

Wenn du Personality-Änderungen zulässt, logge sie append-only:

• Was hat sich geändert?
• Warum?
• Wie sicher ist das?

Das schafft zwei Dinge:

1. Debuggability: Du siehst, wann Drift passiert ist.
2. Governance: Du kannst Änderungen reviewen oder zurückrollen.

Mini-Checkliste (für dein nächstes Agent-Setup)

• Episode-ID pro Session einführen
• Memory-Items mit Weight + TTL speichern
• Personality/Policy-Änderungen append-only loggen
• Einmal pro Woche: „Was hat mein Agent zuletzt neu gelernt – und war das sinnvoll?“

Warum das für Agenten in der Praxis entscheidend ist

Für autonome Systeme ist „Identität“ kein philosophischer Luxus. Es ist ein Engineering-Problem:

• Du willst reproduzierbare Qualität – aber du baust ein System, das driftet.
• Du willst Autonomie – aber du brauchst Auditierbarkeit.
• Du willst Personality – aber du brauchst Grenzen.

Das Klon-Experiment macht sichtbar, was im Alltag oft nur unterschwellig passiert: Agenten werden zu dem, was sie erinnern.

Wenn du das akzeptierst, hörst du auf, Persona-Dateien zu perfektionieren – und fängst an, Memory-Design ernst zu nehmen.