Fakten-Memory
Stabile Aussagen über Personen, Organisationen, Produkte oder Projekte. Beispiel: Kunde nutzt System X seit 2024.
Architektur-Detail · Agenten-Kontext
Graphiti (Zep) baut einen temporalen Knowledge Graphen aus Konversationen: Entitäten werden extrahiert, mit Zeitstempeln versehen und in Neo4j persistiert. POLE+O als Basis-Ontologie (Person, Object, Location, Event, Organisation). Jeder Gesprächseinstieg liest relevante Entitäten aus dem Graphen und ergänzt den LLM-Kontext automatisch.
Kuratierte Architekturentscheidung auf Basis der lokalen Compass-Daten
Relevant wenn
Wenn Kontinuität über Sessions hinweg wichtiger ist als maximale Retrieval-Geschwindigkeit und Kundenkontexte langfristig strukturiert bleiben sollen.
Quellenlage
Reales Agent-Memory-Muster aus LangGraph-Memory und Graphiti/Zep. Der Compass schneidet daraus eine Architektur für persistente, zeitbezogene Agentenerinnerung.
Agenten verlieren Kontext zwischen Gesprächen — Kunden, Ziele, Entscheidungen und offene Fragen müssen neu erklärt werden.
Systemkarte
Die Motion Map verdichtet das Muster auf seine wichtigsten Stationen: Eingabe, Daten- oder Graphschicht, Retrieval, Kontrolle und Antwort. Sie ist bewusst kleiner als die Referenzarchitektur darunter und soll zuerst die Leserichtung und die Systemgrenzen sichtbar machen.
Architekturblick
Diese Seite ist eine Entscheidungshilfe für den Stack. Der Blick liegt auf Datenfluss, Failure Modes, Evaluation, Tooling und dem nächsten sinnvollen Migrationsschritt.
Interaktionen werden in Memory-Kandidaten überführt. Fakten, Präferenzen, Entscheidungen und Ereignisse erhalten Zeit, Herkunft und Korrekturpfade.
Mit Session Summaries beginnen, dann selektive Entity Memories, zeitliche Gültigkeit, Korrektur und Governance ergänzen.
Referenzarchitektur
Agent Memory ist ein kuratierter Kontextspeicher. Ein guter Memory Stack extrahiert kontrollierte Erinnerungen aus Interaktionen, verknüpft sie mit Entitäten, Zeit und Quellen und lädt sie später selektiv wieder in den Kontext. Dadurch entsteht Kontinuität, aber auch Verantwortung: falsche oder sensible Erinnerungen müssen korrigierbar, begrenzbar und nachvollziehbar sein.
01
Gespräche, Tickets, Aufgaben, Entscheidungen oder Tool-Ergebnisse werden als mögliche Memory-Ereignisse betrachtet.
02
Das System erkennt Personen, Organisationen, Ziele, Präferenzen, offene Punkte, Entscheidungen und relevante Fakten.
03
Aliasse, Schreibweisen und wiederkehrende Referenzen werden zusammengeführt: dieselbe Person, derselbe Kunde, dasselbe Projekt oder dieselbe Aufgabe.
04
Memory bekommt Zeitbezug: wann gelernt, wann gültig, wann korrigiert, wann überholt. Ohne Zeitmodell wird Erinnerung schnell falsch.
05
Beim nächsten Gespräch werden passende Memory-Knoten über Entitäten, Zeit, Relevanz und Aufgabenbezug geladen.
06
Nutzer oder Systeme müssen falsche Memories korrigieren, sensible Inhalte entfernen und veraltete Erinnerungen begrenzen können.
Implementierungs-, Integrations- und Betriebsaufwand.
Qualität, Struktur und Zugänglichkeit der Daten vor dem Pilot.
Erfahrung mit RAG, Graphdenken, Infrastruktur und Evaluation.
Datenschutz, Korrekturworkflows oder Entitätsqualität noch ungeklärt sind.
Entitätsextraktion aus Gesprächen ist fehleranfällig — falsch verknüpfte Entitäten sind schwer zu korrigieren. Datenschutz-Anforderungen: alle Kundendaten landen im Graphen. Spürbare Latenz beim Kontext-Laden zu Gesprächsbeginn.
Memory-Modell
Memory wird erst brauchbar, wenn verschiedene Erinnerungstypen getrennt werden. Ein Fakt, eine Präferenz, eine Entscheidung und ein Ereignis haben unterschiedliche Lebensdauer, Risiken und Korrekturregeln.
Stabile Aussagen über Personen, Organisationen, Produkte oder Projekte. Beispiel: Kunde nutzt System X seit 2024.
Nutzer- oder Teampräferenzen, etwa Kommunikationsstil, Formate, bevorzugte Tools oder wiederkehrende Anforderungen.
Beschlüsse, Begründungen, offene Fragen und Verantwortlichkeiten aus Gesprächen oder Arbeitsprozessen.
Zeitlich gebundene Ereignisse: Meeting, Ticket, Supportfall, Workshop oder Analyseauftrag mit Quellen und Verlauf.
Qualitätshebel
Memory macht Agenten nützlicher, aber auch riskanter. Schlechte Erinnerungen wirken wie falscher Kontext mit langer Lebensdauer. Deshalb gehören Auswahl, Herkunft, Konfliktbehandlung und Datenschutz in die Kernarchitektur.
Nicht alles darf gespeichert werden. Gute Architektur entscheidet, was memory-würdig ist, was nur Session-Kontext bleibt und was nie gespeichert wird.
Jede Erinnerung braucht Herkunft: Gespräch, Dokument, Tool, Nutzerkorrektur oder Systementscheidung. Sonst ist Vertrauen nicht bewertbar.
Wenn neues Memory altes Memory widerspricht, darf das System nicht still überschreiben. Es braucht Konfliktregeln und Korrekturpfade.
Memory enthält oft personenbezogene oder sensible Informationen. Rollen, Löschbarkeit, Zweckbindung und Auditierbarkeit gehören von Anfang an dazu.
Ausbaustufen
Der sichere Weg führt nicht direkt zu autonomem Langzeitgedächtnis. Erst wenn Memory-Typen, Korrekturen, Löschung und Herkunft funktionieren, sollte Memory für agentische Entscheidungen genutzt werden.
Stufe 1
Starte mit einfachen Sitzungszusammenfassungen und manueller Prüfung, bevor automatisch persistiert wird.
Stufe 2
Speichere wiederkehrende Personen, Organisationen, Projekte und offene Punkte mit Quellenbezug.
Stufe 3
Ergänze Zeit, Gültigkeit, Korrekturen und überholte Aussagen, damit Memory nicht statisch falsch wird.
Stufe 4
Füge Rollen, Löschung, Review, Konfliktbehandlung, Evaluation und Nutzereinblick hinzu.
In welchem Kontext das Muster typischerweise Sinn ergibt und welchen Beitrag es dort leistet.
Ein Agent begleitet mehrere Gespräche, Entscheidungen und Aufgaben.
Memory hält relevante Entitäten, Präferenzen und offene Punkte über Sitzungen hinweg verfügbar.
Hypothesen, Annahmen und nächste Schritte ändern sich über Wochen.
Der Stack speichert Verlauf und Kontext als strukturierte Arbeitsbasis.
Ein Agent merkt sich, dass ein Kunde Datenschutz sehr hoch priorisiert, GraphRAG erst als Pilot testen will und Neo4j bereits intern freigegeben ist.
Agent Memory speichert solche stabilen Fakten und offenen Punkte gezielt für spätere Gespräche.
Speicherwürdige Entitäten definieren
Korrekturprozess für falsche Verknüpfungen planen
Datenschutzgrenzen vor dem Pilot klären