Kurz erklärt
Memory ist mehr als Chatverlauf
Ein Sprachmodell ist nicht automatisch ein dauerhaft erinnerndes System. Der Anwendungskontext muss bei jedem Aufruf bereitgestellt oder über einen externen Speicher wiederhergestellt werden. Agenten-Frameworks ergänzen deshalb Mechanismen für Session History, persistenten Zustand und gezielten Retrieval-Zugriff.
OpenAI unterscheidet in seinem Agents SDK beispielsweise zwischen Session Memory, das Gesprächsverlauf über mehrere Runs erhält, und separatem Agent Memory, das Erfahrungen aus früheren Läufen verdichtet und für spätere Aufgaben wieder nutzbar macht. Microsoft trennt ebenfalls Conversation Sessions von Context Providern und persistentem Memory. Diese Unterscheidung ist für die Bewertung eines Produkts wichtiger als ein allgemeines Label „hat Memory“.
Memory-Arten
Session, Working State und Langzeit-Memory unterscheiden
Gesprächskontext
Nachrichten und Tool-Ergebnisse einer laufenden Unterhaltung werden zwischen mehreren Agentenläufen wiederverwendet. Das hilft bei Rückfragen und mehrstufigen Dialogen.
Temporärer Arbeitszustand
Zwischenergebnisse, Variablen, offene Schritte oder Workflow-Status bleiben während einer Aufgabe verfügbar, ohne dauerhaftes Nutzerprofil zu werden.
Sitzungsübergreifend
Ausgewählte Präferenzen, Fakten, Erfahrungen oder Zusammenfassungen werden gespeichert, damit spätere Sitzungen davon profitieren können.
Relevantes wiederfinden
Statt alles in den Prompt zu laden, sucht das System passende frühere Inhalte – häufig über Embeddings oder andere Retrieval-Verfahren.
Erfahrungen aus früheren Runs
Ein Agent kann Zusammenfassungen erfolgreicher oder problematischer Abläufe speichern und diese bei ähnlichen Aufgaben als Orientierung nutzen.
Geteilter Kontext
Mehrere Worker oder Agenten können auf denselben Speicher zugreifen. Das erhöht Koordination, verlangt aber besonders saubere Mandanten- und Rechteisolation.
Diese Begriffe sind keine universell normierte Taxonomie. Anbieter und Frameworks verwenden unterschiedliche Namen. Für eine belastbare Bewertung muss deshalb immer geprüft werden, welcher konkrete Speichermechanismus gemeint ist.
Architektur
Wie funktioniert Agenten-Memory technisch?
- Information entsteht.
Eine Nachricht, ein Tool-Ergebnis, eine Nutzerpräferenz oder ein Ergebnis aus einem Agentenlauf könnte später relevant sein.
- Write Policy entscheidet.
Nicht alles sollte gespeichert werden. Regeln bestimmen, welche Inhalte persistiert, zusammengefasst, verworfen oder vor dem Speichern bereinigt werden.
- Speicher ordnet zu.
Informationen werden typischerweise einer Session, einem Nutzer, einer Organisation, einem Agenten oder einem anderen Scope zugeordnet.
- Retrieval wählt aus.
Vor einem späteren Run wird nicht notwendigerweise der gesamte Speicher geladen. Stattdessen können die relevantesten Erinnerungen gesucht und in den Kontext eingefügt werden.
- Agent nutzt Kontext.
Das Modell erhält die ausgewählten Inhalte zusammen mit aktueller Aufgabe, Instruktionen und gegebenenfalls Tool-Ergebnissen.
- Lifecycle greift.
TTL, Korrektur, Löschung, Verdichtung und neue Versionen entscheiden, welche Erinnerungen langfristig erhalten bleiben.
Wichtige Abgrenzung
Session History ist nicht dasselbe wie Langzeit-Memory
OpenAI Sessions speichern Gesprächshistorie für eine bestimmte Session und laden sie bei späteren Runs automatisch wieder. Das eignet sich für Multi-Turn-Konversationen und resumierbare Abläufe. Langfristiges Agent Memory verfolgt ein anderes Ziel: Erkenntnisse aus vergangenen Runs werden verdichtet und nur bei späterer Relevanz wieder herangezogen.
Microsoft Agent Framework beschreibt denselben Architekturunterschied über Sessions und Context Providers. Eine Session hält den Konversationszustand zusammen; ein Memory Provider kann frühere Inhalte zusätzlich in einem Vektorspeicher ablegen und anhand semantischer Ähnlichkeit wiederfinden.
Memory vs. Wissen
Ist RAG dasselbe wie Memory?
Nein. Retrieval-Augmented Generation (RAG) bedeutet grundsätzlich, dass externe Wissensquellen zur Laufzeit durchsucht und relevante Inhalte in den Modellkontext geholt werden. Das kann ein Unternehmenswiki, eine Dokumentensammlung oder eine Datenbank sein. Memory bezieht sich dagegen auf Informationen, die aus vorherigen Interaktionen, Zuständen oder Agentenläufen stammen und später wiederverwendet werden.
Technisch können beide Systeme sehr ähnlich aussehen: Vektorspeicher, Embeddings und semantische Suche kommen sowohl bei Wissens-RAG als auch bei Chat-History-Memory zum Einsatz. Microsoft dokumentiert beispielsweise einen ChatHistoryMemoryProvider, der frühere Nachrichten in einem Vector Store speichert und vor späteren Aufrufen semantisch ähnliche Nachrichten abruft.
RAG fragt: „Welches externe Wissen brauche ich jetzt?“ Memory fragt: „Welche frühere Information aus diesem Nutzungskontext sollte ich jetzt wieder berücksichtigen?“
Nutzen
Wann verbessert Memory einen Agenten wirklich?
Langfristige Aufgaben
Projektstatus, offene Punkte und Entscheidungen bleiben zwischen mehreren Arbeitssitzungen verfügbar.
Persönliche Präferenzen
Wiederkehrende Format-, Kommunikations- oder Arbeitspräferenzen müssen nicht jedes Mal neu erklärt werden.
Support & Service
Ein Agent kann frühere Interaktionen oder den Verlauf eines Falls berücksichtigen, sofern Berechtigungen und Datenschutz stimmen.
Einmalige Aufgabe
Bei einer isolierten Recherche oder Transformation bringt persistentes Memory oft wenig zusätzlichen Nutzen.
Aktuelles Faktenwissen
Für veränderliche externe Fakten ist eine aktuelle Datenquelle häufig geeigneter als eine gespeicherte Erinnerung.
Regelgebundene Prozesse
Deterministische Regeln und Datenbanken sollten nicht durch unscharfe „Erinnerungen“ ersetzt werden.
Risiken
Memory erweitert auch die Angriffs- und Fehlerfläche
Persistentes Memory kann Fehler verlängern. Eine falsche Information in einem einzelnen Chat ist unangenehm; eine falsche Information, die dauerhaft gespeichert und in vielen späteren Runs erneut eingeblendet wird, kann systematisch falsches Verhalten verursachen.
Manipulierte Informationen werden gespeichert und beeinflussen spätere Sitzungen. OWASP nennt Memory Poisoning ausdrücklich als agentenspezifisches Risiko.
Eine Erinnerung kann im falschen Nutzer-, Team- oder Agentenkontext wieder auftauchen, wenn Scoping und Isolation fehlerhaft sind.
Eine frühere Präferenz, Rolle oder Prozessregel kann inzwischen ungültig sein, aber weiterhin als Kontext eingespielt werden.
Wenn nicht nachvollziehbar ist, woher eine Erinnerung stammt, kann der Agent ihre Vertrauenswürdigkeit nur schwer bewerten.
Mehr Memory ist nicht automatisch besser. Unnötige personenbezogene oder vertrauliche Inhalte erhöhen Datenschutz- und Sicherheitsrisiken.
Zu viele oder falsch priorisierte Erinnerungen können aktuelle Instruktionen und relevante neue Informationen im Kontext überlagern.
Memory Poisoning
Wie manipulierte Erinnerungen spätere Agentenläufe beeinflussen können
Memory Poisoning entsteht, wenn ein Angreifer oder eine fehlerhafte Quelle Inhalte in einen persistenten Speicher bringt, die später als vertrauenswürdiger Kontext behandelt werden. Das kann direkt über Nutzereingaben geschehen oder indirekt über Websites, Dokumente, E-Mails oder Tool-Ausgaben, wenn deren Inhalte ohne ausreichende Prüfung gespeichert werden.
OWASP empfiehlt deshalb, persistente Memory-Schreibvorgänge zu kontrollieren, Inhalte vor der Speicherung zu validieren beziehungsweise zu bereinigen, Scopes zu trennen und Erinnerungen ablaufen oder verwerfen zu können. Zusätzlich sollten sicherheitskritische Entscheidungen nie ausschließlich darauf beruhen, dass etwas „im Memory steht“.
Eine gute Architektur trennt daher Write Trust und Read Trust: Nicht jede Information darf gespeichert werden, und nicht jede gespeicherte Information erhält später denselben Vertrauensstatus.
Privacy & Governance
Memory braucht Regeln für Speicherung, Retention und Löschung
Persistentes Agenten-Memory ist automatisch ein Datenspeicher. Für Unternehmen stellen sich deshalb dieselben Fragen wie bei anderen geschäftlichen Datensystemen – ergänzt um die Besonderheit, dass gespeicherte Inhalte später dynamisch in Modellkontexte zurückkehren können.
Zu klären sind mindestens: Speicherort, Nutzer- und Tenant-Isolation, Aufbewahrungsdauer, Verschlüsselung, Zugriffsrechte, Löschung, Korrektur, Export und Protokollierung. Bei personenbezogenen Daten kommt zusätzlich die Frage hinzu, ob und auf welcher Grundlage sie überhaupt langfristig gespeichert werden sollen.
Technische Frameworks zeigen, dass diese Lifecycle-Fragen explizit modelliert werden können. OpenAI dokumentiert Session-Backends mit unterschiedlichen Speichertechniken und auch Wrapper mit Verschlüsselung und TTL. Das bedeutet aber nicht, dass jedes darauf aufgebaute Produkt dieselben Retention- oder Löschgarantien bietet. Solche Aussagen müssen immer produktbezogen belegt werden.
Isolation
Wem gehört eine Erinnerung?
Eine der wichtigsten Architekturentscheidungen ist der Scope. Memory kann an eine Session, einen einzelnen Nutzer, ein Team, einen Tenant, einen Agenten oder eine Aufgabe gebunden sein. Je größer der Scope, desto größer der mögliche Nutzen – und desto höher das Risiko einer unerwünschten Weitergabe.
OpenAI weist in der Agents-SDK-Dokumentation darauf hin, dass Memory-Isolation von der verwendeten Layout- und Conversation-Konfiguration abhängt. Microsoft warnt bei serverseitigen Conversation-IDs ebenfalls davor, IDs lediglich clientseitig zu übernehmen; Anwendungen müssen den authentifizierten Nutzer oder Tenant vor einer Wiederaufnahme verifizieren.
Memory sollte standardmäßig im kleinstmöglichen sinnvollen Scope liegen. Gemeinsames Team- oder Multi-Agent-Memory sollte eine bewusste Architekturentscheidung sein.
Kontextmanagement
Warum Agenten nicht einfach „alles erinnern“
Kontextfenster, Kosten und Relevanz machen unbegrenzte Gesprächshistorie unpraktisch. Frameworks nutzen deshalb verschiedene Strategien: alte Nachrichten kürzen, Konversationen kompakt zusammenfassen, nur die letzten N Einträge laden oder semantisch relevante Inhalte selektiv abrufen.
Diese Mechanismen verändern die Semantik von Memory. Eine Zusammenfassung ist nicht identisch mit dem Originalverlauf; ein semantischer Retriever kann relevante Einträge übersehen oder irrelevante Treffer liefern. Für kritische Prozesse sollten deshalb Primärdaten und verbindliche Systemzustände weiterhin in dafür vorgesehenen Datenbanken oder Fachsystemen liegen.
Unternehmens-Checkliste
Agenten-Memory vor dem produktiven Einsatz prüfen
- Memory-Typ bestimmen.
Geht es um Session History, Workflow-State, Langzeit-Memory oder externen Wissensabruf?
- Write Policy definieren.
Welche Informationen dürfen automatisch gespeichert werden – und welche niemals?
- Scope begrenzen.
Session, Nutzer, Team, Tenant und Agent müssen sauber voneinander getrennt sein.
- Sensible Daten klassifizieren.
Personenbezogene Daten, Secrets und vertrauliche Geschäftsinformationen brauchen eigene Regeln.
- Retention festlegen.
Wie lange bleibt eine Erinnerung gespeichert? Gibt es TTL oder automatische Ablaufregeln?
- Löschung testen.
Kann ein Eintrag gezielt entfernt werden und verschwindet er auch aus abhängigen Indizes oder Vektorspeichern?
- Korrektur ermöglichen.
Veraltete oder falsche Erinnerungen müssen aktualisierbar sein, ohne alte Fehler weiter zu propagieren.
- Memory Poisoning testen.
Manipulierte Websites, Dokumente und Nutzereingaben dürfen nicht ungeprüft dauerhaft Vertrauen erlangen.
- Retrieval prüfen.
Welche Kriterien bestimmen, welche Erinnerungen in einen neuen Run einfließen?
- Provenienz erhalten.
Wo möglich sollte erkennbar bleiben, wann und aus welchem Kontext eine Erinnerung entstanden ist.
- Audit und Zugriff sichern.
Speicherzugriffe und Änderungen müssen für sensible Umgebungen kontrollierbar und nachvollziehbar sein.
- Fallback definieren.
Der Agent sollte auch dann sinnvoll reagieren, wenn Memory fehlt, beschädigt oder nicht erreichbar ist.
AgentenCode
Warum AgentenCode „Memory“ nicht als einfaches Ja/Nein behandeln sollte
Ein Produkt kann Gesprächshistorie behalten, ohne sitzungsübergreifende Nutzererinnerungen zu besitzen. Ein anderer Agent kann langfristige Präferenzen speichern, aber keinen gemeinsam nutzbaren Team-Speicher anbieten. Wieder ein anderes System nutzt Retrieval aus einem Vektorspeicher, ohne selbstständig Erinnerungen zu schreiben.
Für AgentenCode ist deshalb eine feldgenaue Modellierung sinnvoll: Session-Kontext, persistentes Memory, Speicher-Backend, Scope, Retention, Löschung, Schreibkontrolle und Retrieval sollten nur dann als konkrete Produkteigenschaften gelten, wenn sie durch Primärquellen ausdrücklich belegt sind. Fehlende Dokumentation bleibt unknown.
Agenten vergleichen
Memory immer im Kontext von Security und Governance betrachten.
Nutze AgentenProfile und AgentenFit für dokumentierte Hosting-, Security-, Identity-, Audit- und Protokollmerkmale. Memory-spezifische Evidenz sollte dieselben Source-first-Regeln erfüllen.
Primärquellen
Grundlage dieser Memory-Referenz
- OpenAI Agents SDK – Sessions ↗Persistenter Gesprächskontext, Session-Verhalten, Speicher-Backends, Clear-/Pop-Operationen und Session-Strategien.
- OpenAI Agents SDK – Agent Memory ↗Abgrenzung von Session Memory und langfristig nutzbaren Erinnerungen, Memory-Generierung, Isolation und Aktualisierung.
- Microsoft Agent Framework – Conversations & Memory ↗Sessions, Persistenz und Sicherheitsgrenzen beim Wiederaufnehmen serverseitiger Conversations.
- Microsoft Agent Framework – Memory & Persistence ↗Persistent Context, Präferenzen, frühere Interaktionen und Context Provider.
- Microsoft Agent Framework – Chat History Memory Provider ↗Speicherung von Chat-Historie im Vektorspeicher und semantischer Abruf relevanter früherer Nachrichten.
- OWASP – AI Agent Security Cheat Sheet ↗Memory Poisoning als agentenspezifisches Risiko und Empfehlungen für sichere Speicherung und Tests.
Letzte redaktionelle Prüfung: 2. Oktober 2026. „Memory“ ist kein einheitlich standardisiertes Produktmerkmal; konkrete Fähigkeiten, Speicherorte und Retention-Regeln müssen pro Produkt separat geprüft werden.
FAQ
Häufige Fragen zu Memory bei KI-Agenten
Was bedeutet Memory bei KI-Agenten?
Memory umfasst Mechanismen, mit denen ein Agent Informationen über einen einzelnen Modellaufruf hinaus speichert, wiederfindet oder bei späteren Aufgaben erneut verwendet.
Was ist der Unterschied zwischen Session Memory und Langzeit-Memory?
Session Memory hält Kontext innerhalb einer Unterhaltung oder eines Threads verfügbar. Langzeit-Memory speichert ausgewählte Informationen so, dass sie auch in späteren Sitzungen erneut genutzt werden können.
Ist RAG dasselbe wie Memory?
Nein. RAG holt externes Wissen in den Modellkontext. Memory verwendet Informationen aus früheren Interaktionen oder Agentenläufen. Beide können technisch ähnliche Retrieval-Verfahren einsetzen.
Was ist Memory Poisoning?
Memory Poisoning bedeutet, dass manipulierte oder falsche Inhalte dauerhaft gespeichert werden und dadurch spätere Agentenentscheidungen beeinflussen.
Welche Daten sollte ein KI-Agent speichern dürfen?
Nur Daten, die für einen klar definierten Zweck erforderlich sind. Sensible oder personenbezogene Inhalte brauchen strengere Regeln für Zugriff, Retention, Löschung und Isolation.
Braucht jeder KI-Agent Langzeit-Memory?
Nein. Für viele einmalige oder aktuelle Aufgaben reichen Session-Kontext, Fachsysteme oder ein gezielter Wissensabruf aus.
Wie kann Agenten-Memory gelöscht werden?
Das hängt vom Produkt und Speicher-Backend ab. Gute Architekturen bieten Lösch-, Clear-, TTL- oder Korrekturmechanismen; ihre konkrete Wirkung muss produktbezogen geprüft werden.
Warum ist Memory ein Datenschutzthema?
Persistente Erinnerungen können personenbezogene, vertrauliche oder organisationsbezogene Informationen langfristig speichern und später wieder in Modellkontexte einfügen.
Ist mehr Memory immer besser?
Nein. Zu viel, veraltetes oder schlecht kuratiertes Memory kann Kontext verschlechtern, Kosten erhöhen und Sicherheits- sowie Datenschutzrisiken vergrößern.