AI Architecture · 10 Min.
RAG vs. Agent Memory: Warum viele KI-Systeme Kontext mit Erinnerung verwechseln
RAG beantwortet Fragen mit externem Wissen. Memory veraendert, wie ein Agent spaeter arbeitet. Wer beides vermischt, baut schwer kontrollierbare Systeme.
SYSTEMS Grafik zu RAG vs Agent Memory: Data -> Agent -> Outcome. Fokus: Wann Unternehmen RAG, Memory oder beide Konzepte fuer KI-Agenten brauchen.
Kurzfassung
RAG holt Wissen zur Laufzeit in eine Antwort. Agent Memory speichert, was spaeter Verhalten verbessern soll. Unternehmen brauchen fuer beide Schichten getrennte Regeln, sonst entsteht unkontrollierter Kontext.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknuepfe es mit den naechsten Architekturentscheidungen.
Der Unterschied in einem Satz RAG beantwortet: "Was weiss das Unternehmen dazu?" Memory beantwortet: "Was soll der Agent aus frueheren Laeufen lernen?"
Diese Unterscheidung klingt klein, ist aber architektonisch gross. RAG ist eine Wissenszugriffsschicht. Memory ist eine Verhaltens- und Zustandschicht.
Stand Mai 2026: Retrieval, Sessions und Memory werden getrennte Produkte Die Plattformen ziehen die Grenze inzwischen deutlicher. OpenAI beschreibt Retrieval und File Search ueber Vector Stores, in denen Dateien gechunkt, eingebettet und indexiert werden. Google Vertex AI Agent Engine trennt Sessions, State und Memory. MCP trennt Resources, Tools und Prompts.
Das ist die Kernthese: RAG ist nicht Memory. RAG findet Wissen. Memory veraendert, was ein Agent spaeter erinnert, priorisiert oder personalisiert.
Ein Unternehmen sollte deshalb nie fragen: "Brauchen wir RAG oder Memory?" Die bessere Frage ist: "Welche Kontextschicht braucht welcher Workflow?"
Anthropic beschreibt bei produktiven Agenten bewusst einfache Patterns wie Retrieval und In-Context-Beispiele, bevor komplexe Autonomie gebaut wird. Das ist fuer Unternehmen wichtig: Memory ist kein Reifegrad-Abzeichen. Manchmal ist ein sauberer Abruf aus kuratierten Quellen genau die robustere Architektur.
Wann RAG reicht RAG reicht, wenn der Agent vor allem Wissen aus Dokumenten, Datenbanken oder Webseiten braucht. Beispiele: interne Richtlinien, Produktdokumentation, technische Spezifikationen, Angebotsbausteine oder Support-Artikel.
Wichtig ist die Qualitaet des Abrufs: gute Chunking-Strategie, Metadaten, Zugriffskontrolle, Aktualitaet und klare Quellenanzeige. Ein schlechter RAG-Index macht den Agenten nicht klueger, sondern sicherer im Falschen.
Ein RAG-System braucht mindestens:
Ohne diese Details ist RAG nur eine Suchbox mit KI-Antwort.
OpenAI macht bei Retrieval genau diese Richtung sichtbar: Dateien landen in Vector Stores, werden verarbeitet, in durchsuchbare Einheiten zerlegt und koennen ueber Attribute gefiltert werden. Fuer Unternehmen heisst das: Metadaten sind kein Nice-to-have. Sie sind die Stelle, an der Mandant, Rolle, Dokumenttyp, Aktualitaet und Berechtigung in den Abruf eingebaut werden.
Dokument-Ingestion mit Owner und Quelle. Parsing fuer PDF, HTML, Markdown, Tabellen oder Tickets. Chunking-Regeln und Metadaten. Zugriffskontrolle pro Rolle, Kunde oder Workspace. Retrieval-Parameter wie Top-K, Filter und Hybrid Search. Quellenanzeige und Aktualitaetsdatum. Loesch- und Reindex-Prozess. Wann Memory notwendig wird Memory wird relevant, wenn sich der Agent an wiederkehrende Praeferenzen, Korrekturen oder Prozessentscheidungen erinnern soll. Zum Beispiel: Welche Tonalitaet ein Kunde bevorzugt, welche Lead-Kriterien intern geschaerft wurden oder welche Aktionen in einem Prozess nie automatisch passieren duerfen.
Memory darf aber kein Log-Muell sein. Wenn jede Korrektur gespeichert wird, entsteht ein widerspruechliches Selbstbild des Agenten.
Google beschreibt Memory Bank als Schicht, die aus Sessions Memories erzeugen kann, inklusive Created, Updated und Deleted Actions. Genau diese Revision ist wichtig: Memory muss korrigierbar sein. Ein Agent darf nicht fuer immer an einer falschen Beobachtung kleben.
Gleichzeitig ist Memory riskanter als viele Demos zeigen. Wenn aus Sessions automatisch Erinnerungen entstehen, koennen auch sensible oder personenbezogene Informationen in diese Schicht rutschen. Deshalb braucht Memory immer Scope, Review, Loeschbarkeit und klare Regeln, welche Beobachtungen niemals gespeichert werden.
Sessions, State, Memory und RAG Eine saubere Architektur trennt:
OpenAI Conversation State ist ein guter Gegenpol: Dort geht es um fortsetzbare Verlaeufe mit Messages, Tool Calls und Tool Outputs. Das ist wertvoll fuer lange Jobs oder mehrere Devices, aber es ist noch keine kuratierte Langzeit-Erinnerung mit Governance. State speichert Verlauf. Memory entscheidet, welche Information aus diesem Verlauf spaeter Verhalten veraendern darf.
Wenn ein Agent Live-CRM-Daten in Memory speichert, entstehen Datenschutz- und Aktualitaetsprobleme. Wenn er Memory ueber RAG sucht, kann er private Praeferenzen wie allgemeines Unternehmenswissen behandeln. Beides ist falsch.
Session: die laufende Interaktion und ihre Events. State: temporaere Arbeitsdaten innerhalb eines Runs. RAG: externer Wissensabruf aus kuratierten Quellen. Memory: persistente, scoped Informationen ueber Nutzer, Kunden oder Prozesse. Tool-Zugriff: Live-Daten aus Systemen wie CRM, Tickets oder Kalender. Governance fuer Memory Gutes Memory braucht Lebenszyklusregeln:
Ohne diese Regeln entsteht eine unsichtbare Entscheidungsschicht. Genau das ist in Unternehmen gefaehrlich.
Was darf gespeichert werden? Aus welchem Anlass wird Memory erzeugt? Wer darf Memory korrigieren? Wann verfaellt eine Erinnerung? Welche Informationen sind sensibel? Wie wird Memory getestet? Wie wird widerspruechliche Memory geloescht oder ersetzt? Kontextkosten und Tool-Bloat Memory und RAG haben auch Kostenfolgen. Anthropic beschreibt bei langen Agentenlaeufen, dass Tool-Definitionen und Tool-Ergebnisse den Kontext aufblaehen. Tool Search, Prompt Caching und Context Editing sind Gegenmittel.
Das gilt genauso fuer RAG und Memory. Wer zu viele Dokumente, zu viele Memories und zu viele Tool-Outputs in jeden Run packt, macht den Agenten teurer und schlechter. Kontextarchitektur ist deshalb auch Kostenarchitektur.
Der SYSTEMS-Blick Wir bauen RAG und Memory getrennt. RAG bekommt Quellen, Berechtigungen und Aktualitaet. Memory bekommt Zweck, Scope und Pflegeprozess.
So kann ein Agent besser werden, ohne dass er sich zufaellige Aussagen merkt oder Unternehmenswissen ausserhalb der Governance kopiert.
