OpenClaw meistern: Kontext-Management für Multi-Agent-Systeme

Nach intensiver Arbeit mit einem Fünf-Agent-Setup haben sich klare Muster herauskristallisiert, was funktioniert und was das System destabilisiert. Die wichtigste Erkenntnis: Ein Multi-Agent-System ist nur so gut wie sein Kontext-Management.

Die vier Architekturprinzipien

Session als Arbeitsgedächtnis

Sessions sind für die aktuelle Aufgabe da, nicht als Langzeitgedächtnis. Der häufigste Fehler: Man sammelt alles in der Session – historische Diskussionen, komplette Tool-Outputs, alte Logs. Das System wird träge, die Antworten unscharf.

Was wirklich in eine Session gehört: Das aktuelle Ziel, die aktuellen Constraints, getroffene Entscheidungen und die unmittelbar nächsten Schritte. Alles andere gehört woanders hin.

Memory als kuratierte Essenz

`MEMORY.md` ist keine Sammelstelle für alles Wichtige. Sie enthält nur die komprimierte, dauerhafte Essenz: stabile Nutzerpräferenzen, dauerhafte Architekturregeln, Agent-Rollen auf höchster Ebene, wenige kritische Verbote.

Was definitiv nicht hineingehört: Arbeitsprotokolle, Session-Zusammenfassungen im Volltext, Tool-Logs, große Beispiele, historische Versionen derselben Entscheidung, tägliche Notizen. Diese Dinge gehören in `memory/*.md` oder projektspezifische Dateien.

Detailwissen in Dateien, nicht im Bootstrap

Die Bootstrap-Dateien werden bei jedem Turn injiziert. Das macht sie teuer. Nur was regelmäßig auf fast jedem Turn gebraucht wird, darf dort landen. Alles andere gehört in separate Dateien, die bei Bedarf geladen werden. Den Agents kann allerdings in Ihrer MEMORY.md mitgeteilt werden, wo Sie bei Bedarf noch schlagen können, hierbei aber auch nur die wichtigsten Pfade.

Fünf Agents bedeuten fünf Kontexträume

Der kritischste Punkt im Multi-Agent-Setup: Kein Agent darf zum Sammelbecken für andere werden. Jeder Agent braucht seinen eigenen Kontext-Raum mit eigener Rolle, eigenem Session-Verlauf und eigener Memory-Perspektive.

Das macht sie tatsächlich am Ende doch sehr effizient. Wenn einer sich nur um DevOps kümmert, braucht er weder in seiner Memory noch in seinen Rules irgendwelche Anforderungen darüber, wie er redaktionell tätig ist oder wie er auf E-Mails antwortet. Die Kontexte werden jeweils sehr schlank und effizient.

Möglicherweise unterliegt man dem Irrtum dass viele Agents auch viele Tokens kosten. Das Gegenteil ist jedoch tatsächlich der Fall: Viele Agents bedeuten minimale Requests beziehungsweise minimalen Input-Kontext pro Aufgabe.

Die harten Zahlen

Nach monatelanger Optimierung haben sich diese Zielwerte als praktikabel erwiesen:

Basiskontext (Bootstrap):

Das ist die Summe aller Dateien, die bei jedem Run mitgesendet werden, also Beispielsweise AGENTS.ms, SOUL.MD, MEMORY.md, etc.

Unter 10K Tokens: sehr gut
10K-15K: gut
15K-20K: noch vertretbar
Über 20K: problematisch

Sessions:

Unter 50K: gesund
50K-120K: beobachten
120K-180K: bald verdichten
Über 180K: strukturell krank

Bootstrap im Detail

Bedeutungen und Scope der einzelnen Bootstrap-Komponenten.

zunächst die inhaltlichen Bedeutungen und der Scope der jeweiligen Bootstrap-Files für jeden einzelnen Agenten.

File	Rolle	Einschätzung
AGENTS.md	Regeln, Arbeitsweise, Routing, Sicherheitsprinzipien	Die wichtigste Datei, aber nur Kernregeln. Keine Projektchronik.
SOUL.md	Persona, Stil, Kommunikationshaltung	Sehr kurz halten. Nur Tonalität und Verhalten, kein Prozesswissen.
IDENTITY.md	Rolle, Zuständigkeit, Grenzen, Owner	Besonders nützlich bei mehreren Agents.
TOOLS.md	Tool-Policy, wann welches Tool genutzt wird	Nur Entscheidungslogik, keine Tool-Dokumentation.
USER.md	stabile Präferenzen des Users / Stakeholders	Nur langlebige Präferenzen, keine Tagesdetails.
HEARTBEAT.md	Health-/Loop-/Maintenance-Regeln	Winzig halten. Alles andere kostet nur ständig Tokens.
BOOTSTRAP.md	Startablauf, Boot-Sequenz, Lese-Reihenfolge	Eher Checkliste als Fließtext.
MEMORY.md	kuratierte Langzeit-Erinnerung	Nur Essenz. Alles Historische auslagern.
memory/YYYY-MM-DD.md	Tageslog / Rohgedächtnis	Nicht als dauerhafter Bootstrap-Ersatz missbrauchen; eher Log als Systemprompt-Inhalt.

Empfohlene Token-Größen

File	Empfohlene Zielgröße	Empfohlene Obergrenze
AGENTS.md	400–900 Tokens	1.200 Tokens
SOUL.md	150–400 Tokens	600 Tokens
IDENTITY.md	100–250 Tokens	400 Tokens
TOOLS.md	250–600 Tokens	800 Tokens
USER.md	150–400 Tokens	600 Tokens
HEARTBEAT.md	50–150 Tokens	250 Tokens
BOOTSTRAP.md	100–250 Tokens	400 Tokens
MEMORY.md	300–800 Tokens	1.200 Tokens
memory/YYYY-MM-DD.md	kein hartes Tokenziel pro Datei	—

Übergaben zwischen Agents

Die Kunst liegt im Hand-off. Wenn Agent A an Agent B übergibt, dann nicht als komplette Historie, sondern als knappe Übergabe. Hier ein Beispiel.

# Hand-off

## Ziel

- n8n-Workflow für PDF-Klassifikation stabilisieren.

## Stand

- OCR-Pipeline läuft.
- Sender-Erkennung ist unzuverlässig.
- Problem tritt vor allem bei mehrseitigen PDFs auf.

## Relevante Entscheidungen

- Dateinamensschema bleibt {date}_{sender}_{documenttype}.pdf
-  OCR bleibt im aktuellen Stack.

## Constraints

- Keine komplette Roh-PDF im Kontext halten.
- Tool-Output nur ausschnittsweise.

## Nächster Schritt

- Gezielte Analyse von drei fehlerhaften Beispielen mit minimalem Output.

Üblicherweise regeln das die Agents untereinander aber schon selber ganz gut.

Der Tool-Output-Hebel

Tool-Outputs sind ebenfalls ein großer Kontextkiller. Ein `cat große_datei` oder `grep -R .` kann eine Session sofort sprengen. Die Regel: Tool-Output darf fast nie vollständig in die Session laufen.

Stattdessen: `head`, `tail`, gezielte Zeilenbereiche, Trefferlisten mit Limit. Ein Tool sollte meistens nicht mehr als 20-100 Zeilen zurückgeben. Bei Browser-Tools oder PDFs: nur relevante Ausschnitte, nie komplette Dokumente.

Operative Routine

Die tägliche Hygiene macht den Unterschied:

Täglich: `/status` und `/context detail` prüfen, große Bootstrap-Dateien identifizieren, Sessions mit starkem Wachstum markieren.
Nach Arbeitssitzungen: Session kompaktieren, Essenz in `memory/*.md` sichern, nur stabile Regeln in `MEMORY.md` übernehmen.
Wöchentlich: MEMORY.md aufräumen, AGENTS.md auf Wiederholungen prüfen, große Tooling-Muster identifizieren.

Anti-Patterns in der Praxis

Diese Muster führen garantiert zu Problemen:

Eine Session für alles verwenden (man kann jederzeit mit `/reset` oder `/new` eine neue Session beginnen)
MEMORY.md als Protokollarchiv missbrauchen
Globale Vollsicht aller Agents in jedem Turn
Bootstrap-Limits erhöhen statt Inhalte bereinigen
Cross-Agent-Kommunikation als Transcript-Weitergabe
Gerne immer mal wieder manuell kompaktieren (`/compact`). Dabei wird die aktuelle Session auf die wesentlichen Ergebnisse, Entscheidungen und relevanten Informationen zusammen komprimiert und in der Regel massiv kleiner.

Die Entscheidungsmatrix

Bei Unsicherheit, wo Information hingehört:

Braucht fast jeder Turn das wirklich? → Wenn nein: nicht in Bootstrap
Ist es dauerhaft und stabil? → Eventuell knapp in MEMORY.md
Ist es arbeitsrelevanter Detailkontext? → In memory/*.md
Ist es nur für die aktuelle Aufgabe wichtig? → Nur in die Session

Lessons Learned

Ein gesundes OpenClaw-Setup entsteht nicht durch größere Kontextfenster, sondern durch präzise Auswahl. Die Stabilität eines Multi-Agent-Systems hängt direkt davon ab, wie konsequent man Kontext-Hygiene betreibt.

Das mag nach viel Overhead klingen, aber die Alternative – ein System, das bei 373K Tokens in einer 200K-Session erstickt – ist keine Option. Mit klaren Regeln und konsequenter Umsetzung bleibt OpenClaw stabil, schnell und präzise.

Die wichtigste Lektion: Weniger ist mehr. Weniger globaler Dauerprompt, kleineres MEMORY.md, klare Agententrennung, kompakte Hand-offs, frühe Compaction und strikte Tool-Output-Begrenzung. Das System dankt es mit Stabilität und Geschwindigkeit.