Memory-Augmented-Agent: Kontext über Sessions behalten

Kern des Patterns

Memory-Augmented Agent ist ein Pattern, bei dem der Agent eine eigene Memory-Layer hat: Er speichert wichtige Fakten, ruft sie bei Bedarf ab und nutzt sie in spaeteren Schritten oder Sessions.

Wann sinnvoll: wenn Fakten zwischen Schritten oder Sessions erhalten bleiben und in spaeteren Entscheidungen genutzt werden muessen.

Statt des Modells "jede Anfrage beginnt bei null" macht der Agent Folgendes:

• nuetzliche Fakten aus der Interaktion erfassen
• in strukturierter Memory speichern
• vor der Antwort relevante Eintraege abrufen
• veraltete Eintraege aktualisieren oder loeschen

Problem

Stell dir vor, du arbeitest mit einem Agenten ueber mehrere Sessions.

In der ersten Session gibst du Regeln vor:

• schreibe auf Ukrainisch
• antworte kurz
• beachte eine Ausnahme fuer Enterprise-Kunden

In der naechsten Session "vergisst" der Agent das, und alles muss wiederholt werden.

Ohne gesteuerte Memory sieht jede neue Session fuer den Agenten wie die erste aus.

Folgen:

• inkonsistente Antworten
• unnoetige Wiederholungen fuer Nutzer
• Fehler durch fehlenden Kontext
• geringerer Nutzen in langen Workflow

Das ist das Problem: ohne Memory-Layer sammelt der Agent keinen nuetzlichen Kontext und arbeitet nur im aktuellen Request.

Loesung

Memory-Augmented fuehrt memory-policy fuer Schreiben und Retrieval ueber Sessions ein.

Analogie: wie eine Kundenkarte im Service. Es wird nur Wichtiges gespeichert, nicht jedes Wort aus dem Chat. So startet die naechste Interaktion mit relevantem Kontext.

Schluesselprinzip: Memory muss selektiv und steuerbar sein, nicht "alles speichern".

Der Agent kann vorschlagen, was gespeichert werden soll, aber die Memory-Layer bestimmt:

• was geschrieben werden darf
• was fuer eine neue Anfrage abgerufen wird
• wann ein Eintrag veraltet ist und geloescht werden muss

Gesteuerter Prozess:

1. Capture: bedeutende Fakten extrahieren
2. Store: mit Metadata speichern (source, timestamp, TTL)
3. Retrieve: relevante Memory abrufen
4. Apply: in den Antwortkontext einbauen
5. Update/Delete: veraltete Eintraege entfernen

Das liefert:

• Konsistenz zwischen Sessions
• Personalisierung ohne wiederholte Anweisungen
• kontrolliertes Speichern von Entscheidungen und Ausnahmen
• weniger manuelle Wiederholungen fuer Nutzer

Funktioniert gut, wenn:

• nur bedeutende Fakten gespeichert werden
• eine Schreib-/Lese-Policy existiert (privacy + scope)
• der Lifecycle umgesetzt ist (TTL, update, delete)
• Retrieval relevante und aktuelle Eintraege liefert

Das Modell kann "wollen", alles zu merken, aber memory-policy bestimmt den langfristigen Kontext.

Wie es funktioniert

Memory ist nicht gleich vollstaendige raw chat history.

In production wird nicht alles gespeichert, sondern nur wichtige Fakten mit Datum, Quelle und Record-Lifecycle-Policy.

Im Code sieht das so aus

facts = extract_memory_facts(user_message)

approved = supervisor.review_memory_write(
    user_id=user_id,
    items=facts,
)

memory.upsert(user_id=user_id, items=approved)

relevant = memory.search(
    user_id=user_id,
    query=goal,
    top_k=5,
)

context = build_context(base_context, memory_items=relevant)
answer = agent.respond(context)

return answer

Memory muss gesteuert werden: mit Groessenlimits, Update-Regeln und Entfernen veralteter Fakten.

So sieht das waehrend der Ausfuehrung aus

Goal: Antwort mit gespeicherten Nutzerpraeferenzen personalisieren

Session 1:
User: Schreibe Antworten auf Englisch und kurz.
Memory saved:
- language = en (source=session_1)
- response_style = concise (source=session_1)

Session 2:
User: Erklaere den Unterschied zwischen SLA und SLO.
Retrieve:
- language = en
- response_style = concise

Agent response:
- auf Englisch
- im kurzen Format

Wann es passt - und wann nicht

Passt

Passt nicht

Denn die Memory-Layer fuegt operativen Overhead hinzu: Speicherung, Indexierung, Retention und Privacy-Control.

Unterschied zu RAG

RAG beantwortet: "was sagt die Wissensbasis".

Memory-Augmented beantwortet: "was ist wichtig ueber diesen Nutzer und Prozess zu merken".

Wann Memory-Augmented verwenden (vs andere Patterns)

Verwende Memory-Augmented, wenn Kontext zwischen Schritten oder Sessions gespeichert und wiederverwendet werden muss.

Kurzer Test:

• wenn du "Praeferenzen, Entscheidungen und Nutzerzustand merken" musst -> Memory-Augmented
• wenn du "Fakten aus externen Dokumenten fuer aktuelle Anfrage finden" musst -> RAG Agent

Wie man es mit anderen Patterns kombiniert

• Memory + RAG: der Agent kombiniert persoenlichen Kontext mit verifizierten Quellen, damit Antwort sowohl korrekt als auch nutzerrelevant ist.
• Memory + ReAct: in jedem Schritt beruecksichtigt der Agent fruehere Entscheidungen, um gleiche Aktionen nicht zu wiederholen.
• Memory + Supervisor: Supervisor kontrolliert, was in Memory geschrieben und daraus gelesen werden darf.

Kurz gesagt

Vorteile und Nachteile

FAQ

Q: Bedeutet Memory, dass der Agent absolut alles merkt?
A: Nein. In production werden nur nuetzliche Fakten nach Auswahlregeln, TTL und Sicherheitsregeln gespeichert.

Q: Wie verhindert man das Speichern sensibler oder unnoetiger Daten?
A: Man nutzt data classification, redaction, Feld-Allowlist und retention/delete-Policies.

Q: Was tun bei veralteter oder widerspruechlicher Memory?
A: timestamp und confidence hinzufuegen, kritische Eintraege revalidieren und neuere Fakten priorisieren.

Was als Naechstes

Memory-Augmented fuegt dem Agenten langfristigen Kontext hinzu.

Aber wie prueft man vor dem Senden an Nutzer, dass die finale Antwort konsistent und frei von offensichtlichen Fehlern ist?