Memory für KI-Agenten entwerfen: Ebenen, Schreibregeln, Poisoning und DSGVO

Große Sprachmodelle sind zustandslos. Alles, woran sich ein Agent „erinnert", ist Text, den dein System wieder in den Prompt legt. Die spannenden Engineering-Fragen betreffen deshalb die Schleife um das Modell: was geschrieben wird, wo, von wem, wie es wiedergefunden und wie es entfernt wird. Memory ist auch der Punkt, an dem Agenten aufhören, eine Demo zu sein. Ein Coding-Agent, der dein Repository jeden Morgen neu lernt, oder ein Support-Agent, der zum dritten Mal dieselbe Frage stellt, ist ein Memory-Problem.

Memory ist außerdem eine Angriffsfläche und eine Datenschutz-Verpflichtung, was die meisten Tutorials auslassen. In diesem Artikel gehe ich durch die Ebenen, die ich verwende, die drei Gedächtnisarten, eine Schreibrichtlinie mit expliziter „Nie speichern"-Liste, Retrieval, Compaction, Poisoning und DSGVO, und vergleiche dann, wie ChatGPT, Claude und OpenAI dots es heute lösen. Er baut auf der Funktionsweise der Agent-Schleife und auf dem Bedrohungsmodell aus dem Artikel zur Lethal Trifecta auf.

Drei Ebenen: Arbeitskontext, Session, Langzeit

Ich trenne Memory gern nach Lebensdauer, weil sie entscheidet, wer schreiben darf, wie gelöscht wird und was es kostet. Die Forschung sieht das ähnlich. MemGPT hat das Problem wie ein Betriebssystem beschrieben: Es verwaltet verschiedene Gedächtnisebenen, um dem Modell einen erweiterten Kontext zu geben, und verschiebt Informationen zwischen schnellem und langsamem Speicher wie zwischen RAM und Festplatte.

Der Arbeitskontext ist das Fenster selbst. Es ist teuer und es degradiert: Anthropic beschreibt „Context Rot", also dass mit wachsender Tokenzahl im Kontextfenster die Fähigkeit des Modells sinkt, Informationen daraus genau abzurufen. Der Session-Zustand ist das, was du für eine Aufgabe oder einen Thread aufbewahrst, damit eine Unterbrechung den Fortschritt nicht zerstört, etwa eine Fortschrittsdatei oder eine Zusammenfassung. Das Langzeitgedächtnis überlebt Sessions und ist die einzige Ebene, auf der Datenschutz, Poisoning und Löschung dauerhafte Probleme werden.

Für das Design folgt daraus: Der Arbeitskontext wird bei jedem Aufruf neu aufgebaut und darf so verrauscht sein, wie die Aufgabe es verlangt. Der Session-Zustand sollte klein, strukturiert und vom Harness verwaltet sein. Das Langzeitgedächtnis braucht ein Schreib-Gate, denn alles, was es passiert, behandelt der Agent später als sein eigenes Wissen.

Episodisch, semantisch, prozedural: was du wirklich speicherst

Das CoALA-Paper von Sumers, Yao, Narasimhan und Griffiths ordnet Sprach-Agenten um ein Arbeitsgedächtnis und drei Langzeitarten aus der Kognitionswissenschaft: episodisch, semantisch und prozedural. Die Trennung ist praktisch, weil jede Art einen anderen Schreibauslöser, ein anderes Abrufmuster und einen anderen Fehlermodus hat.

Das Generative-Agents-Paper von Stanford und Google zeigt, warum episodisches Gedächtnis allein nicht reicht: Die Agenten speichern Erlebnisse in natürlicher Sprache und „synthesize those memories over time into higher-level reflections", so werden aus Ereignissen semantisches Wissen. Die Idee würde ich übernehmen, den Reflexionsschritt aber nachvollziehbar halten. Prozedurales Gedächtnis verdient das meiste Misstrauen, denn ein Memory, das ändert, wie der Agent handelt, ist näher an Code als an Daten. Wenn Agenten eigene Skills schreiben dürfen, behandle sie wie einen Pull Request (siehe Coding-Agent-Skills).

Was du wann schreibst und was du nie speicherst

Die meisten Memory-Systeme scheitern am Schreibpfad. Entweder schreibt der Agent alles (und das Retrieval ertrinkt im Rauschen) oder er schreibt nach Laune (und Wichtiges fehlt). Ich würde eine Schreibrichtlinie explizit definieren, statt sie allein dem Modell zu überlassen. Die Dokumentation des Claude Memory Tools weist in dieselbe Richtung: Du kannst steuern, was Claude schreibt, etwa indem du nur Informationen zu einem bestimmten Thema festhalten lässt, und du kannst eine Validierung ergänzen, die sensible Daten entfernt, bevor dein Handler eine Datei speichert.

Schreibe zu wenigen klar definierten Zeitpunkten statt kontinuierlich: wenn der Nutzer eine stabile Präferenz oder Korrektur nennt, am Ende einer Aufgabe (Ergebnis, Entscheidungen, offene Fragen) und kurz bevor Kontext gelöscht oder verdichtet wird. Die Context-Editing-Dokumentation von Anthropic beschreibt Letzteres: Es arbeitet mit dem Memory Tool zusammen, damit Claude wichtige Informationen im Memory sichern kann, bevor Inhalte gelöscht werden. Jeder Eintrag sollte Owner, Quelle, Zeitstempel, Geltungsbereich (Nutzer, Projekt, Mandant) und ein Ablauf- oder Prüfdatum tragen.

Was ich nie speichern würde, egal was der Agent vorschlägt:

• Geheimnisse und Zugangsdaten. API-Keys, Tokens und Passwörter gehören in einen Tresor. Anthropic merkt an, dass Claude sensible Informationen meist nicht in Memory-Dateien schreibt, empfiehlt für stärkere Garantien aber eine eigene Validierung. dots gehen weiter und sagen, ihr Kontext behalte keine Zugangsdaten, Bilder oder Screenshots.
• Kennungen und besondere Kategorien wie amtliche Ausweisnummern, Kontonummern, Vorstrafen und Einwanderungsstatus. Claude schließt genau diese standardmäßig aus, und Gesundheit, Religion, Politik und Identität sind aus, solange der Nutzer nicht zustimmt.
• Rohe Tool-Ausgaben und Webinhalte. Fasse geprüfte Fakten zusammen, speichere aber keine Seiten oder Dokumente wörtlich: Sie können Anweisungen enthalten, die dann im vertrauten Memory deines Agenten liegen.
• Schlüsse über Personen, die der Nutzer nicht von sich aus genannt hat, und alles, womit der Nutzer nicht rechnet. Ist Überraschung wahrscheinlich, frag vorher.
• Personenbezogene Daten Dritter (Kunden, Kollegen), sofern du keinen definierten Zweck und keine Rechtsgrundlage dafür hast.

Erinnerungen abrufen, ohne den Kontext zu fluten

Memory, das man nicht findet, ist nur Speicher. Ich würde mit dem einfachsten Muster beginnen, das funktioniert, und erst Mechanik ergänzen, wenn Evals sie nötig machen. Anthropic nennt die zugrunde liegende Idee Just-in-Time-Retrieval: Statt alles vorab zu laden, hält der Agent leichtgewichtige Bezeichner wie Dateipfade und lädt Daten bei Bedarf. Das Memory Tool folgt dem, denn Claude sieht zuerst das Memory-Verzeichnis an und öffnet dann nur die relevanten Dateien.

• Erst eingrenzen, dann suchen. Filtere zuerst nach Nutzer, Mandant und Projekt, dann ranke. Ein mandantenübergreifendes Memory-Leck ist eine Datenpanne, und ein harter Filter verhindert es viel zuverlässiger als ein Prompt.
• Mit einem kleinen Index beginnen. Eine kurze Übersichtsdatei oder ein Profil, das immer geladen wird, plus Themendateien oder Datensätze, die bei Bedarf geholt werden, funktioniert bei einigen hundert Einträgen besser als eine Vektordatenbank.
• Hybride Suche bei wachsendem Volumen. Kombiniere Schlüsselwort- und Embedding-Suche, rerank und gewichte Aktualität; die Mechanik ist dieselbe wie in einer RAG-Pipeline.
• Budget begrenzen. Injiziere nur eine feste Zahl von Erinnerungen oder Tokens und zeige dem Agenten, woher jede stammt und wann sie geschrieben wurde.
• Memory als Daten kennzeichnen. Liefere abgerufene Erinnerungen in einem klar abgegrenzten Block als Kontext zum Abwägen, nicht als Anweisungen. Das hilft, beseitigt das Poisoning-Risiko unten aber nicht.

Miss Retrieval wie jedes andere Feature: Baue eine kleine Menge von „Wäre die richtige Erinnerung gefunden worden?"-Fällen und verfolge Trefferquote und Quote falscher Erinnerungen über die Zeit (siehe LLM-Evals für Produkt-Features). Veralten ist auch ein Retrieval-Problem. Ändert sich ein Fakt, aktualisiere oder ersetze den alten Eintrag; hänge keinen Widerspruch an und hoffe, dass das Modell den neueren wählt.

Compaction und Zusammenfassung: verlustbehaftet by Design

Compaction fasst eine Unterhaltung zusammen, die an ihre Grenze stößt, und startet mit der Zusammenfassung neu. Anthropic beschreibt das als Destillieren des Kontextfensters „in a high-fidelity manner" und nennt den zentralen Zielkonflikt: Zu aggressive Compaction riskiert, subtile, aber kritische Details zu verlieren. Außerdem beschreibt Anthropic strukturiertes Notieren, bei dem der Agent regelmäßig Notizen außerhalb des Kontextfensters ablegt und später wieder liest. Im Pokémon-Beispiel hielt Claude so präzise Zählstände über Tausende Spielschritte.

Die Claude-Dokumentation beschreibt die Arbeitsteilung gut: Context Editing löscht bestimmte Tool-Ergebnisse, Compaction fasst die ganze Unterhaltung serverseitig zusammen, und bei langlaufenden Agenten bewahrt Memory die Informationen, die eine Zusammenfassung überleben müssen. Das Löschen von Tool-Ergebnissen löst standardmäßig bei 100.000 Input-Tokens aus und behält die letzten drei Tool-Nutzungen, also sollten wichtige Entscheidungen vorher ins Memory geschrieben werden, statt hinterher aus einer Zusammenfassung rekonstruiert zu werden.

Das hat eine Sicherheitsfolge. Eine Zusammenfassung erzeugt ein Modell, das gerade nicht vertrauenswürdige Inhalte gelesen hat, und ihr Ergebnis wird gespeichert und als vertrauenswürdig behandelt. Compaction ist ein Schreibkanal und muss dieselben Gates passieren wie jeder andere Memory-Eintrag.

Memory Poisoning: die Injection, die bleibt

Prompt Injection endet normalerweise mit der Session. Mit Memory nicht. 2024 zeigte der Forscher Johann Rehberger, dass ein manipuliertes Dokument ChatGPT dazu bringen kann, versteckte Anweisungen im Langzeitgedächtnis zu speichern, woraufhin Unterhaltungen in neuen Threads weiter an einen Angreifer-Server gesendet wurden. Im Oktober 2025 beschrieb Palo Alto Networks Unit 42 dieselbe Klasse gegen Amazon Bedrock Agents: Eine präparierte Webseite manipulierte den Zusammenfassungsschritt der Session, die eingeschleusten Anweisungen wurden gespeichert, und spätere Sessions leiteten still Nutzerdaten ab. Ihre zentrale Beobachtung: Memory-Inhalte werden in die System-Anweisungen der Orchestrierungs-Prompts eingefügt und oft höher priorisiert als die Nutzereingabe.

Ein Preprint von 2026 zu Memory Poisoning systematisiert das in vier Schreibkanäle: explizit per Anweisung ausgeführte Schreibvorgänge, vom System-Prompt getriebene Schreibvorgänge, durch Compaction getriebene Schreibvorgänge und Erfahrung-zu-Prozedur-Schreibvorgänge. Bei den zwei getesteten Agenten mit GPT-OSS-120B lag die durchschnittliche Angriffserfolgsrate bei 66,67 Prozent und 34,25 Prozent, und die vier untersuchten Prompt-Injection-Abwehrmaßnahmen ließen erhebliche Lücken. OWASP führt die Klasse inzwischen als ASI06, Memory and Context Poisoning. Die genauen Prozentwerte würde ich nicht als Prognose für dein System lesen, aber die Struktur des Problems ist klar: Je aggressiver ein Agent Memory liest und schreibt, desto größer die Angriffsfläche.

Konkret würde ich vier Kontrollen einsetzen: Schreibvorgänge nach Quelle gaten (die eigenen Nachrichten des Nutzers sind anders vertrauenswürdig als abgerufene Inhalte), jede Erinnerung mit Herkunft versehen, damit sie auditierbar und gesammelt entfernbar ist, prozedurales Memory wie Code reviewen und alle Lese- und Schreibzugriffe loggen, damit du hinterher „Warum hat der Agent das getan?" beantworten kannst. Den Agenten von ausgehenden Kanälen zu isolieren begrenzt den Schaden, wenn eine schlechte Erinnerung durchrutscht; die Muster aus dem Artikel zur Lethal Trifecta gelten unmittelbar.

DSGVO: Auskunft, Löschung und das Problem abgeleiteter Daten

Sobald ein Langzeitgedächtnis personenbezogene Daten enthält, gelten dafür die Grundsätze aus Artikel 5 DSGVO. Daten müssen für festgelegte Zwecke erhoben und nicht unvereinbar weiterverarbeitet werden (Zweckbindung), angemessen, erheblich und auf das notwendige Maß beschränkt sein (Datenminimierung), sachlich richtig und aktuell sein, wobei unrichtige Daten unverzüglich gelöscht oder berichtigt werden, und nur so lange identifizierbar bleiben wie nötig (Speicherbegrenzung). Artikel 17 gibt Betroffenen das Recht auf Löschung, unter anderem wenn die Daten für den Zweck nicht mehr notwendig sind, die Einwilligung widerrufen wurde oder die Verarbeitung unrechtmäßig war. Ein Nutzer, der fragt „Was weißt du über mich, und bitte vergiss es", stellt eine normale Anfrage, die du bedienen können musst.

• Ordne jede Erinnerung einer Person zu. Eine Nutzer- oder Betroffenen-ID an jedem Datensatz macht Auskunft und Löschung zu einer Abfrage statt zu einer Ermittlung. Auch Erinnerungen über Dritte brauchen eine Kennung.
• Lösche abgeleitete Kopien. Zusammenfassungen, Embeddings, Suchindizes, Caches und Backups sind Kopien. Speichere in jeder Ableitung die ID der Quell-Erinnerung, damit das Löschen kaskadiert.
• Standardmäßig ablaufen lassen. Speicherbegrenzung heißt Prüfdatum oder TTL an jedem Eintrag, und die Memory-Tool-Dokumentation nennt das Ablaufen lange ungenutzter Dateien als empfohlene Schutzmaßnahme.
• Anzeigen und Korrektur ermöglichen. Richtigkeit ist ein Grundsatz, kein Feature. Eine sichtbare Memory-Ansicht mit Bearbeiten und Löschen ist der günstigste Weg dahin.
• Halte Logs frei von Memory-Inhalten und behalte den Verarbeitungsort im Blick; zur Datenresidenz siehe DSGVO und LLM-APIs.

Hier unterscheiden sich die Produkte am stärksten, wie der nächste Abschnitt zeigt. Das ist keine Rechtsberatung; kläre Rechtsgrundlage und Aufbewahrungsfristen mit deiner Datenschutzbeauftragten oder deinem Datenschutzbeauftragten. Die technische Anforderung ist aber eindeutig: Ein Memory, das du nicht pro Eintrag einsehen, korrigieren oder löschen kannst, ist schwer zu verteidigen.

Wie aktuelle Produkte Memory lösen

Die folgenden Angaben stammen aus der Dokumentation der Anbieter (Stand 2. Oktober 2026) oder aus Quellen, die sie zitieren; die OpenAI-Hilfeseiten blockierten meinen automatisierten Zugriff, daher stütze ich mich bei ChatGPT und dots auf Suchauszüge der Hilfeartikel und auf einen Beitrag, der die dots-Dokumentation zitiert. Prüfe den aktuellen Wortlaut, bevor du dich auf ein Detail verlässt.

Drei Details fallen auf. ChatGPT führt ein Protokoll gelöschter gespeicherter Erinnerungen bis zu 30 Tage lang für Sicherheit und Debugging, und eine Erinnerung überlebt das Löschen des Chats, aus dem sie stammt. Claude begrenzt Memory pro Projekt, aktiviert es standardmäßig in den Plänen Free, Pro und Max und überlässt es bei Team und Enterprise den Owners. Bei dots sagt die Dokumentation, dass du einzelne Dot-Erinnerungen weder ansehen, korrigieren noch löschen kannst, dass das Trennen eines Plugins nicht löscht, was der Dot daraus gelernt hat, und dass alles, was der Dot dem ChatGPT Memory hinzugefügt hat, nach dem Löschen des Dots bestehen bleibt. Für einen persönlichen Assistenten mag das akzeptabel sein; für ein Unternehmen, das ihn mit Kundendaten verbindet, ist es zuerst eine DSGVO-Frage. Das größere Bild diskutiere ich in der dots-Impact-Analyse.

Eine Checkliste für das Memory-Design

In dieser Reihenfolge würde ich bei einem neuen Agenten vorgehen:

1. Schreibe auf, welche Ebenen du brauchst. Viele Agenten brauchen nur Arbeitskontext plus eine Fortschrittsdatei pro Session.
2. Wähle die Gedächtnisarten und gib jeder eine eigene Datensatzform und eigenen Ablauf.
3. Definiere die Schreibrichtlinie: Auslöser, erlaubte Quellen und die „Nie speichern"-Liste. Setze Quellenprüfungen im Code um, nicht nur im Prompt.
4. Versieh jeden Datensatz mit Owner, Quelle, Zeitstempel, Geltungsbereich und Ablauf.
5. Grenze das Retrieval nach Mandant und Nutzer ein, bevor du rankst; begrenze die injizierten Tokens.
6. Leite die Ausgabe von Compaction und Zusammenfassung durch dieselben Schreib-Gates.
7. Reviewe prozedurales Memory wie Code; verlange Freigabe für Erinnerungen, die das Verhalten ändern.
8. Gib Nutzern eine Ansicht mit Bearbeiten, Löschen und Pausieren; lass die Löschung auf abgeleitete Daten kaskadieren.
9. Logge Lese- und Schreibzugriffe und teste vor dem Launch mit Poisoning-Fällen und Retrieval-Evals.

Meine Empfehlung

Fang klein an: eine Fortschrittsdatei pro Session und ein kurzes, für Nutzer sichtbares Profil-Memory. Ergänze episodisches Langzeitgedächtnis erst, wenn du in deinen Evals zeigen kannst, dass es die Ergebnisse verbessert, und prozedurales Memory zuletzt und mit Review. Die Produkte zeigen, wohin der Markt geht, nämlich zu Agenten, die standardmäßig erinnern, aber auch die offenen Fragen: Kontrolle, Löschung und Vertrauen in das Erinnerte. Wenn du auf der API baust, ist das Memory Tool genau deshalb ein gutes Referenzdesign, weil es Speicher, Validierung und Löschung in deine Hände legt.

Quellen

1. Anthropic docs: Memory tool
2. Anthropic docs: Context editing
3. Anthropic Engineering: Effective context engineering for AI agents
4. Sumers et al.: Cognitive Architectures for Language Agents (CoALA)
5. Packer et al.: MemGPT, Towards LLMs as Operating Systems
6. Park et al.: Generative Agents, Interactive Simulacra of Human Behavior
7. Unit 42: When AI Remembers Too Much, persistent behaviors in agents memory
8. From Untrusted Input to Trusted Memory: A Systematic Study of Memory Poisoning Attacks in LLM Agents (preprint)
9. The Hacker News: ChatGPT macOS flaw could have enabled long-term spyware via memory function
10. Vectorize: OWASP ASI06, Memory and Context Poisoning explained
11. Claude Help Center: Use chat search and memory to build on previous context
12. OpenAI Help Center: Memory in ChatGPT
13. OpenAI Help Center: Dots privacy, security, and safety FAQs
14. Flavio Copes: A deep dive into OpenAI dots (quotes the dots documentation on memory)
15. GDPR Article 5: Principles relating to processing of personal data
16. GDPR Article 17: Right to erasure