Agent Memory vs. RAG: verwandt, nicht dasselbe
Die kurze Antwort: RAG holt aus einem Korpus, den du dem System vorab gegeben hast. Agent Memory sammelt sich aus dem, was der Agent selbst erlebt: die Entscheidungen, die er traf, die IDs, die er anlegte, die Vorlieben, die du genannt hast. RAG ist ein Bibliotheksausweis. Memory ist ein Tagebuch. Beide beinhalten Abruf, und genau deshalb verschwimmt Agent Memory vs. RAG, und Teams bauen immer wieder zuerst das Falsche.
Die Verwirrung ist verständlich. Unter der Haube nutzen beide oft Embeddings, beide machen Ähnlichkeitssuche, und Anbieter beschreiben beide mit dem Wort "Retrieval". Aber Daten, Schreibpfad und Job sind verschieden, und wer sie verwechselt, bekommt Agenten, die dein Handbuch zitieren können, während sie deinen Namen vergessen.
Wofür RAG da ist
Retrieval Augmented Generation beantwortet eine Frage: Wie bekommt das Modell das richtige Wissen im richtigen Moment? Du bereitest einen Korpus vor (Doku, Richtlinien, alte Tickets), zerlegst und embeddest ihn, und bei einer Frage zieht das System die relevantesten Stücke in den Kontext. Der Korpus ist von Menschen verfasst, vorab vorbereitet und aus Sicht des Systems nur lesbar. Ändern sich die Quelldokumente, indexierst du neu.
RAG ist das richtige Werkzeug, wenn das Wissen groß, weitgehend stabil und außerhalb des Agenten ist: ein Produkthandbuch, ein Rechtsarchiv, eine Wissensdatenbank. Gegen die Tool-Aufruf-Seite der Welt haben wir es in [MCP vs. RAG](/de/blog/mcp-vs-rag) verglichen.
Wofür Agent Memory da ist
Memory beantwortet eine andere Frage: Wie behält der Agent, was er beim Arbeiten gelernt hat? Niemand schreibt einen Korpus-Eintrag mit "der Kunde mag kurze E-Mails" oder "wir haben uns im März gegen Feature Flags entschieden" oder "die Staging-Datenbank-ID ist db_7741". Diese Fakten entstehen während der Sessions, aus der eigenen Erfahrung des Agenten, und sie sind wertlos in einem Dokumentenarchiv, aber unbezahlbar morgen um 9 Uhr.
Memory hat also einen Schreibpfad, den RAG nicht hat: Der Agent speichert Fakten, während sie passieren (ein remember-Aufruf, in MCP-Begriffen), und ruft sie später nach Thema ab. Sie ist persönlich für das Paar aus Agent und Nutzer, wächst kontinuierlich und enthält Urteile und Zustand, kein publiziertes Wissen. Die tiefere Anatomie steht im [Guide zu Memory-Schichten](/de/blog/memory-layer-for-ai-agents).
Der direkte Vergleich
| RAG | Agent Memory | |
|---|---|---|
| Quelle | Ein vorbereiteter Korpus | Die eigenen Sessions des Agenten |
| Schreibpfad | Offline-Indexierungs-Pipeline | Der Agent schreibt während der Arbeit |
| Inhalt | Publiziertes Wissen | Entscheidungen, IDs, Vorlieben, Zustand |
| Frische | So frisch wie der letzte Re-Index | Geschrieben im Moment des Geschehens |
| Geltungsbereich | Geteilt über alle Nutzer des Korpus | Gescoped auf Nutzer, Projekt oder Team |
| Typischer Fehler | Unpassende Chunks geholt | Es wurde nie etwas gespeichert |
Die letzte Zeile ist die praktische. Wenn RAG versagt, tunst du Chunking und Ranking. Wenn Memory versagt, liegt es meist daran, dass das System nie etwas aufgeschrieben hat, und kein Retrieval-Tuning repariert ein leeres Tagebuch.
Warum die Verwechslung echtes Geld kostet
Der häufige Fehler hat eine vorhersehbare Form: Ein Team merkt, dass der Agent ständig Dinge vergisst, diagnostiziert ein Wissensproblem und baut RAG über die eigene Doku. Der Agent kann jetzt wunderschön aus dem Handbuch zitieren. Er begrüßt trotzdem jede Session mit Amnesie über die Arbeit von gestern, denn die Arbeit von gestern stand nie in einem indexierbaren Dokument.
Den umgekehrten Fehler gibt es auch: Richtlinien-Handbücher Fakt für Fakt in die Agent-Memory zu stopfen, dem Tagebuch von Hand zu füttern, was in die Bibliothek gehört. Jetzt ist der Memory-Speicher mit statischem Wissen aufgebläht, der Abruf wird lauter, und die eigentlichen Session-Fakten ertrinken.
Die Regel, die beides verhindert: Hat ein Mensch es als Dokument verfasst, gehört es in RAG. Ist es während einer Session passiert, gehört es in Memory.
Sie kombinieren sich, und die Rohre können geteilt sein
Ein fähiger Agent nutzt beides, oft über dasselbe Protokoll. Eine RAG-Pipeline passt sauber in ein MCP-Tool (search_docs), und Memory kommt ebenfalls als MCP-Tools (remember, recall). Aus Sicht des Agenten sind beide nur Tools in der Liste; aus deiner werden sie von völlig verschiedenen Pipelines gefüttert.
Deshalb halten wir die Verbindungsschicht für ein natürliches Zuhause von Memory: Ein Gateway sieht jeden Tool-Aufruf des Agenten, und genau dieser Erfahrungsstrom ist der Stoff, aus dem Memory besteht. Das ist das Design hinter den Memory-Tools in [Tulimoas Gateway](/de/gateway) (unser Produkt, offen gesagt), wo remember und recall neben den RAG-Tools stehen, die du verbindest, und die beiden aufhören, verwechselt zu werden, weil jedes seinen Platz hat.
Häufige Fragen
Ist Agent Memory nur RAG über Gesprächs-Logs?
Nein. Rohe Transkripte zu indexieren holt Rauschen: Sackgassen, Retries, geschwätzigen Tool-Output. Memory funktioniert, weil Fakten beim Schreiben ausgewählt werden (diese Entscheidung, diese ID, diese Vorliebe), das ist Kuration, kein Archivieren. Ein durchsuchbares Log ist ein Fallback, keine Memory-Schicht.
Brauche ich RAG, wenn mein Agent Memory hat?
Für Dokumentenwissen ja. Memory wird kein 400-Seiten-Handbuch aufsaugen, und sollte es nicht. Nutze RAG für die Bibliothek, Memory für das Tagebuch, und lass den Agenten beides aufrufen.
Kann dieselbe Vektor-Datenbank beides bedienen?
Technisch oft ja, architektonisch sollten es trotzdem getrennte Speicher mit getrennten Schreibpfaden und Geltungsbereichen sein. Geteiltes Korpus-Wissen mit Session-Fakten pro Nutzer in einem Index zu mischen erzeugt Relevanz-Probleme und Datenschutz-Probleme zugleich.