Agent-Memory — Kurzzeit- und Langzeitgedächtnis von KI-Agenten
Ein KI-Agent, der nach jedem Schritt vergisst, was er gerade getan hat, ist kein Agent — er ist ein Chatbot mit Extraschritt. Agent-Memory ist der Sammelbegriff für alle Mechanismen, mit denen ein Agent Information über den aktuellen Arbeitsschritt hinaus verfügbar hält: was gerade im Kontextfenster steht (Kurzzeitgedächtnis) und was in einem externen Speicher liegt, aus dem bei Bedarf nachgeladen wird (Langzeitgedächtnis). Dieser Artikel trennt beide Ebenen sauber, zeigt die gängigen Architekturmuster von 2026 und die Stellen, an denen Memory-Systeme in der Praxis reißen.
Kurzzeitgedächtnis: das Kontextfenster als Arbeitsspeicher
Das Kontextfenster eines Sprachmodells ist von Natur aus flüchtig — es existiert nur für die Dauer einer einzelnen Anfrage und ist danach weg. Für einen Agenten, der mehrere Schritte hintereinander ausführt (Werkzeug aufrufen, Ergebnis lesen, nächsten Schritt planen), heißt das: Der bisherige Verlauf muss bei jedem neuen Aufruf erneut mitgeschickt werden, sonst „vergisst” das Modell, was es gerade tut.
Das ist die einfachste Form von Memory — der Agent-Loop hängt Beobachtungen, Tool-Ergebnisse und Zwischenschritte einfach an den wachsenden Prompt an. Funktioniert gut für kurze Aufgaben, stößt aber schnell an zwei Grenzen:
- Größe. Auch ein großes Fenster ist endlich. Lange Agenten-Läufe mit vielen Tool-Aufrufen (Datei-Dumps, Suchergebnisse, Logs) füllen es erstaunlich schnell.
- Qualität. Ein volles Fenster leidet unter dem Lost-in-the-Middle-Effekt — Information in der Mitte eines langen Verlaufs wird schlechter genutzt als Information am Rand.
Die Reaktion darauf heißt in der Praxis Context Editing: Ältere Tool-Ergebnisse werden automatisch aus dem aktiven Kontext entfernt, sobald ein Schwellenwert überschritten ist — vorausgesetzt, das Wichtige wurde vorher in einen externen Speicher geschrieben. Genau hier beginnt Langzeitgedächtnis.
Langzeitgedächtnis: externe Memory-Stores und Vektor-DBs
Sobald Information über eine einzelne Anfrage hinaus erhalten bleiben soll — über viele Schritte, über das Ende einer Session oder über mehrere Sessions hinweg —, reicht das Kontextfenster nicht mehr. Der Agent braucht einen externen Speicher, aus dem er gezielt das Relevante zurückholt, statt alles ständig mitzuschleppen.
Drei Bauformen sind 2026 verbreitet:
- Vektor-Store-basiert. Vergangene Interaktionen, extrahierte Fakten oder Nutzerpräferenzen werden als Embeddings in einer Vektor-Datenbank abgelegt und per semantischer Suche zurückgeholt — im Grunde RAG, nur dass die Wissensbasis die eigene Interaktionshistorie des Agenten ist statt einer Dokumentensammlung.
- Dateibasiert. Der Agent schreibt und liest strukturierte Notizen als Dateien — Anthropics Memory-Tool für die Claude Developer Platform funktioniert so: Claude legt Erkenntnisse, Zwischenstände und Zusammenfassungen als lokale Dateien an, bevor der zugehörige Tool-Output aus dem Kontext gelöscht wird, und kann später gezielt wieder darauf zugreifen.
- Graph-basiert. Statt flacher Vektor-Treffer wird ein zeitlich annotierter Wissensgraph aufgebaut (Entitäten, Beziehungen, Gültigkeitszeiträume), der Fragen wie „was galt zum Zeitpunkt X” robuster beantwortet als reine Ähnlichkeitssuche — der Ansatz hinter Tools wie Zeps Graphiti-Engine.
Eine nützliche Unterscheidung aus der Praxis, die sich 2026 etabliert hat, sind vier Memory-Typen: Working Memory (der aktuelle Kontext), Episodic Memory (konkrete vergangene Ereignisse — „am Montag hat der User X gesagt”), Semantic Memory (extrahierte, verallgemeinerte Fakten und Präferenzen — „der User bevorzugt kurze Antworten”) und Procedural Memory (gelernte Vorgehensweisen des Agenten selbst). Ein produktives Memory-System kombiniert typischerweise mehrere dieser Ebenen statt nur einer.
Wie Agenten Kontext über Schritte und Sessions halten
Technisch läuft das Halten von Zustand über zwei Ebenen:
- Innerhalb eines Laufs (Schritt zu Schritt). Agenten-Frameworks wie LangGraph führen dafür einen expliziten State durch den Graphen — jeder Node liest und schreibt einen gemeinsamen Zustand, ein Checkpointer persistiert ihn nach jedem Schritt in einer Datenbank. Fällt der Prozess aus, kann der Lauf am letzten Checkpoint fortgesetzt werden, statt neu zu starten.
- Über Sessions hinweg (Tag zu Tag, Nutzer zu Nutzer). Hier kommt eine Session- oder Thread-ID ins Spiel, an die der externe Memory-Store gebunden ist. Meldet sich derselbe Nutzer oder derselbe Auftrag erneut, lädt der Agent gezielt die zur ID gehörenden Erinnerungen — nicht den kompletten Verlauf, sondern eine kuratierte, meist zusammengefasste Auswahl.
Wichtig ist die Konsolidierung dazwischen: Ein roher Chat-Verlauf wird selten 1:1 als Langzeitgedächtnis gespeichert. Stattdessen extrahiert ein separater Schritt (oft ein zweiter, günstigerer LLM-Aufruf) die relevanten Fakten und schreibt nur diese fort — Rohdaten wachsen sonst unbegrenzt und werden bei der Rückholung unpräzise.
Praxis: Frameworks und Werkzeuge
Ein paar konkrete Umsetzungen, an denen sich die Konzepte festmachen lassen:
- Anthropics Memory-Tool + Context Editing (Claude Developer Platform, seit 2025 als Beta verfügbar): dateibasiertes Gedächtnis, kombiniert mit automatischer Bereinigung alter Tool-Ergebnisse aus dem aktiven Kontext.
- Letta (früher MemGPT): überträgt das Betriebssystem-Prinzip von virtuellem Speicher auf LLMs — der Agent selbst entscheidet per Funktionsaufruf, was vom „RAM” (aktiver Kontext) auf die „Festplatte” (Archivspeicher) ausgelagert wird und wann er es zurückholt.
- Mem0: eine dedizierte Memory-Schicht, die Erinnerungen aus Interaktionen extrahiert, ablegt und über eine API wieder bereitstellt — framework- und vektor-DB-agnostisch, für Personalisierung über viele Sessions.
- Zep: baut statt flacher Vektor-Treffer einen zeitlichen Wissensgraphen auf, gedacht als Antwort auf das Problem veralteter oder widersprüchlicher Erinnerungen.
Welches Werkzeug passt, hängt vom Anwendungsfall ab: Für einen Support-Bot mit Nutzerpräferenzen reicht oft ein einfacher Vektor-Store. Für einen Agenten, der wochenlang an einem Projekt arbeitet und dabei widersprüchliche Zwischenstände vermeiden muss, lohnt sich ein Graph-Ansatz oder ein OS-artiges Speichermodell.
Stolperfallen in der Praxis
- Veraltete Erinnerungen. Ein Fakt, der letzten Monat stimmte („Kunde nutzt Plan Basic”), kann heute falsch sein. Ohne Zeitstempel oder Graph-Struktur landen widersprüchliche Erinnerungen unkommentiert nebeneinander im Speicher — der Agent trifft dann Entscheidungen auf Basis überholter Information.
- Halluzinierte Erinnerungen. Bei der Extraktion von Fakten aus Gesprächen kann das extrahierende Modell Dinge hinzudichten, die so nie gesagt wurden. Diese falschen Erinnerungen wirken beim Abruf genauso überzeugend wie echte — ein Grund, extrahierte Fakten stichprobenartig zu prüfen.
- Kontext-Verschmutzung. Zu aggressives Zurückladen alter Erinnerungen bläht den Kontext wieder auf und bringt den Lost-in-the-Middle-Effekt zurück, den Memory eigentlich vermeiden sollte. Nicht alles Gespeicherte gehört in jeden neuen Prompt.
- Kosten und Latenz. Jeder Speicher- und Abrufvorgang kostet zusätzliche LLM- und Embedding-Aufrufe. Bei sehr häufigen, kurzen Interaktionen kann der Memory-Overhead die eigentliche Aufgabe an Rechenzeit übersteigen.
- Datenschutz. Langzeitgedächtnis heißt: personenbezogene Daten (Präferenzen, Gesprächsinhalte, Verhaltensmuster) liegen dauerhaft in einem Speicher, nicht nur flüchtig im Kontext einer Anfrage. Löschkonzepte, Aufbewahrungsfristen und ein Opt-out sind hier keine Kür, sondern DSGVO-Pflicht, sobald Nutzerdaten betroffen sind.
FAQ
Ist Agent-Memory dasselbe wie RAG? Nicht ganz. RAG holt in der Regel Wissen aus einer externen, meist statischen Dokumentensammlung. Agent-Memory speichert und holt die eigene Interaktionshistorie und daraus gelernte Fakten des Agenten zurück — die Retrieval-Technik dahinter überschneidet sich oft (Embeddings, Vektor-Suche), der Inhalt ist aber ein anderer.
Reicht ein größeres Kontextfenster nicht aus, um Memory-Probleme zu lösen? Nein. Ein größeres Fenster verschiebt nur die Grenze, ab der externe Speicherung nötig wird — es bleibt endlich, teuer pro Anfrage und anfällig für Lost-in-the-Middle. Für Wissen, das über Sessions hinweg erhalten bleiben soll, braucht es unabhängig von der Fenstergröße einen externen Speicher.
Was ist der Unterschied zwischen episodischem und semantischem Memory? Episodisches Memory speichert konkrete Ereignisse mit Kontext („am 3. September hat der Kunde X gefragt”). Semantisches Memory speichert die daraus verallgemeinerte, entzeitlichte Erkenntnis („der Kunde bevorzugt kurze Antworten”). Produktive Systeme nutzen meist beides — episodisch für Nachvollziehbarkeit, semantisch für schnellen, kompakten Abruf.
Wie verhindere ich, dass ein Agent widersprüchliche Erinnerungen sammelt? Am robustesten mit einem zeitlich annotierten Speicher (Graph oder Zeitstempel je Eintrag), der neue Fakten explizit gegen bestehende prüft und veraltete als überholt markiert statt sie kommentarlos stehen zu lassen. Ohne diese Prüfung akkumulieren sich Widersprüche unbemerkt.
Muss ich Agent-Memory selbst bauen oder gibt es fertige Lösungen? Für die meisten Anwendungsfälle lohnt sich der Griff zu einer bestehenden Memory-Schicht (etwa Mem0 oder Zep) oder zum Persistence-Mechanismus des genutzten Agenten-Frameworks (etwa LangGraphs Checkpointer), statt Extraktion, Speicherung und Abruf komplett neu zu bauen. Eigenbau lohnt sich erst bei sehr spezifischen Anforderungen an Datenschutz oder Speicherstruktur.