2026-06-20 · Aktualisiert 2026-07-22

[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.

AI Agent Memory: Schema-Guided Typisierte Zustandsverwaltung für langlaufende Systeme

Langlaufende AI Agents ziehen häufig veraltete Informationen ab, da herkömmliche Semantic Memory keine Regelung vorsieht, um zu bestimmen, welcher Wert aktuell gültig ist.

Wenn ein Benutzer den Fristtermin eines Passes von 15. Juli auf 30. Juni ändert, kann eine Vector Search sowohl die alte als auch die neue Angabe liefern. Eine Zustandsmemorielage muss daher festhalten, dass der Wert vom 30. Juni den früheren ersetzt.

Zusammenfassung: Behandeln Sie eine dauerhafte Agent-Memory als typisierten Anwendungs-Zustand. Extrahieren Sie mögliche Memorieneinträge über eine Grenze für Structured Output, speichern Sie die Einträge mit Scope für den jeweiligen Tenant, Gültigkeitsfenstern, Überlagerungsregeln, Herkunftsangaben sowie Versionsinformationen des Schemas und holen Sie beim Lesen stets den aktuellsten Teil ab. Nutzen Sie Vector Search ausschließlich für ungenaue Suchanfragen. Lese Sie veränderbare Fakten aus den aktuell gültigen, eingeschränkten Einträgen.

Die Falle des Context Windows

Das Context Window stellt die für einen einzelnen Model-Aufruf verfügbaren Eingabedaten dar. Eine Anwendung kann Nachrichten in spätere Aufrufe übertragen, doch die Anwendungslogik muss entscheiden, welche alten Fakten weiterhin gelten und wer sie einsehen darf.

Langlaufende Agents müssen Präferenzen, Aufgabenstatus, Kundendaten, Entscheidungen bezüglich Tools, Compliance-Hinweise sowie frühere Fehler speichern. Eine einfache Lösung besteht darin, Zusammenfassungen anzuhängen oder alte Notizen in einen Vector Store zu laden. Das funktioniert solange, bis sich einer der gespeicherten Fakten ändert.

Dann verfügt der Agent über zwei Pass-Fristen, zwei bevorzugte Formate oder zwei Projektentscheidungen. Eine Semantic Search kann beide Ergebnisse liefern. Eine Zusammenfassung könnte einen der Einträge überschreiben. Ein langer Kontext könnte den veralteten Eintrag neben den aktuellen platzieren. Solche Ansätze liefern zwar Texte zurück, stellen aber den aktuellen Wert nicht durch.

Die Anwendung muss konkrete Fragen beantworten können:

• Was gilt aktuell?
• Was galt am 2. Juni?
• Wer hat das gesagt?
• Zu welchem Tenant gehört dieser Eintrag?
• Welchen älteren Fakt hat dieser Eintrag ersetzt?
• Kann ich ihn löschen oder verfallen lassen?

Schema-Guided Agent Memory (SGAM) speichert diese Antworten als Felder und Beziehungen, anstatt sie implizit im Text zu belassen.

Was SGAM bedeutet

Drei ähnlich benannte Konzepte definieren den Umfang von SGAM.

Schema-Guided Dialogue (SGD) bezieht sich auf den 2019 Google Task-Oriented Dialogue Dataset. Sein Schema beschreibt Service-APIs, Intentionen und Slots, sodass ein Dialogmodell den Zustand von Diensten verfolgen kann, die es zuvor nicht gesehen hat. Es handelt sich dabei um einen nützlichen Vorläufer für schema-basiertes Tracking, wobei der Anwendungsbereich auf Dialogdienste beschränkt ist.

Schema-Guided Memory (SGM) ist der Forschungsbegriff, den Mei et al. in According to Me: Long-Term Personalized Referential Memory QA verwenden. In dieser Arbeit werden freitextbasierte Descriptive Memory (DM)-Elemente mit key-value-Memorieneinträgen unter Verwendung fester Schemata verglichen. Beide Darstellungsformen enthalten dieselben Quelldaten, allerdings in unterschiedlichen Strukturen.

In diesem Artikel verwende ich den Begriff Schema-Guided Agent Memory (SGAM) für ein Engineering-Pattern, bei dem Schemata die Schreibvorgänge, Aktualisierungen, Abfragen sowie Löschvorgänge steuern. Das Schema definiert somit den Anwendungs-Zustand sowie dessen Lebenszyklus.

ATM-Bench zeigt, warum diese Darstellung wichtig ist. Dabei werden etwa vier Jahre an persönlichen Daten aus E-Mails, Bildern und Videos verwendet. Die gestellten Fragen erfordern persönliche Bezüge, Standorte, mehrere Beweismittel sowie zeitliche Aktualisierungen. Bei der schwierigen Aufgabenkategorie sinkt die Leistung, während SGM im Vergleich zu DM verbesserte Ergebnisse liefert, da der Abfrager direkt auf Felder wie Zeit, Quelle, Standort, Entitäten und Tags zugreifen kann.

SGM gegenüber DM beantwortet eine Speicherfrage: Soll der Speicher als freier Text verbleiben oder sollten benannte Felder verwendet werden? Ein Produktions‑Agent hat bereits vor dem Speichern ein weiteres Problem zu bewältigen – er muss aus einer unstrukturierten Konversation auf einen vorgeschlagenen Speicher‑Update schließen. Schema‑Guided Reasoning (SGR) definiert diesen Entscheidungsweg: Die Belege werden überprüft, Subjekt und Attribut identifiziert, geprüft, ob die Tatsache den aktuellen Zustand ändert, anschließend ein Kandidat für eine Schreiboperation erstellt. SGAM wendet nach diesem Modellaufruf die Speicher‑ und Lebenszyklusregeln an.

Trennung der Modellextraktion von der Speichereigentumsverwaltung

Ein Speicher‑Write durchläuft drei Ebenen. Structured Output (SO) stellt die Struktur des Kandidatenobjekts sicher. Schema‑Guided Reasoning (SGR) kodiert die Schritte sowie die Reihenfolge, die das Modell befolgen muss, um zu diesem Kandidaten zu gelangen. Schema‑Guided Agent Memory (SGAM) verwaltet den Kandidaten als dauerhaften Zustand nach dem Modellaufruf.

Eine Entscheidung, ein Routing oder ein Plan verfallen in der Regel mit der aktuellen Anfrage. Ein späterer Aufruf kann den Speicher‑Kandidaten Tage später lesen oder ihn zur Auswahl einer Tool‑Call‑Operation nutzen. Diese längere Lebensdauer erfordert Speicherregeln, die von SGR nicht bereitgestellt werden.

SGR beschränkt einen Modellaufruf, indem es seine Reasoning‑Topologie festlegt. Bei einem Speicher‑Write kann das Schema Quellenbelege, ein normalisiertes Subjekt und Attribut sowie einen Vergleich mit dem aktuellen Zustand erforderlich machen, bevor der vorgeschlagene Update erfolgt. Pydantic oder JSON Schema beschreiben diesen Weg. Provider‑spezifischer Structured Output oder ein guideter Decoding‑Runtime wie XGrammar verhindern, dass das Modell Felder überspringt oder eine andere Struktur zurückgibt.

Das Schema kann keine korrekte Schlussfolgerung garantieren. Es macht jedoch den erforderlichen Entscheidungsweg explizit und überprüfbar – einschließlich der Belege und des Vergleichs, aus denen der Kandidat entstanden ist.

SGAM entscheidet darüber, was nach dem Bestehen des Objekts geschieht: Soll es gespeichert werden? Überlagert es eine ältere Tatsache? Welcher Benutzer kann es einsehen? Ist es aktuell oder historisch? Welches Quellen‑Episode stützt es?

Die Tabelle gibt das Eigentumsverhältnis sowie die Fehlermodi jeder Ebene an:

Auf dem Schreibweg verläuft die Abfolge wie folgt:

SGR reasoning schema + Structured Output -> candidate write -> SGAM policy and persistence

Der folgende exemplarische Auszug aus memory_models.py definiert das Objekt, das von der Extraktion an den SGAM‑Schreibdienst übergeben wird:

from datetime import datetime
from pydantic import BaseModel, Field


class MemoryDelta(BaseModel):
    tenant_id: str = Field(description="Isolation boundary, e.g. acme")
    subject: str = Field(description="Normalized entity ID, e.g. mira")
    attribute: str = Field(description="Property being updated")
    value: str = Field(description="New value")
    valid_from: datetime
    source_episode_id: str

MemoryDelta zeigt, was das Modell extrahiert hat. Der SGAM‑Schreibdienst entscheidet anschließend, ob dieses Objekt abgelehnt, zusammengeführt oder gespeichert werden soll.

Schreib- und Lesewege haben unterschiedliche Aufgaben

SGAM verfügt über einen Schreibweg und einen Leseweg. Nur der Schreibweg ändert den gespeicherten Zustand. Der Leseweg wählt die für die aktuelle Anfrage relevanten Aufzeichnungen aus.

Der Eingangsfluss ist der Schreibweg:

1. Eine rohe Episode aus Nachrichten, Tool‑Ergebnissen oder Geschäftsevents erfassen.
2. Über Structured Output typisierte Kandidaten extrahieren.
3. Das Schema validieren und fehlerhafte Einträge ablehnen.
4. Konflikte bereinigen, veraltete Fakten schließen und die Herkunft dokumentieren.
5. Die Aufzeichnung im SGAM‑Speicher persistieren.

Der Anfragenfluss ist der Leseweg:

1. Mit der Anfrage des Benutzers beginnen.
2. Entscheiden, ob derzeitiger Zustand oder Zustand zu einem bestimmten Zeitpunkt benötigt wird.
3. Nach Mieter, Speichertyp, Thema, Attribut und Gültigkeitsfenster filtern.
4. Nur dann Vektor- oder Graphenerweiterungen vornehmen, wenn eine exakte Zustandsabfrage nicht ausreicht.
5. Den kleinstmöglichen, für das Modell relevanten Kontext zusammenstellen.

Betrachten Sie dieses Diagramm von links nach rechts in zwei Spalten. Die obere Spalte schreibt in den Speicher, die untere liest daraus. Beide nutzen denselben Speicher.

Was gehört in ein Speicherschema

Ein minimales SGAM‑Objekt benötigt mehr als text.

tenant_id
memory_id
subject
attribute
value
memory_type
schema_version
valid_from
valid_to
supersedes_memory_id
source_episode_id
confidence
retention_policy

Mit diesen Feldern kann ein neuer Fristtermin einen vorherigen Termin außer Kraft setzen, ohne die Historie zu löschen. Derselbe Datensatz ermöglicht es außerdem, sowohl aktuelle als auch zeitpunktbezogene Abfragen zu beantworten und das Ergebnis anschließend auf das zugrundeliegende Ereignis zurückzuverfolgen. schema_version unterstützt Migrationsprozesse, während retention_policy den Löschvorgängen mitteilt, welche weiteren Elemente entfernt werden müssen.

Zur Dokumentenzugriffserstellung wird RAG eingesetzt, um Texte abzurufen, während SGAM eine veränderliche Zustandsverwaltung gewährleistet. Für ungenaue Suche, Clustering sowie Erweiterungen bleibt die Vektorsuche weiterhin im System erforderlich. Der aktuelle Wert von mira.passport_deadline sollte aus einem spezifizierten Speicherintrag stammen und nicht einfach aus demjenigen Chunk gewählt werden, der zufällig am höchsten rangiert.

Ein Beispiel für veraltete Fakten

Betrachten wir eine synthetische Trace mit zwei Episoden, dargestellt als DM-Baseline und SGAM-Ledger:

e1: Mira prefers concise answers. Her passport deadline is 2026-07-15.
e2: Mira corrected the deadline. It is now 2026-06-30.

Eine DM-Baseline speichert beide Episoden als freien Text, wodurch eine Textsuche e1 zurückgeben kann, da dieser die entsprechenden Wörter enthält. SGAM extrahiert hingegen aus jeder Episode einen typisierten Fakt, der nach Mieter, Thema und Attribut keygt. Es sollte dabei e2 als aktueller Zustand zurückgegeben werden, während e1 für historische Abfragen gespeichert bleibt.

Die folgende Funktion stellt den Schreibweg von SGAM dar und befindet sich in einem Store-Modul wie sgam_store.py. DM verfügt über kein Äquivalent, da sie keinen aktuellen Zeileninhalt pro Attribut bereitstellt. Bevor der Aufrufer einen Ersatz einfügt, schließt diese Funktion die aktuelle Zeile:

def close_previous_fact(db: sqlite3.Connection, fact: MemoryFact) -> int | None:
    row = db.execute(
        """
        select fact_id
        from memory_facts
        where tenant_id = ?
          and subject = ?
          and attribute = ?
          and valid_to is null
        order by valid_from desc
        limit 1
        """,
        (fact.tenant_id, fact.subject, fact.attribute),
    ).fetchone()
    if not row:
        return None

    db.execute(
        "update memory_facts set valid_to = ? where fact_id = ?",
        (fact.valid_from, row["fact_id"]),
    )
    return int(row["fact_id"])

Sobald e2 eintrifft, setzt die Funktion valid_to am aus e1 extrahierten Fakt auf das Zeitstempelwert von e2. Anschließend fügt der Aufrufer den neuen Fakt mit einem offenen valid_to ein. Da DM keinen entsprechenden Aktualisierungsmechanismus besitzt, kann der alte Text weiterhin eine höhere Priorität haben als die Korrektur.

Die Ausführung von aktuellen sowie historischen Fristabfragen gegenüber beiden Repräsentationen liefert unterschiedliche Ergebnisse:

Naive text memory:
  returned episode: e1 -> passport deadline is 2026-07-15

SGAM current state:
  mira.passport_deadline = 2026-06-30
  valid_from=2026-06-03T10:00:00Z, source=e2

SGAM point-in-time state:
  on 2026-06-02, mira.passport_deadline = 2026-07-15

In der Produktion sollte diese Transaktion mit einer strukturierten Extraktion im Schreibweg kombiniert werden. Die Datenbanktransaktion aktualisiert dabei die zeitliche Gültigkeit, während das Modell einen Kandidatenfakt extrahiert, aber nicht entscheidet, welche gespeicherte Zeile weiterhin aktuell ist.

Die Speicherauswahl orientiert sich am Abrufmuster

Projekte verwenden für verschiedene Komponenten dieses Musters unterschiedliche Bezeichnungen: Speichersysteme für Erinnerungen, Kontextgraphen, Profile, Langzeitspeicher, Graph-RAG sowie Zustandsagenten.

Graphiti stellt eine konkrete Open-Source-Implementierung relationaler, zeitbasierter Speichersysteme dar. Es verfolgt Änderungen an Fakten, speichert Verweise auf die jeweiligen Quellen und unterstützt hybride Suchverfahren. LangGraph trennt Checkpoints innerhalb eines Threads von den Speichern zwischen verschiedenen Threads. Mem0 bündelt Speicheroperationen als verwalteten Service. Letta verwendet editierbare Kontextblöcke anstelle eines fieldbasierten SGAM-Systems, behandelt den Agentenzustand jedoch weiterhin als persistente Datenstruktur.

Beginnen Sie mit dem Datenmodell. Wenn die primäre Aufgabe die genaue Abfrage von Fakten ist, reicht in der Regel eine relationale Tabelle mit JSON-Daten, Gültigkeitsspalten, Tenant-Indizes sowie einem Vektor-Backend aus. Erst wenn das Durchlaufen von Beziehungen ein wesentlicher Bestandteil des Produkts ist, sollte ein Graph hinzugefügt werden – und nicht allein wegen eines ansprechenden Graph-Demos.

Aufbau des Schreibpfads vor dem Graphen

Zunächst muss festgelegt werden, was das Produkt speichern darf. Die Entscheidung zwischen Graphen- und Vektoransatz erfolgt später.

Ein Support-Agent könnte die Kontoebene, offene Fälle sowie dauerhafte Kontaktdaten speichern. Er sollte jedoch nicht jeden frustrierten Nutzer dauerhaft im Profilstatus speichern, nur weil dieser einmal abgerufen wurde. Ein Coding-Agent könnte Repository-Konventionen sowie ungelöste Aufgaben merken. Auch er sollte keine privaten Notizen ewig aufbewahren, nur weil diese ein einziges Mal abgerufen wurden.

Beginnen Sie mit dem Schreibpfad und betrachten Sie das Speichern als eine kleine Zustandsänderung:

1. Geben Sie dem Speichertyp, dem Thema, dem Tenant-Bereich sowie der Aufbewahrungsklasse einen Namen.
2. Extrahieren Sie potenzielle Datensätze mithilfe von Strukturiertem Ausgabe.
3. Überprüfen Sie den Payload mit Pydantic oder der bereits genutzten Schema-Schicht.
4. Lösen Sie Konflikte vor dem Einfügen, insbesondere dann, wenn der neue Datensatz den alten ersetzen soll.
5. Bewahren Sie einen Quellzeiger zum ursprünglichen Ereignis, Tool-Resultat, Datei, Ticket oder Benutzerbestätigung auf, aus denen der Datensatz entstanden ist.
6. Speichern Sie die Schema-Version zusammen mit jedem Datensatz – anstatt sie nur im Anwendungscode zu hinterlegen.

Der erste SGAM-Speicher kann eine relationale Tabelle mit einer JSON-Spalte sowie einigen Indizes sein. Ein Graph wird nützlich, wenn das Produkt Beziehungen wie Kunde zu Konto, Konto zu Policy, Aufgabe zu Artefakt oder Projekt zu Entscheidung durchlaufen muss.

Schneller Schreibpfad und Hintergrundschreibvorgänge

Eine sofortige Extraktion lohnt sich, wenn der nächste Schritt vom neuen Speicherinhalt abhängt. Wenn der Nutzer beispielsweise sagt: „Merken Sie sich, dass ich kurze Antworten bevorzuge“, sollte das System nicht auf einen täglichen Batch-Vorgang warten, um anders zu reagieren.

Die meisten Schritte erfordern keinen sofortigen Schreibvorgang. Speichern Sie zunächst das ursprüngliche Ereignis zusammen mit Tenant-, Sitzungs- und Tool-Metadaten, und lassen Sie anschließend einen Hintergrundprozess später potenzielle Datensätze extrahieren. Durch rekursionsbasierte Konsolidierung puffert der Prozess schwache Signale und führt eine Information erst dann ein, wenn ähnliche Hinweise wieder auftauchen oder der Nutzer dies bestätigt. Dadurch entsteht eine Verzögerung bei der Aktualität – was für Fälle wie „der Nutzer bittet häufig um CSV-Exporte“ akzeptabel ist, aber für Situationen wie „der Kunde hat die Lieferadresse geändert“ riskant ist.

Stellen Sie sicher, dass der Lesepfad deterministisch ist. Zuerst müssen Tenant-Bereich und Gültigkeitsfenster überprüft werden; erst danach darf fuzzy Retrieval eingesetzt werden, wenn es nützlichen Kontext liefern kann.

1. Filtern Sie nach Tenant, Speichertyp und Gültigkeitsfenster.
2. Holen Sie zunächst den exakten strukturierten Zustand ab, bevor semantische Nachbarn berücksichtigt werden.
3. Verwenden Sie Vektor- oder Graphenerweiterungen für unterstützende Belege, verwandte Entitäten und Beispiele – nicht jedoch als Autorität für aktuelle Fakten.
4. Zusammenstellen Sie den kleinstmöglichen zitierten Kontext, der die Frage beantworten kann.

Betrachten Sie Schema-Migrationen als Produktänderungen, da sie beeinflussen, was der Agent sich merken, zitieren oder löschen kann. Zudem können dadurch auch historische Fakten als aktuell gelten. Planen Sie Migrationsskripte, Rückfüllvorgänge, doppelte Lesefenster sowie Löschverhalten bereits im selben Release.

Wann SGAM die Komplexität lohnt

Verwenden Sie SGAM, wenn Fakten im Laufe der Zeit variieren können:

• Nutzerpräferenzen, die aktualisiert oder widerrufen werden können
• Kundendaten oder Kontoinformationen mit Prüfanforderungen
• Zustände von langlaufenden Assistenten
• Projektmerkmale von Coding-Agents
• Gemeinsamer Zustand mehrerer Agents
• Compliance-Hinweise, bei denen die Herkunft wichtig ist
• Zeitbezogene Fragen wie „Was glaubten wir vor der Migration?“

SGAM ist überdimensioniert, wenn die Speicherressourcen kurzlebig sind, die Daten exploratorisch genutzt werden oder deren Neuberechnung kostengünstig möglich ist. Reicht es dem Agenten aus, nur wenige Kontinuitätsschritte beizubehalten, genügen ein Checkpoint sowie eine gekürzte Nachrichtenhistorie. Bei statischer Dokumentqualitätsprüfung kann oft bereits RAG ausreichen. Falls das Anwendungsfeld so instabil ist, dass sich das Schema täglich ändert, verlangsamt eine typisierte Speicherlösung die Arbeit des Teams erheblich.

Bewertungscheckliste

Bewerten Sie sowohl den Lebenszyklus des Speichers als auch die finale Antwort. Ein System kann trotz falsch eingetragener Fakten, abgelaufener Abrufe oder Überschreitung von Nutzergrenzen eine plausibel klingende Antwort liefern.

Ich wende dieselbe schrittweise Aufteilung an wie in meinem Artikel zur RAG-Bewertung. Es wird der Schritt gemessen, an dem ein Fehler auftreten kann, anstatt die Bewertung ausschließlich auf den generierten Text zu beschränken. Die aus dem Artikel zur Agentenbewertung übernommene Trace-Methode ist ebenfalls relevant, da Speicherverfehlungen häufig bereits im Laufverlauf sichtbar werden, bevor sie die Antwort beeinflussen.

Ich würde SGAM unter Verwendung von Replay-Tests überprüfen. Dabei wird eine feste Abfolge von Episoden in den Speicherwriter eingegeben, nach jedem bedeutenden Schritt das Register überprüft und anschließend Fragen zum aktuellen Zustand sowie zu bestimmten Zeitpunkten anhand des entstandenen Speichers gestellt.

Benchmarks wie LoCoMo, LongMemEval und ATM-Bench stellen öffentliche Testfälle bereit. Sie ersetzen jedoch kein spezifisches Testumfeld für das jeweilige Anwendungsfeld. Ein Code-Assistent, ein Kundenservice-Bot oder ein Compliance-Copilot benötigen unterschiedliche Schemata, Filter, Retentionsregeln sowie Fehlerprüfungen.

Einschränkungen

SGAM ist meine Bezeichnung für ein bestimmtes Muster und kein offizieller Standard. Bestehende Projekte gehen bei der Modellierung des Problems unterschiedlich vor. LangGraph Memory sowie LangMem beschreiben Kurzzeit- und Langzeit-Speicherstrukturen, Profile, Sammlungen, Schreibvorgänge auf häufig genutzten Pfaden sowie Hintergrundprozesse zur Verwaltung von Speicherinhalten. Zep Graphiti verwendet den Begriff temporärer Kontextgraph. Letta ermöglicht das Persistieren editierbarer Speicherblokke, während Mem0 eine verwaltete Speicherschicht bereitstellt. Microsoft GraphRAG, die Property Graphs von LlamaIndex sowie Cognee betrachten jeweils Teile des Problems als Wissensgraphen.

Ein Benutzerprofil, ein Episodenprotokoll, ein Dokumentengraph sowie ein vom Agenten editierbarer Speicherblock lösen unterschiedliche Anforderungen hinsichtlich Abruf und Aktualisierung von Daten. Ich reserviere SGAM für dauerhafte Speicherstrukturen, die den aktuellen Zustand einer Anwendung darstellen und daher eine Struktur, Gültigkeitsprüfung, Herkunftsangabe, Konfliktverwaltung, Aufbewahrungsfristen sowie Migrationsmechanismen erfordern.

Auch strukturiert gespeicherter Speicher kann fehlerhaft sein. Eine Struktur erleichtert zwar die Überprüfung fehlerhafter Einträge, macht sie aber nicht automatisch zuverlässig. Es bleibt weiterhin eine Überprüfung der Quellen, die Bestätigung des Benutzers bei sensiblen Informationen, eine Konfliktstrategie, Löschfunktionen sowie Monitoring erforderlich.

Die Migration von Strukturen ist mit Aufwand verbunden. Sobald Speicherinhalte zum Zustandsbestandteil werden, sind Versionierung, Rückfüllvorgänge, alte Datensätze sowie das Löschverhalten selbst zu verwalten. Werden diese Schritte übersprungen, überdauern alte Datensätze oft die zugrunde liegenden Semantiken oder Aufbewahrungsrichtlinien.

Referenzen

• According to Me: Long-Term Personalized Referential Memory QA – Artikel von Mei et al., in dem ATM-Bench sowie Schema-Guided Memory vorgestellt werden.
• Towards Scalable Multi-Domain Conversational Agents: The Schema-Guided Dialogue Dataset – Artikel von Rastogi et al. zum SGD-Datensatz.
• LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory – Benchmark von Wu et al. zur Bewertung der Fähigkeiten von Chat-Assistenten im Umgang mit Langzeit-Speichern.
• Graphiti: Build Temporal Context Graphs for AI Agents
• Zep: A Temporal Knowledge Graph Architecture for Agent Memory
• Mem0 Platform Overview
• Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory
• LangGraph Memory Overview
• LangGraph Persistence
• LangMem documentation
• Letta: Introduction to Stateful Agents
• Microsoft GraphRAG documentation
• LlamaIndex: Using a Property Graph Index
• Cognee Documentation
• Pydantic model validation docs
• Python sqlite3 documentation