OpenClaw Memory und Context Engineering - Wie Agenten erinnern

Memory ist der Punkt, an dem sich ein Agent von einem klassischen Chatbot unterscheidet. Ein Chatbot reagiert auf eine Anfrage, gibt eine Antwort zurück und vergisst danach den Kontext. Ein Agent dagegen muss sich erinnern: an Zwischenergebnisse, an Tool-Outputs, an Entscheidungen aus vorherigen Schritten und manchmal an Briefings, die Tage oder Wochen zurückliegen. OpenClaw löst diese Aufgabe mit einem flexiblen Memory-Layer, der drei Hauptstrategien kennt und sich für jeden Use-Case eigenständig konfigurieren lässt. In dieser Lektion lernst du, wie Buffer, Summary und Retrieval funktionieren, wann du welche Variante nimmst und wie du dein Context-Window so klein wie möglich hältst, ohne wichtige Informationen zu verlieren.

Warum Memory in Agenten anders funktioniert als in Chats

Ein Chat-Verlauf ist linear: User schreibt, Bot antwortet, User schreibt, Bot antwortet. Die Reihenfolge ist offensichtlich, der Inhalt ist überschaubar, und der Context wächst pro Turn um zwei Nachrichten. Bei einem Agenten sieht die Welt anders aus, weil zwischen den User-Turns plötzlich viele weitere Ereignisse passieren: Der Agent ruft Tools auf, bekommt Antworten zurück, entscheidet auf Basis dieser Antworten den nächsten Schritt, ruft erneut Tools auf, und produziert dabei am Ende vielleicht ein einziges Ergebnis für den User. Pro User-Turn können also leicht zehn bis fünfzig interne Nachrichten anfallen, die alle irgendwo gespeichert werden müssen, mindestens für die Dauer der aktuellen Aufgabe.

Tool-Outputs sind dabei besonders heikel. Stell dir vor, dein Agent ruft eine Web-Search-API auf und bekommt zwanzig Treffer mit jeweils ein paar Absätzen Snippet zurück. Das sind schnell mehrere Tausend Token, die in den Context wandern. Bei drei aufeinanderfolgenden Searches hast du fünfzehntausend Token allein für Tool-Outputs verbrannt. Wenn dein Modell ein 32k-Context-Window hat, ist die Hälfte schon weg, bevor der eigentliche Reasoning-Prozess überhaupt richtig anläuft. Memory-Strategien sind deshalb in erster Linie Speicher-Disziplin: Du musst entscheiden, was bleibt, was zusammengefasst wird und was komplett ausgelagert oder gelöscht werden kann.

State zwischen Sessions ist die zweite Dimension. Ein Agent, der eine längere Aufgabe bearbeitet, läuft selten in einer einzigen Session durch. Er pausiert, wartet auf User-Input, wird durch einen Cron-Job neu angeworfen oder läuft auf mehreren Maschinen verteilt. In all diesen Fällen muss das Memory persistent sein, sonst beginnt der Agent jedes Mal bei Null. Das ist ein klassischer Fehler in frühen Agenten-Prototypen: Im Notebook funktioniert alles, weil der Python-Prozess die Variablen hält. Sobald du das Ganze in einen Job-Runner oder eine API steckst, ist das Wissen weg.

Memory in Agenten ist deshalb mehr als ein Konversations-Logger. Es ist die zentrale Infrastruktur, die entscheidet, wie schlau dein Agent über die Zeit wird, wie viele Token du pro Aufgabe verbrennst und ob deine Pipeline reproduzierbar bleibt. OpenClaw nimmt dir die Implementierungsdetails ab, lässt dir aber die strategische Entscheidung. Diese Entscheidung triffst du am besten bewusst: pro Agent, pro Use-Case, pro Erwartung an Latenz und Kosten. Faustregel: Je länger die erwartete Lebensdauer einer Aufgabe und je mehr Tool-Calls dazwischen liegen, desto wichtiger wird eine kluge Memory-Strategie.

Schließlich gibt es noch den Aspekt der Wiederholung. Agenten arbeiten oft an ähnlichen Aufgaben, etwa wenn sie für jeden Kunden eine vergleichbare Recherche fahren. Wer hier Memory clever einsetzt, kann Vorlagen, gemeinsame Erkenntnisse oder gelernte Heuristiken zwischen Sessions teilen und so Qualität und Geschwindigkeit über die Zeit steigern. Das ist der Übergang von einem zustandslosen Werkzeug hin zu einem System, das mit jeder Iteration besser wird, ohne dass du es jedes Mal neu programmieren müsstest.

Buffer-Memory

Die einfachste Memory-Strategie ist der Buffer: Du hältst die letzten N Nachrichten unverändert im Context und wirfst alles Ältere raus. In OpenClaw legst du das mit zwei Zeilen an. Du importierst die Memory-Klasse, gibst die Strategie und das Limit an, und der Agent nutzt diesen Speicher automatisch für jeden Turn.

from openclaw import Memory
mem = Memory(strategy="buffer", max_messages=20)

Buffer-Memory ist deine erste Wahl, wenn die Aufgabe kurz ist und der Kontext nicht über mehrere Dutzend Turns hinaus relevant bleibt. Ein Support-Bot, der Tickets klassifiziert, braucht selten mehr als die letzten fünf bis zehn Nachrichten. Ein Coding-Assistent, der punktuell Fragen zu einem Snippet beantwortet, kommt mit zwanzig Nachrichten weit. In diesen Szenarien spielt Buffer seine Stärken aus: Es gibt keinen Informationsverlust innerhalb des Fensters, keinen zusätzlichen LLM-Aufruf zum Komprimieren, keine Latenz-Strafe und keine Komplexität in der Konfiguration.

Wo Buffer schmerzt, sind lange Recherche-Tasks oder Multi-Step-Workflows. Sobald dein Agent dreißig oder vierzig Tool-Calls hintereinander ausführt, verlierst du mit einem 20er-Buffer schon nach kurzer Zeit den Anfang der Aufgabe, also den eigentlichen Auftrag des Users. Das Ergebnis sind Agenten, die plötzlich vom Thema abkommen oder die ursprüngliche Frage vergessen, weil das System-Briefing aus dem Buffer gefallen ist. In solchen Fällen kannst du mit einem Trick gegensteuern: Du pinst die ersten N Nachrichten (System-Prompt, User-Briefing) und lässt nur die folgenden rotieren. OpenClaw unterstützt das über den Parameter pinned_messages, mit dem du Indexe oder Tags festlegst, die nie aus dem Buffer fallen.

Buffer ist außerdem die Strategie mit den höchsten Token-Kosten pro Turn, weil jede Nachricht in voller Länge im Context bleibt, bis sie aus dem Fenster fällt. Wenn deine Tool-Outputs groß sind, etwa lange JSON-Antworten oder ganze Web-Page-Inhalte, frisst das schnell dein Budget. In diesem Fall hilft entweder eine harte Output-Compression auf Tool-Ebene (du fasst den Output schon zusammen, bevor er ins Memory wandert) oder du wechselst direkt zu Summary- oder Retrieval-Memory. Buffer ist die Default-Antwort für simple Agenten, aber selten die richtige Wahl für produktive Systeme mit langer Laufzeit oder vielen Tool-Calls.

Summary-Memory

Summary-Memory geht einen Schritt weiter. Statt alte Nachrichten einfach zu verwerfen, fasst der Memory-Layer sie zusammen und schreibt das Ergebnis in eine kompakte Zusammenfassung. Diese Summary wandert zusammen mit den letzten paar unveränderten Nachrichten in den Context. So bekommst du beides: aktuelle Details ungekürzt und eine kondensierte Erinnerung an alles, was vorher passiert ist. In OpenClaw aktivierst du das mit einem Token-Budget und einem Summary-Modell.

mem = Memory(strategy="summary", max_tokens=4000, summary_model="gpt-4o-mini")

Hier wird es interessant. Der Parameter max_tokens definiert, wie viel Platz die Summary plus die letzten unveränderten Nachrichten zusammen einnehmen dürfen. Sobald das Limit überschritten wird, triggert OpenClaw einen Summary-Pass: Es nimmt die ältesten Nachrichten, kombiniert sie mit der bestehenden Summary und ruft das Summary-Modell auf, um eine neue, kompaktere Version zu generieren. Wichtig: Das ist ein zusätzlicher LLM-Aufruf pro Kompression, mit eigener Latenz und eigenen Kosten. Deshalb wählst du dein Summary-Modell mit Bedacht. Ein günstiges Modell wie gpt-4o-mini oder claude-haiku reicht für die meisten Zusammenfassungs-Aufgaben aus und kostet einen Bruchteil dessen, was dein Haupt-Modell für jede Token-Antwort nimmt.

Der Trade-off bei Summary-Memory ist Verlust. Eine Zusammenfassung ist immer eine Interpretation, und die Qualität hängt davon ab, wie gut das Summary-Modell die wichtigen Details herausarbeitet. In der Praxis heißt das: Du musst dein Summary-Prompt tunen. OpenClaw bringt einen sinnvollen Default mit, aber sobald du merkst, dass dein Agent bestimmte Informationen verliert (etwa Zahlen, Namen oder Tool-Resultate), solltest du den Prompt anpassen. Du kannst das mit summary_prompt="..." direkt im Memory-Konstruktor tun und etwa explizit verlangen, dass alle numerischen Werte und User-Wünsche wörtlich übernommen werden.

Summary ist die Standard-Wahl für mittellange Workflows: Recherche-Agenten, die fünfzig bis hundert Schritte durchlaufen, Coding-Assistenten, die über mehrere Files hinweg arbeiten, oder Onboarding-Bots, die einen User durch einen längeren Flow führen. Du behältst die letzten Details exakt, hast aber einen kompakten Überblick über die Geschichte. In Sachen Token-Effizienz schlägt Summary den reinen Buffer ab einer bestimmten Länge deutlich: Statt 20.000 Token aus zwanzig vollen Nachrichten landen vielleicht 2.000 Token Summary plus 5.000 Token aktuelle Nachrichten im Context. Du sparst also gut zwei Drittel, ohne den groben roten Faden zu verlieren.

Was Summary nicht kann: punktgenau auf Detailfragen aus weit zurückliegenden Schritten antworten. Wenn dein Agent zwanzig Schritte zuvor eine bestimmte Zahl gesehen hat, wird sie in der Summary vielleicht nur als grober Wert auftauchen oder ganz wegfallen. Für solche Fälle brauchst du Retrieval-Memory, das wir uns als Nächstes anschauen. Eine pragmatische Mischung ist, Buffer und Summary zu kombinieren: einen kleinen Buffer für die letzten zehn Nachrichten plus eine Summary für alles davor. OpenClaw unterstützt das über die Strategie "buffer+summary", bei der du beide Limits separat setzt.

Retrieval-Memory (RAG)

Retrieval-Memory ist die mächtigste der drei Strategien und gleichzeitig die mit dem größten Setup-Aufwand. Die Idee: Statt das gesamte Wissen im Context zu halten oder zu verdichten, schreibst du es in einen Vektor-Store. Bei jedem Turn berechnet der Memory-Layer einen Embedding-Vektor für die aktuelle User-Anfrage und holt die N relevantesten Snippets aus dem Store zurück in den Context. So skaliert dein Agent auf praktisch unbegrenzte Wissensbestände, ohne dass das Context-Window jemals überläuft.

from openclaw.memory import RetrievalMemory
mem = RetrievalMemory(
    store="qdrant",
    embedder="text-embedding-3-small",
    top_k=4,
)

Der Store kann Qdrant sein, wie im Beispiel, aber OpenClaw unterstützt auch Pinecone, Weaviate, Chroma, pgvector und Milvus. Welchen du nimmst, hängt von deinem Stack ab: Wer schon PostgreSQL betreibt, kommt mit pgvector schnell ans Ziel. Wer Wert auf hohe Performance bei Millionen von Dokumenten legt, ist mit Qdrant oder Milvus besser bedient. Pinecone ist die Managed-Variante, die kein Self-Hosting verlangt, dafür aber laufende Kosten verursacht. Der Embedder bestimmt, wie gut die Treffer-Qualität ist. text-embedding-3-small von OpenAI ist günstig und liefert gute Ergebnisse für die meisten Anwendungsfälle. Für deutsche Texte solltest du testen, ob text-embedding-3-large oder ein lokal gehostetes Modell wie bge-m3 deutlich bessere Treffer liefert.

top_k=4 bedeutet, dass bei jeder Anfrage die vier ähnlichsten Snippets zurück in den Context wandern. Das klingt nach wenig, ist aber bewusst gewählt: Mehr Snippets heißen mehr Token, mehr Rauschen und schlechteres Reasoning. Vier bis acht Snippets sind in der Praxis ein guter Sweet-Spot. Wenn du merkst, dass dein Agent häufig nicht die richtige Information findet, ist das selten ein Problem von zu kleinem top_k, sondern eher von schlechten Embeddings, ungünstigen Chunk-Größen oder einer suboptimalen Query-Formulierung. Hier hilft eine Reranking-Stufe: OpenClaw kann zwischen Vektor-Suche und LLM einen kleinen Reranker-Aufruf einbauen, der die Top-20 Treffer auf die echten Top-4 reduziert.

Retrieval glänzt, wenn dein Wissensbestand groß und stabil ist. Klassische Use-Cases: Doku-Bots über eine ganze Codebase, Customer-Support über zehntausend Tickets, Recherche-Assistenten über hunderte PDFs. In all diesen Szenarien wäre es absurd, alles in den Context zu laden. Retrieval ermöglicht den Zugriff auf praktisch unbegrenztes Wissen, ohne dass dein Modell ein Million-Token-Context-Window braucht. Der Trade-off ist Latenz: Eine Vektor-Suche braucht je nach Store und Index-Größe zwischen 10 und 200 Millisekunden, plus die Embedding-Berechnung der Query. In Summe sind das pro Turn vielleicht 100 bis 400 ms zusätzliche Wartezeit. Für die meisten Anwendungen vernachlässigbar, für Echtzeit-Voice-Agenten kann es kritisch werden.

Ein häufig übersehener Aspekt ist der Schreibvorgang. Retrieval-Memory liest nicht nur, sondern schreibt auch: Jede Konversation, jeder Tool-Output, jeder neue Fakt landet im Store. Du musst dir überlegen, was geschrieben werden soll und mit welcher Granularität. OpenClaw bietet hier ein write_policy an, mit dem du steuerst, ob alles, nur User-Nachrichten, nur finale Antworten oder explizit getaggte Items in den Store fließen. Eine zu großzügige Policy verursacht Index-Bloat und schlechtere Suchergebnisse, weil der Store mit unwichtigem Klein-Klein vollläuft. Eine zu restriktive Policy lässt wichtige Erkenntnisse durch die Lappen gehen.

Schließlich solltest du die Retention bedenken. Ein Vektor-Store wird mit der Zeit immer voller, und alte Einträge können zwar noch matchen, sind aber vielleicht inhaltlich überholt. OpenClaw unterstützt TTL pro Eintrag und Filter auf Metadaten wie client_id, topic oder freshness_score. Setz dir früh eine Strategie, sonst hast du nach sechs Monaten Produktion einen Store voller veralteter Snippets, die deinen Agenten in die Irre führen.

Persistente Memory

Egal welche Strategie du wählst: Solange dein Memory nur im RAM des laufenden Prozesses liegt, ist es bei jedem Restart weg. Für ernsthafte Produktion brauchst du einen Persistenz-Adapter. OpenClaw bringt drei Stück out-of-the-box mit: Filesystem, Redis und PostgreSQL. Du wählst per Memory(..., store_backend="redis") oder über eine Connection-String-Konfiguration in deiner openclaw.yaml. Die Wahl hängt von Skala, Latenz und Operations-Aufwand ab.

Filesystem ist die einfachste Option. Memory wird als JSON oder Pickle pro Session in einen Ordner geschrieben. Vorteil: kein zusätzlicher Service, kein Setup, perfekt für Prototyping und Single-Node-Deployments. Nachteil: keine Concurrency-Garantien, bei vielen parallelen Agenten kommt es zu File-Locks und Race-Conditions, und ab ein paar zehntausend Sessions wird das Auflisten und Aufräumen langsam. Für lokale Tests und kleine Pipelines ist Filesystem ideal, alles darüber hinaus solltest du gleich mit Redis oder PostgreSQL starten.

Redis ist der Klassiker für State-Management. Schnelle Reads und Writes, gute TTL-Unterstützung, einfaches Sharding. OpenClaw nutzt Redis-Hashes pro Session und kann optional Pub/Sub-Events für Memory-Updates auslösen, was nützlich ist, wenn mehrere Agenten gleichzeitig auf das gleiche Shared-Memory zugreifen. Operativ brauchst du einen Redis-Instance (Self-Hosted oder Managed), und du solltest dich um Persistenz kümmern, weil Redis per Default nur In-Memory arbeitet. Mit AOF-Persistence oder Snapshots ist das aber gelöst. Für die meisten Multi-Agent-Setups ist Redis die richtige Wahl: schnell, robust, einfach zu betreiben.

PostgreSQL ist die strukturierteste Variante. Memory-Einträge landen als Rows in einer Tabelle, optional mit pgvector-Extension auch direkt mit Embeddings. Der Vorteil: Du kannst SQL-Abfragen fahren, JOINs gegen User-Tabellen oder Kunden-Daten machen, und alles ist transactional. Migration zwischen Adaptern ist ebenfalls einfach: OpenClaw bringt ein openclaw memory migrate CLI-Kommando mit, das dir Memory von einem Backend in ein anderes überträgt. So kannst du in der Entwicklung mit Filesystem starten, für Staging auf Redis wechseln und für Production auf PostgreSQL gehen, ohne dein Agent-Coding anzufassen.

Context-Engineering-Patterns

Memory-Strategien sind die eine Hälfte. Die andere Hälfte ist Context-Engineering, also die bewusste Gestaltung dessen, was tatsächlich pro Turn ans Modell geht. Hier gibt es eine Handvoll Patterns, die in der Praxis den Unterschied zwischen einem teuren, langsamen Agent und einem effizienten, präzisen System ausmachen. Wer diese Patterns nicht kennt, optimiert lange am Modell und am Prompt herum, ohne zu merken, dass das eigentliche Problem im Context-Aufbau liegt.

Prompt-Layering ist das erste Pattern. Statt einen monolithischen System-Prompt zu schreiben, baust du den Context aus mehreren Layern auf: ein stabiler System-Prompt mit Rolle und Regeln, ein dynamisches Briefing pro Session, ein aktualisierbares Memory-Layer und schließlich die aktuelle User-Nachricht. Jeder Layer hat eine eigene Lebensdauer und kann unabhängig gecached werden. OpenClaw nutzt diese Struktur intern, und du kannst die Layer per prompt_template anpassen. Der Effekt: Du verstehst klar, woher welche Information kommt, und kannst gezielt optimieren, ohne dass alles zusammenklebt.

Tool-Output-Compression ist Pattern Nummer zwei. Wenn dein Tool eine 5.000-Token-Antwort liefert und davon nur 200 Token wirklich relevant sind, solltest du nicht den ganzen Output ins Memory schreiben. OpenClaw bietet tool_output_filter-Hooks, mit denen du Outputs vor dem Speichern komprimierst, bestimmte Felder extrahierst oder per Regex auf das Wesentliche reduzierst. Bei Web-Searches kannst du etwa nur Titel, URL und ersten Absatz speichern, statt den ganzen HTML-Snippet zu behalten. Das spart pro Tool-Call leicht 70 bis 90 Prozent der Tokens.

System-Prompt-Caching ist Pattern Nummer drei und besonders wirkungsvoll, wenn du viele Sessions mit dem gleichen System-Prompt fährst. Anthropic, OpenAI und Co. bieten mittlerweile Prompt-Caching an: Wenn der Anfangsteil deines Prompts identisch bleibt, wird er auf Provider-Seite gecached und kostet beim zweiten Aufruf nur einen Bruchteil. OpenClaw setzt automatisch Cache-Marker an den richtigen Stellen, wenn du die Option enable_prompt_cache=True aktivierst. Bei einem 2.000-Token-System-Prompt und tausend Sessions pro Tag spart das schnell zweistellige Prozentwerte deiner Inferenz-Kosten.

Selective Forgetting ist das vierte Pattern. Nicht alles, was im Verlauf passiert, ist langfristig wertvoll. Tool-Logs, Reasoning-Traces, fehlgeschlagene Versuche: Vieles davon kann nach einem Turn gelöscht werden, ohne dass die Qualität leidet. OpenClaw bietet eine Markierung transient=True für Memory-Items, die nach N Turns automatisch verschwinden. So bleibt dein Memory schlank, ohne dass du manuell aufräumen musst. Wer das Pattern nicht nutzt, hat nach hundert Turns Memory voller Müll.

Schließlich Context-Routing als fünftes Pattern: Manche Aufgaben brauchen viel Memory, andere kaum. Statt dem Agent immer den vollen Context zu geben, kannst du pro Tool-Call entscheiden, welche Memory-Slices wirklich gebraucht werden. OpenClaw unterstützt das über scoped_memory, mit dem du etwa für Code-Generierungs-Schritte nur Code-Memory ladest und für Recherche-Schritte nur Recherche-Memory. Das reduziert Token-Verbrauch drastisch und verbessert gleichzeitig die Treffgenauigkeit, weil das Modell weniger Rauschen verarbeiten muss.

Häufige Memory-Fehler

Memory ist eines der Themen, bei denen die meisten Bugs nicht im Code stecken, sondern in der Konfiguration. Wer sich mit den typischen Fallen vertraut macht, spart sich tagelange Debugging-Sessions. Hier sind die sechs Fehler, die in der Praxis am häufigsten auftreten, plus jeweils eine knappe Antwort, wie du sie vermeidest.

Erstens: Buffer zu klein gewählt. Klassiker bei Recherche-Agenten. Du startest mit max_messages=10, weil das im Test reicht. In Production läuft der Agent dann durch fünfzig Tool-Calls, und das ursprüngliche User-Briefing fällt nach Turn elf aus dem Buffer. Der Agent driftet ab, beantwortet plötzlich falsche Fragen, oder bricht den Task ab. Lösung: Pinning für System-Prompt und User-Briefing, oder direkt zu Summary wechseln. Buffer-Größe immer am Worst-Case-Workflow messen, nicht am Test-Szenario.

Zweitens: Summary zu aggressiv. Du setzt max_tokens=1000 und merkst, dass dein Agent ständig wichtige Details vergisst. Die Summary ist so kurz, dass nur der grobe Verlauf übrig bleibt. Lösung: Token-Budget hochziehen (4.000 bis 8.000 sind ein guter Bereich für mittellange Tasks) und das Summary-Prompt anpassen, um wichtige Datentypen wie Zahlen, Namen oder API-Resultate explizit zu erhalten. Achte zudem auf das Verhältnis: Eine Summary von 2.000 Token plus 4.000 Token aktueller Nachrichten ist meist besser als eine 500-Token-Summary mit 5.500 Token aktuellen Nachrichten, weil der historische Kontext erhalten bleibt.

Drittens: Fehlendes TTL bei Retrieval-Memory. Dein Vektor-Store wird Monat für Monat größer, alte Einträge bleiben drin, und die Suchqualität sinkt schleichend. Nach sechs Monaten findet dein Agent öfter veraltete Snippets als aktuelle. Lösung: TTL pro Eintrag setzen, plus regelmäßiger Cleanup-Job, der Items älter als X Tage löscht oder archiviert. OpenClaw hat dafür memory_ttl_days als globalen Default und einen openclaw memory cleanup CLI-Befehl, den du als Cron einbauen kannst. Plane das Aufräumen von Anfang an mit, nicht erst, wenn der Store schon zu groß ist.

Viertens: Context-Pollution durch Tool-Logs. Dein Agent ruft ein Tool auf, das ausführliche Debug-Logs ausgibt, und alle Logs landen ungefiltert im Memory. Nach zehn Turns ist dein Context voll mit Stacktraces, Timing-Infos und irrelevantem Detail. Das verwirrt das Modell und kostet Tokens. Lösung: Tool-Output-Filter konfigurieren, die nur die wirklich relevanten Felder ins Memory schreiben. Für externe APIs heißt das oft, dass du nur den Body und ausgewählte Header behältst, nicht aber Telemetry, Cookies oder Trace-IDs. Pflicht für jede produktiv eingesetzte Pipeline.

Fünftens: Shared-Memory ohne Locking. In Multi-Agent-Setups schreiben mehrere Agenten parallel ins gleiche Memory. Ohne Concurrency-Schutz überschreiben sie sich gegenseitig, und du verlierst Daten oder bekommst inkonsistente States. OpenClaw nutzt bei Redis und PostgreSQL standardmäßig optimistic Locking mit Version-Counter, aber bei Filesystem hast du das nicht. Lösung: In Multi-Agent-Szenarien auf einen Backend-Adapter mit Concurrency-Garantien wechseln. Filesystem ist nur für Single-Agent oder strikt sequenzielle Setups gedacht.

Sechstens: Privatsphäre vergessen. Memory-Stores enthalten oft sensible Daten: User-Anfragen, API-Keys aus Tool-Outputs, persönliche Informationen. Wer diese Daten unverschlüsselt speichert, hat ein Compliance-Problem, sobald DSGVO oder ähnliche Regulierung greift. Lösung: Encryption-at-Rest auf der Storage-Ebene aktivieren, sensible Felder vor dem Speichern hashen oder anonymisieren, und Lösch-Anfragen über eine API ermöglichen. OpenClaw bringt für PostgreSQL und Redis Encryption-Hooks mit, die du in einer Zeile aktivierst. Diese Hausaufgabe machst du am besten gleich am Anfang, nicht erst, wenn der erste DSGVO-Antrag eintrifft.

Nächster Schritt

Mit einem klaren Bild von Memory-Strategien und Context-Engineering bist du bereit, deine Agenten in eine echte Produktivumgebung zu bringen. Im nächsten Modul geht es um Deployment auf einem VPS: wie du OpenClaw als Systemd-Service betreibst, Logging und Monitoring aufsetzt und mit Caddy als Reverse-Proxy sicher ins Netz gehst. Modul 5 - Deployment auf VPS.