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

KI-Agenten produzieren im laufenden Betrieb kontinuierlich Daten: Session-Transkripte, Suchverläufe und Gesprächsnotizen. Um zu verhindern, dass der Langzeitspeicher unlesbar wird oder wichtige Informationen verloren gehen, hat OpenClaw die sogenannte Dreaming-Funktion eingeführt. Dieser automatische Hintergrundprozess destilliert aus den täglichen Ereignissen eines Agenten echtes Langzeitwissen. Die Phasen tragen die Namen Light Sleep, REM und Deep Sleep – eine bewusste Analogie zur menschlichen Gedächtnisbildung.

Was Dreaming leistet

Dreaming ist das Hintergrundsystem für Memory Consolidation im memory-core-Plugin. Es ist opt-in und standardmäßig deaktiviert (experimental). Der Opt-in-Ansatz stellt sicher, dass du die Kontrolle behältst, ob und wann OpenClaw aus kurzlebigen Signalen überhaupt langfristige Einträge ableitet.

Anstatt alle Signale ungefiltert in die Datei MEMORY.md zu schreiben, fungiert Dreaming als kuratiertes Pipeline-System. Es sortiert die gesammelten Daten, reflektiert darüber und überträgt sie erst bei ausreichender Relevanz in den Langzeitspeicher.

Die drei Phasen der Datenkonsolidierung

Light Sleep: Sammeln und Staging

In der Light-Phase werden kurze Signale der letzten Stunden erfasst und gegen bekannte Muster dedupliziert. Das System liest Daten aus dem Kurzzeit-Recall, täglichen Memory-Dateien sowie redigierten Session-Transkripten.

Diese Kandidaten landen zunächst in einem isolierten Block innerhalb der Datei DREAMS.md. Ein direkter Schreibzugriff auf den finalen Speicher (MEMORY.md) 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, konzentriert sich die REM-Phase auf Themen und wiederkehrende Muster. Der Agent extrahiert übergeordnete Zusammenhänge aus den gesammelten Traces und erstellt Reflexions-Zusammenfassungen.

Auch diese Erkenntnisse fließen als eigener Block in die DREAMS.md und liefern weitere Metriken für die finale Bewertung. OpenClaw trennt hier technisch strikt zwischen dem reinen Erfassen von Ereignissen und der Interpretation ihrer Bedeutung.

Deep Sleep: Langzeitspeicherung

Erst in der Deep-Phase erfolgt der tatsächliche Schreibvorgang in die MEMORY.md. Deep rankt Kandidaten anhand gewichteter Signale und lässt sie nur durch, wenn sie definierte Schwellwerte überschreiten (u.a. minScore, minRecallCount, minUniqueQueries).

Die Bewertung basiert auf sechs gewichteten Basis-Signalen: Relevance und Frequency tragen am stärksten, dazu kommen Query diversity, Recency, Consolidation (mehrtägige Wiederkehr) und Conceptual richness. Light- und REM-Treffer können zusätzlich einen kleinen, zeitlich abklingenden Boost liefern.

Das Dream Diary, „Grounded Backfill“ und die Dateistruktur

Neben den technischen Outputs erzeugt Dreaming ein Dream Diary in DREAMS.md (bzw. dreams.md): Nach Phasen mit genügend Material schreibt ein best-effort Subagent eine kurze, menschlich lesbare Einordnung. Wichtig: Das Diary ist für dich als Operator, nicht die Quelle für Promotions.

Neu (bzw. seit den aktuellen Releases prominent ausgebaut) ist eine grounded historische Backfill-Lane: Damit kannst du alte Tagesnotizen gezielt „nachträglich träumen lassen“, zunächst als reversibles, klar markiertes Diary- und Staging-Output. Optional lassen sich dabei sogar durable Kandidaten in denselben Kurzzeit-Evidence-Store „stagen“, den Deep ohnehin auswertet. Das ist praktisch, wenn du Dreaming erst später aktivierst oder einen sauberen „Recovery“-Pass über ältere Notizen machen willst.

Die Architektur legt die Daten an klar definierten Orten ab:

• memory/.dreams/: Maschinenzustand (Recall-Store, Phase-Signale, Checkpoints, Locks).
• DREAMS.md: Menschlich lesbares Diary + Phasenblöcke.
• memory/dreaming/<phase>/YYYY-MM-DD.md: Optionale, detaillierte Phasen-Reports.
• MEMORY.md: Final konsolidierte Langzeit-Erkenntnisse (Promotion schreibt nur hierhin).

Konfiguration und Steuerung

Du aktivierst Dreaming per Slash-Command (/dreaming on) oder in der Plugin-Config von memory-core. Der Default-Sweep läuft nachts um 03:00 (Cron: 0 3 * * *), und du kannst die Frequenz sowie Zeitzone anpassen.

Beispiel (gekürzt):

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

Nutzer müssen dem Prozess nicht blind vertrauen. Über das Command-Line-Interface lässt sich der Status jederzeit abfragen und steuern:

# 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

Was in OpenClaw v2026.4.9 daran neu/konkreter wird

In v2026.4.9 hat OpenClaw Dreaming/Memory vor allem in Richtung Review, Recovery und Nachvollziehbarkeit geschärft: eine „grounded REM backfill“-Lane (historische Notes replayen, reversible Diary-Outputs, optionales Staging von Kurzzeit-Evidence) und eine passend dazu aufgebohrte Control-UI mit strukturiertem Diary-View, Timeline/Backfill/Reset-Controls und einer klar getrennten „grounded Scene lane“.

Das ist kein flashy Feature, aber operativ wichtig: Du kannst Dreaming später einschalten, Altdaten kontrolliert nachziehen, und trotzdem bleibt sichtbar, welche Erkenntnisse aus Live-Betrieb vs. Backfill stammen.

Einordnung

Der Ansatz erinnert an ältere Community-Experimente rund um Memory Consolidation. Der Unterschied ist die native Integration in memory-core inklusive klarer Review-Flows (Diary/Scene/Backfill) und harter Promotion-Gates (Deep). Für Teams ist das ein echter Skalierungshebel: weniger Memory-Müll, mehr nachvollziehbare Langzeit-„Truths“, und ein Operator, der im Zweifel Dinge gezielt zurückrollen kann.