Agent-Memory ist der persistente State, den ein KI-Agent zu Beginn jeder Runde liest und am Ende zurückschreibt. Ohne ihn ist jede Konversation ein Kaltstart — der Nutzer wiederholt denselben Kontext, der Agent vergisst die letzte Woche, und der Workflow regressiert zu einer schicken Autocomplete. Mit ihm akkumuliert der Agent echtes Arbeits-Wissen über Sessions.
Die drei Schichten von Agent-Memory.
- Short-Term. Der Konversations-Buffer für die aktuelle Runde. Lebt im Context-Window. Wird am Ende der Session geleert.
- Working Memory. Mid-Session-Scratchpad: der aktuelle Plan des Agenten, was er bereits versucht hat, was er über die Aufgabe weiss. In einem strukturierten Store ausserhalb des Context-Windows gehalten, sodass er wachsen kann, ohne den Prompt aufzublähen.
- Long-Term. Die persistente Schicht, die Sessions überlebt. Nutzer-Präferenzen, akkumulierte Fakten, frühere Interaktionen, retrievte-und-bestätigte Information. Gestützt von einem Vektor-Store oder einer typisierten Datenbank.
Der Read/Write-Kontrakt.
Ein arbeitender Agent deklariert, welche Memory er zu Beginn jeder Runde liest und welche er am Ende zurückschreibt. Reads sind strukturierte Queries (gib mir die letzten fünf Runden; gib mir das User-Preferences-Objekt). Writes sind typisierte Events (record, dass der Nutzer DM Mono bevorzugt; record, dass der Agent Tool X schon versucht hat). Memory-Operationen sind Teil des Observability-Traces.
«Memory ohne Kontrakte ist nur Nostalgie.»
Häufige Failure-Modes.
Unbegrenztes Memory-Wachstum — jede Runde fügt Zeilen hinzu, Retrieval verlangsamt, Kosten explodieren. Veraltete Memory — der Agent nutzt selbstbewusst einen Fakt von vor drei Monaten, der nicht mehr wahr ist. Cross-User-Kontamination — Memory von einem Nutzer leakt in die Session eines anderen, weil der Partitioning-Key falsch war. Alle drei werden gefangen, indem Memory-Operationen in die Eval-Harness geschrieben werden und das Verhalten des Agenten auf synthetischen zeit-verschobenen Fixtures gradet wird.
Häufige Fragen.
- Was ist Agent-Memory?
- Agent-Memory ist der persistente State, den ein KI-Agent zu Beginn jeder Runde liest und am Ende zurückschreibt. Sie hat üblicherweise drei Schichten: Short-Term (Konversations-Buffer), Working Memory (Mid-Session-Scratchpad) und Long-Term (Cross-Session-persistenter Storage wie ein Vektor-Store oder eine typisierte Datenbank).
- Warum nicht einfach alles im Context-Window halten?
- Weil das Context-Window begrenzt und teuer ist. Past 100k Tokens degradiert Qualität (Lost-in-the-Middle) und Kosten wachsen linear. Working Memory und Long-Term-Memory leben ausserhalb des Context-Windows; der Agent liest nur das, was er braucht, in jeder Runde in den Prompt.
- Wie sieht Memory-Failure in Produktion aus?
- Drei Muster: unbegrenztes Wachstum (Memory fügt weiter Zeilen hinzu, bis Retrieval verlangsamt und Kosten explodieren), Veraltetheit (der Agent nutzt selbstbewusst einen veralteten Fakt) und Cross-User-Kontamination (Memory eines Nutzers leakt in die Session eines anderen). Alle drei werden gefangen, indem Memory-Operationen zur Eval-Harness hinzugefügt werden und auf synthetischen zeit-verschobenen Fixtures gegradet wird.
- Wo speichert Morvion Agent-Memory?
- pgvector innerhalb der bestehenden Postgres für Long-Term-Memory, eine typisierte Tabelle oder Redis für Working Memory und der Konversations-Buffer im Context-Window für Short-Term. Memory-Operationen sind versioniert und nachverfolgbar durch dieselbe Observability-Schicht wie der Rest des Agenten.
Englische Fassung: Agent-Memory on the EN edition.