Agent Memory in LLM Systems — Context, Persistence & Retrieval

Die fundamentale Erkenntnis: Memory ist kein Modell-Problem

Agent Memory ist kein Feature des Modells. Es ist Infrastruktur, die du um das Modell herum baust. Das Modell erinnert sich nicht. Die Infrastruktur erinnert sich. Das Modell sieht nur das, was die Infrastruktur in das Context Window legt.

Größere Context Windows (128K, 200K, 1M Tokens) lösen das Problem nicht. Sie verschieben es nur. Memory-Qualität bestimmt Agenten-Qualität.

Die fünf Memory-Typen

Short-Term / Working Memory hält die aktuelle Konversation und den laufenden Task-Kontext. Technisch umgesetzt durch Context Window und Chat History Buffer — Lebensdauer: 1 Session.

Long-Term Semantic Memory speichert Fakten, Wissen und User-Präferenzen in einer Vector DB oder einem Knowledge Graph — persistent.

Episodic Memory hält vergangene Erfahrungen, Interaktionen und Events in einem Event Store mit Timestamps — persistent.

Procedural Memory enthält System-Prompts, Agent-Code und Tool-Definitionen — quasi-permanent.

Shared / Collective Memory ist Wissen, das über Agenten oder Teams geteilt wird in einer Shared Knowledge Base — persistent.

Short-Term Memory: Das Context Window richtig nutzen

Das Problem mit naivem Chat History

Ohne Strategie entstehen drei Probleme: Token-Kosten explodieren (jede neue Nachricht schickt den gesamten Verlauf mit), Qualität sinkt durch das "Lost in the Middle"-Problem, und Latenz steigt durch lange Kontexte.

Pattern 1 — Sliding Window

Du behältst nur die letzten N Nachrichten im Context Window, ältere fallen weg. Das ist die einfachste Strategie: kein zusätzlicher LLM-Call, keine Infrastruktur, planbare Token-Kosten pro Anfrage. Der Preis: Alles außerhalb des Fensters ist für den Agenten verloren, auch eine Entscheidung vom Anfang der Session. Sliding Window passt für kurze, abgeschlossene Aufgaben, zum Beispiel einen Support-Chat mit einem klaren Anliegen.

Pattern 2 — Summarization

Sobald der Verlauf eine Schwelle überschreitet, fasst ein separater LLM-Call die älteren Nachrichten zu einer kurzen Zusammenfassung zusammen. Ins Context Window gehen dann System Prompt, Zusammenfassung und die letzten Nachrichten im Wortlaut. So bleiben Entscheidungen, Namen und offene Punkte erhalten, während die Token-Kosten pro Anfrage stabil bleiben. Zwei Dinge musst du absichern: Die Zusammenfassung darf nichts erfinden, und wichtige Fakten wie Kundennummer, Deadline oder eine getroffene Entscheidung gehören in ein festes Feld, nicht nur in den Fließtext der Zusammenfassung.

Pattern 3 — Semantic Retrieval

Statt alles mitzuschicken, holst du nur relevante Teile der Geschichte zurück. System Prompt + relevante Erinnerungen (top_k=5) + die letzten 3 Nachrichten ergibt ~2.500 Tokens statt 40.000.

Long-Term Memory: Wissen über Sessions hinweg

Vector Store — Semantische Suche

Konvertiere Erinnerungen in Embeddings, speichere sie in Qdrant, Pinecone oder pgvector, und retrieve per Similarity Search. Mem0 extrahiert automatisch atomare Fakten aus Konversationen — du musst nicht selbst definieren, was gespeichert wird.

Knowledge Graph — Strukturierte Beziehungen

Für Szenarien, in denen Beziehungen zwischen Entitäten wichtig sind: Kunde → Branche, Ansprechpartner → Präferenzen, Projekt → Status und Blocker.

Episodic Memory: Lernen aus Erfahrung

Ein Support-Agent mit Episodic Memory erinnert sich: "Letztes Mal, als ein Kunde aus der Automotive-Branche das gleiche Problem hatte, war die Lösung X. Der erste Versuch Y hat nicht funktioniert." Das ist Erfahrungswissen — kein Fakten-Retrieval, sondern "was hat funktioniert und was nicht?"

Das Memory-Framework-Ökosystem 2026

Mem0 hat die breiteste Adoption mit Dual-Store (Vector + Graph) und automatischer Fakt-Extraktion. LangGraph Memory integriert sich nahtlos mit LangChain für komplexe Agentic Workflows. Zep glänzt bei zeitabhängigen Fakten und langen Konversationen. Redis Agent Memory Server bietet die niedrigste Latenz für latenz-kritische Agenten.

Architektur-Patterns

Pattern 1: Read-Write Memory

1. Memory READ — relevante Erinnerungen für den aktuellen Input suchen
2. Context Assembly — System Prompt + Memories + History + User Input
3. LLM Response — Agent generiert Antwort
4. Memory WRITE — neue Fakten extrahieren und speichern

Pattern 2: Reflection-Based Memory

Nach einer Session reflektiert ein separater LLM-Call und extrahiert Meta-Wissen: was gut funktioniert hat, was nicht, und Lehren für zukünftige Interaktionen.

Pattern 3: Autonomous Memory Orchestration

Der Agent entscheidet selbst wann er Memory liest, schreibt oder aktualisiert. Memory-Operationen werden als Tools definiert: memory_search, memory_store, memory_update, memory_forget.

Memory-Qualität: Die vergessene Dimension

Memory Bloat entsteht ohne Filterung. Ein Beispiel: Nach 1.000 Sessions hast du 50.000 Entries, davon angenommen 80 % irrelevant. Lösung: Relevanz-Scoring bei der Extraktion.

Memory Drift entsteht wenn veraltete Fakten nicht aktualisiert werden. Lösung: Conflict Detection und Temporal Awareness.

Halluzinierte Erinnerungen entstehen wenn das LLM Fakten "extrahiert" die nie gesagt wurden. Lösung: Confidence Scores und Verification.

Die 80/20-Regel für Memory

Mit Short-Term Memory Management (Sliding Window + Summarization) und einfacher Long-Term Memory (Vector Store + Fakt-Extraktion) deckst du die meisten Use Cases ab. Qualität der Erinnerungen schlägt Quantität — ein Agent der sich an die richtigen 50 Fakten erinnert ist wertvoller als einer mit 50.000 Fakten.