OpenClaw Dreaming: Was dein KI-Agent tut, wenn du schläfst

KI-Agenten produzieren im laufenden Betrieb ständig Rohmaterial: was jemand gefragt hat, wonach gesucht wurde, was in einer Session besprochen wurde. Ohne Konsolidierung wird daraus schnell ein Haufen. Wichtiges verschwindet im Rauschen, während ein zufälliges Gesprächsfragment plötzlich als dauerhafter Kontext hängen bleibt. OpenClaws Dreaming-Funktion adressiert genau das: Sie verdichtet tägliche Ereignisse im Hintergrund zu längerfristig nutzbarem Wissen.

Die Phasen tragen Namen wie Light Sleep, REM und Deep Sleep – eine Anleihe bei der menschlichen Gedächtnisbildung. Technisch ist es nüchterner: eine Pipeline, die sammelt, Muster erkennt und erst danach etwas dauerhaft speichert. Nur Kandidaten, die diese Prüfung bestehen, kommen in den Langzeitspeicher. Das ergänzt andere OpenClaw-Memory-Ansätze wie SecretRef für sichere Konfiguration oder Active Memory im Release-Kontext, zielt aber stärker auf Hintergrundkonsolidierung als auf unmittelbaren Recall.

Was Dreaming leistet

Dreaming ist als Hintergrundsystem für Memory Consolidation im memory-core-Plugin angelegt. Es ist opt-in und standardmäßig deaktiviert. Nichts läuft also unbemerkt mit. Ob und wann OpenClaw aus kurzlebigen Signalen langfristige Einträge ableitet, bleibt kontrollierbar. Das ist die richtige Voreinstellung. Bevor der erste Sweep läuft, muss der Betreiber bewusst freigeben, dass dieses System künftigen Agentenkontext mitprägen darf.

Statt alle Signale ungefiltert in den Langzeitspeicher zu schreiben, arbeitet Dreaming als kuratierte Pipeline: sortieren, reflektieren, erst bei ausreichender Relevanz übertragen.

Die drei Phasen der Datenkonsolidierung

Light Sleep: Sammeln und Staging

In der Light-Phase erfasst das System kurze Signale der letzten Stunden und dedupliziert sie gegen bekannte Muster. Woher die Daten kommen, ist bewusst breit gefasst – vom Kurzzeit-Recall bis zu redigierten Session-Transkripten.

Diese Kandidaten landen zunächst in einem isolierten Staging-Bereich. Ein direkter Schreibzugriff auf den finalen Speicher findet hier noch nicht statt. Stattdessen zeichnet der Prozess Verstärkungssignale für die spätere Bewertung auf.

REM Sleep: Muster erkennen

Während Light vor allem Material sammelt, sucht REM nach Themen und wiederkehrenden Mustern. Der Agent extrahiert übergeordnete Zusammenhänge aus den gesammelten Traces und schreibt Reflexions-Zusammenfassungen, die als zusätzliche Metriken in die finale Bewertung einfließen.

OpenClaw trennt hier bewusst zwischen dem Erfassen eines Ereignisses und der Interpretation seiner Bedeutung, weil ein flüchtiges Gesprächsfragment nicht vorschnell zur dauerhaften Wahrheit werden soll.

Deep Sleep: Langzeitspeicherung

Erst in der Deep-Phase erfolgt die eigentliche Promotion in den Langzeitspeicher. Deep rankt Kandidaten anhand gewichteter Signale und lässt sie nur durch, wenn definierte Schwellwerte überschritten werden, etwa minScore, minRecallCount oder minUniqueQueries.

Am stärksten zählen Relevance und Frequency. Alles andere wiegt weniger, ist aber kein Beiwerk: Ein Kandidat, der nur einmal in einer einzigen Session auftaucht, bleibt liegen, so relevant er klingen mag. Erst wenn dasselbe Thema an mehreren Tagen wiederkehrt und in unterschiedlichen Suchanfragen wieder auftaucht, zieht Deep ihn tatsächlich hoch. Light- und REM-Treffer können zusätzlich einen kleinen, zeitlich abklingenden Boost liefern.

Dream Diary und Backfill

Neben den technischen Outputs erzeugt Dreaming ein Dream Diary. Nach Phasen mit genügend Material schreibt ein best-effort Subagent eine kurze, menschlich lesbare Zusammenfassung – gedacht für Operatoren, nicht als Quelle automatischer Promotions. Was im Diary steht, wird nicht automatisch zu Memory. Das ist der wichtige Unterschied.

Eine zusätzliche Backfill-Lane erlaubt es, ältere Tagesnotizen nachträglich durch den Dreaming-Prozess laufen zu lassen. Wer Dreaming erst Monate nach dem Rollout aktiviert, kann damit auch historische Notizen kontrolliert nachziehen. Solche Backfills sollten reversibel und klar markiert bleiben, damit später nachvollziehbar ist, welche Erkenntnisse aus Live-Betrieb und welche aus historischer Nachverarbeitung stammen.

Die Architektur trennt dafür die Speicherorte sauber. memory/.dreams/ hält den internen Maschinenzustand fest – vom Recall-Store bis zu den Locks, die parallele Sweeps voneinander abschirmen. Reine Prozessdaten, nichts zum Nachlesen. Für Menschen gedacht sind DREAMS.md als Diary mit Phasenblöcken und optional memory/dreaming/<phase>/YYYY-MM-DD.md für detaillierte Phasen-Reports. Am Ende der Kette steht MEMORY.md mit den final konsolidierten Langzeit-Erkenntnissen.

Konfiguration und Steuerung

Dreaming lässt sich per Slash-Command oder in der Plugin-Konfiguration von memory-core aktivieren. Der Default-Sweep läuft nachts; Frequenz und Zeitzone lassen sich anpassen.

Beispiel, gekürzt:

{
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": true,
            "frequency": "0 3 * * *"
          }
        }
      }
    }
  }
}

Blindes Vertrauen ist trotzdem nicht nötig. Über das Command-Line-Interface lässt sich jeder Schritt vorher einsehen, statt ihn erst im fertigen Speicher zu entdecken:

# Status abfragen
openclaw memory status --deep

# Kandidaten vorab prüfen (ohne Schreibvorgang)
openclaw memory promote

# Kandidaten mit Begründung analysieren
openclaw memory promote-explain "router vlan"

# Manuell in den Langzeitspeicher überführen
openclaw memory promote --apply

Diese vier Befehle bilden zusammen den eigentlichen Prüfpfad: promote zeigt die Vorschau ohne jede Schreibwirkung, promote --apply erzeugt die tatsächliche Schreibwirkung, und status --deep hält den Zustand davor wie danach als Snapshot fest. Wie du aus diesem Dreiklang ein konkretes Abbruchkriterium ableitest, zeigt der nächste Abschnitt.

Der Testlauf, bevor du Dreaming scharf schaltest

Bevor ein nächtlicher Sweep in MEMORY.md schreibt, lohnt ein trockener Durchlauf. Die REM-Harness zeigt Reflexionen, Kandidaten-Truths und die Deep-Promotion-Ausgabe, ohne etwas zu schreiben:

openclaw memory rem-harness --json

Erwartet: Kandidaten mit Score und Begründung, aber kein Schreibvorgang. Tatsächlich beobachten: Ob dieselben Themen auftauchen, die du auch selbst als merkenswert einstufen würdest. Stehen dort vor allem einmalige Nebensätze aus einer Session, sind die Schwellwerte zu locker.

Den Snapshot vor und nach dem Lauf lieferst du dir über denselben Statusbefehl:

openclaw memory status --deep

Er zeigt unter anderem, wie viele Kandidaten heute schon promotet wurden und wie viele Signale aktuell zur Prüfung anstehen. Notiere diesen Wert, bevor du scharf schaltest. Steigt er am nächsten Morgen deutlich stärker als erwartet, hast du eine messbare Auffälligkeit statt eines Bauchgefühls.

Bei einzelnen Zweifelsfällen hilft die Begründung:

openclaw memory promote-explain "router vlan" --json

Abbruchkriterium: Will die Vorschau Einträge promoten, die du nicht dauerhaft im Speicher haben willst, schalte Dreaming nicht scharf. Zieh erst die Schwellwerte an. Ein zu großzügiges minScore merkst du sonst erst, wenn MEMORY.md schon voll damit ist.

Rollback: Der ist nur für die Backfill-Lane vorgesehen. openclaw memory rem-backfill --rollback räumt die eingespielten Diary-Artefakte weg, --rollback-short-term zusätzlich die gestagten Kurzzeit-Kandidaten. Gewöhnliche Diary-Einträge und der Live-Recall bleiben unangetastet. Für regulär promotete Einträge aus dem Nacht-Sweep existiert kein solcher Befehl – die räumst du in MEMORY.md von Hand ab. Deshalb ist der Vorschaulauf oben kein Komfort. Er ist der eigentliche Schutz.

Review, Recovery und Nachvollziehbarkeit

Ob Dreaming im Alltag etwas bringt, entscheidet sich an der Nachvollziehbarkeit. Kann ein Team später sehen, welcher Eintrag aus welcher Phase kam und warum? Dazu gehören reversible Diary-Outputs, optionales Staging von Kurzzeit-Evidence und getrennte Ansichten für Diary, Timeline, Backfill und Reset.

Operativ zahlt sich das aus: Ein Team kann Dreaming später aktivieren, ältere Daten kontrolliert nachziehen und trotzdem unterscheiden, was aus Live-Betrieb stammt und was aus einem Backfill-Lauf. Genau das verhindert, dass historische Daten unkontrolliert in den Langzeitspeicher wandern.

Was hängen bleibt

Dreaming ersetzt keine manuelle Kuratierung. Es ist eine vorgeschaltete Konsolidierungsschicht, die ihren Wert erst durch die native Integration in memory-core, Review-Flows und Promotion-Gates entfaltet.

Der Opt-in-Default ist die richtige Grenze. Wer Dreaming aktiviert, sollte vorher ausdrücklich entscheiden, dass die Funktion künftigen Agentenkontext verändern darf, und diese Entscheidung mit einem eigenen Testlauf absichern.

Weniger Memory-Müll, nachvollziehbarere Langzeit-Erkenntnisse, mehr Kontrolle darüber, was dauerhaft bleibt – das ist der eigentliche Nutzen. Dass der Agent dabei „träumt“, ist Nebensache. Der Punkt ist ein anderer: Ein temporäres Signal darf nicht ungeprüft zu dauerhaftem Kontext werden.