Für den lokalen und offenen Agentenspeicher ist der Abruf die Standardeinstellung: RAG-Pipelines, Agentensuche, Einbettungsspeicher und Diagrammdurchlauf sind das, was die meisten Builder zuerst erreichen. Eine [Umfrage aus dem Jahr 2026](https://arxiv.org/abs/2602.19320) kommt zu dem Schluss, dass das Speicherdesign und nicht die Modellfähigkeit jetzt der limitierende Faktor für langlebige Agenten ist.

Der Abruf eignet sich gut für Codierung und Erkundung, bricht jedoch ab, wenn Agenten den laufenden Status verwalten. Die großen Projekte ([Zep](https://www.getzep.com/), [Mem0](https://mem0.ai/), [Letta](https://www.letta.com/), [LangMem](https://langchain-ai.github.io/langmem/)) fügen Entitätsauflösung, Persistenz und Diagrammstruktur hinzu, aber die vollständige Konvergenz zu einem strukturierten Design stößt auf Hindernisse, die schwer nachzurüsten sind: Schema-First-Abfragen, deterministisch Identität, Nur-Append-Provenienz und Local-First-Kontrolle.

## Warum das Abrufen dominiert

Der Abruf passt zu dem Anwendungsfall, der Agenten bekannt gemacht hat: Codierung. Codebasen sind explorativ, Sie wissen oft nicht, wo sich die Dinge befinden, und Sie möchten wissen: „Wo gehen wir mit X um?“ anstatt „jede Funktion mit Herkunft auflisten“. Semantische Suche und Ad-hoc-Traversal sind hierfür gut geeignet.

Die meisten Menschen entwickeln ihre Vorstellungen über das Agentengedächtnis aus der Codierung, wo das Abrufen ausreicht. Das Problem besteht darin, das zu verallgemeinern. Für Betriebszustände wie Aufgaben, Kontakte, Transaktionen und Verpflichtungen benötigen Sie nächste Woche die gleiche Antwort, vollständige Sätze und Prüfprotokolle.

Auch die Retrieval-Funktion lässt sich günstig hinzufügen. Sie können Ihre Dokumente einbetten, einen Vektorspeicher einrichten und an einem Nachmittag über Arbeitsspeicher verfügen, ohne Schemaentwurf, ohne Entitätsauflösung und ohne Herkunftsverfolgung. Das ist ein echter Vorteil, nicht nur Trägheit.

## Wo der Abruf unterbrochen wird

Die Brüche treten auf, wenn Sie sich für die Wahrheit auf das Gedächtnis des Agenten verlassen.

**Inkonsistente Antworten.** Die Frage „Alle Aufgaben für Projekt X auflisten“ liefert an einem Tag sieben Ergebnisse und am nächsten vier. Der Abruf erfolgt jedes Mal neu. [Untersuchungen bestätigen](https://arxiv.org/abs/2512.12818), dass Agenten Informationen über Sitzungen hinweg zusammenführen und mit zunehmendem Gedächtnis zeitlich inkonsistente Antworten produzieren.

**Unvollständiger Rückruf.** RAG-Systeme mit einem Abrufrückruf unter 80 % zeigen [Halluzinationsraten von 34 %, verglichen mit 20 % für Systeme über 90 % Rückruf](https://www.ijmsrt.com/storages/download-paper/IJMSRT25SEP018). Beim einbettungsbasierten Abruf werden zeitliche und relationale Strukturen verworfen, und je mehr Entitäten Sie haben, desto schlechter wird der Abruf.

**Keine Herkunft.** Wenn Sie fragen: „Woher kommt diese Nummer?“ Durch den Abruf erhalten Sie eine abgeleitete Antwort aus den aufgetauchten Teilen. Es gibt keine Abstammung von der Antwort zurück zu den Quelldatensätzen.

**Nicht wiederherstellbare Schreibvorgänge.** Wenn ein Agent einen Kontakt überschreibt oder Aufgaben zusammenführt, geht der vorherige Status verloren. Es gibt keine Versionierung und kein Rollback.

**Werkzeugübergreifende Drift.** Eine in ChatGPT erstellte Aufgabe kann in Cursor nicht zuverlässig abgefragt werden. Der Speicher des Anbieters ist [unvorhersehbar inkonsistent](https://www.datastudios.org/post/can-chatgpt-remember- previous-conversations-memory-behavior-session-limits-and-persistence), und offene Abruf-Setups sind standardmäßig auch nicht werkzeugübergreifend.

## Was der strukturierte Zustand bietet

Unter strukturiertem Zustand versteht man einen Speicher mit typisierten Entitäten, stabilen IDs, Beziehungen und Zeitleisten. Dieselbe Abfrage gibt jedes Mal dasselbe Ergebnis zurück, und Sie erhalten Herkunft und Rollback.

| Brauchen | Strukturierter Shop | Abruf |
|------|----|-----------|
| Komplettset („alle Aufgaben in Projekt X“) | Ja, nach Schema und Beziehungen | Teilweise oder abgeleitet |
| Gleiche Antwort nächste Woche | Ja | Nein |
| Zur Quelle zurückverfolgen | Ja, Herkunftskette | Nein |
| Wiederherstellung nach fehlerhaftem Schreibvorgang | Ja, wenn nur Anhängen | Normalerweise nein |
| Werkzeugübergreifende Konsistenz | Ja, wenn plattformübergreifend | Nur wenn alle Tools dasselbe Backend verwenden |
| Entdecken Sie das Unbekannte | Möglich, aber nicht seine Stärke | Ja, hier zeichnet sich Retrieval aus |
| Einmalige Zusammenfassung | Overkill | Ja |

Ein strukturierter Speicher kann diagrammförmig sein, und der, den ich aufbaue, [Neotoma](https://neotoma.io), ist: eine lokale, MCP-kompatible Speicherschicht, die Agenten eine einzige Wahrheitsquelle für Entitäten, Beziehungen und Abstammung bietet. Was es von den beim Abrufen üblichen „Graph-Setups“ unterscheidet, sind Persistenz, kanonische IDs und Herkunft. Ich habe an anderer Stelle mehr darüber geschrieben, [warum der Agentenspeicher eine Wahrheitsschicht benötigt](/posts/truth-layer-agent-memory).

## Wohin sich das Feld bewegt

Die großen Projekte nähern sich auf der Rückgewinnungsseite dem strukturierten Zustand an.

**[Zep](https://www.getzep.com/)/[Graphiti](https://www.getzep.com/)** erstellt einen [zeitlichen Wissensgraphen](https://arxiv.org/abs/2501.13956), der eine Genauigkeitssteigerung von 18,5 % gegenüber MemGPT und eine Latenzreduzierung von 90 % erreicht und einen MCP-Server liefert. Es ist der strukturierteste Zustand im aktuellen Ökosystem.

**Mem0** verwendet eine [zweiphasige Extraktions- und Konsolidierungspipeline](https://mem0.ai/research), die eine 26 % höhere Genauigkeit als der Speicher von OpenAI meldet, mit einer Diagrammvariante für Entitätsbeziehungen. Es ist immer noch in erster Linie eine Retrieval-First-Methode und die strukturierte Schicht ist additiv.

**[Letta](https://www.letta.com/)** (früher [MemGPT](https://docs.letta.com/guides/legacy/memgpt-agents-legacy)) [behält alle Zustände in einer Datenbank bei](https://docs.letta.com/guides/agents/context-engineering) mit bearbeitbaren Speicherblöcken. Es ist der expliziteste „strukturierte Zustand“ der Retrieval-Origin-Projekte.

**[LangMem](https://langchain-ai.github.io/langmem/)/[LangGraph](https://langchain-ai.github.io/langgraph/)** bietet ein [persistentes Speicher-SDK](https://blog.langchain.com/langmem-sdk-launch/) mit semantischen, episodischen und prozeduralen Typen und Speicherkonsolidierung. Die Persistenzschicht ist real, aber das primäre Zugriffsmuster ist immer noch die eingebettete Suche.

**[Rückblick](https://arxiv.org/abs/2512.12818)** ([Forschung 2025](https://arxiv.org/abs/2512.12818)) organisiert den Speicher in vier logische Netzwerke und erreicht eine Genauigkeit von 83–91 % bei Langhorizont-Benchmarks. Es zeigt die Richtung: Strukturierter Speicher mit expliziten Entitätsnetzwerken übertrifft Flat Retrieval.

## Können Retrieval-Systeme vollständig konvergieren?

Manche Dinge passen auf natürliche Weise zusammen, andere lassen sich strukturell nur schwer nachrüsten.

**Was bereits konvergiert.** Entitätsextraktion und Graphstruktur sind in Zep und [Mem0g](https://mem0.ai/) real. Datenbankpersistenz ist in Letta und LangGraph real. Die zeitliche Verfolgung ist in Graphiti real. Diese schließen die Lücke.

**Ähnlichkeit zuerst versus Schema zuerst.** Das Standardzugriffsmuster von Retrieval ist „Ähnliche Dinge finden“. Der Standardwert eines strukturierten Speichers ist „Abfrage nach Typ, ID, Beziehung oder Zeit“. Um ein Abrufsystem schemaorientiert zu gestalten, müssen die API-Oberfläche und die Benutzererwartungen geändert werden, nicht nur das Hinzufügen einer Funktion.

**Implizite versus explizite Identität.** Der Abruf behandelt zwei Chunks als dieselbe Entität, wenn ihre Einbettungen nahe beieinander liegen. Der strukturierte Status behandelt zwei Datensätze als dieselbe Entität, wenn sie eine gemeinsame kanonische ID haben. Die Nachrüstung der deterministischen Identität bedeutet, jeden Aufnahmepfad zu ändern.

**Upsert versus Nur-Anhängen.** Abrufsysteme überschreiben normalerweise, während der Nur-Anhängen-Speicher den Verlauf beibehält. Letta verwendet veränderliche Speicherblöcke und Zep verfolgt die zeitliche Entwicklung, was näher ist. Die meisten Retrieval-Systeme haben kein Konzept zum Schreiben von Historien.

**Provenienz durch Konsolidierung.** Wenn Mem0 Fakten konsolidiert oder LangMem verwandte Erinnerungen zusammenführt, geht die Herkunft aus den Originalquellen normalerweise verloren. Eine Provenienz, die die Zusammenführung übersteht, erfordert, dass das Speichermodell sie von Anfang an unterstützt.

**Determinismus.** Der Abruf erfordert eine Rangfolge und die Ergebnisse variieren von Lauf zu Lauf. Strukturierte Abfragen sind deterministisch: Dieselbe Abfrage liefert dasselbe Ergebnis. Durch das Entfernen der Ranking-Funktion wird der Nutzen des Abrufs beeinträchtigt. Dabei handelt es sich um grundsätzlich unterschiedliche Abfrageverträge.

**Lokale Kontrolle.** Ein System wirklich lokal zu gestalten, ohne Cloud-Abhängigkeit und ohne Telemetrie, steht im Widerspruch zum Geschäftsmodell der meisten Speicherunternehmen. Dies ist kein technisches Hindernis; es handelt sich um ein strukturelles Anreizproblem.

Abrufsysteme können teilweise zu einem strukturierten Speicher gelangen, aber die letzte Meile erfordert Schema-First-Abfragen, deterministische Identität, Nur-Anhängen-Herkunft, deterministische Ergebnisse und Local-First-Standardwerte. Diese Entscheidungen widersprechen der Retrieval-First-Architektur.

## Was Retrieval noch besser macht

**Erkundung.** Wenn Sie in Ihren Notizen etwas über die Wohnung in Barcelona finden möchten, kennen Sie das Schema oder den Entitätstyp nicht. Abrufen relevanter Bits ohne vorherige Modellierung.

**Zusammenfassung.** Wenn Sie fragen, was Sie mit dem Auftragnehmer entschieden haben, kann Retrieval in einer Sitzung suchen, extrahieren und zusammenfassen. Diese Antwort muss beim nächsten Mal nicht bestehen bleiben oder genau übereinstimmen.

**Ad-hoc-Traversal.** Wenn Sie fragen, wo Stripe-Webhooks verarbeitet werden, variiert das Layout je nach Codebasis und Dokument. Der Abruf passt sich ohne ein einheitliches Diagramm an.

**Geringe Vorabkosten.** Sie können an einem Nachmittag über ein Arbeitsgedächtnis verfügen. Für alles, was keine Vollständigkeit, Konsistenz oder Herkunft erfordert, ist die Rückholung ausreichend und kostengünstiger.

## Lücken im strukturierten Zustand und wie Neotoma sie behebt

**Schema-Overhead.** Neotoma verwendet eine sich weiterentwickelnde Schema-Registrierung, in der die LLM-unterstützte Extraktion während der Aufnahme Typen und Beziehungen vorschlägt. Dies senkt die Vorabkosten, beseitigt sie jedoch nicht. In der Praxis überprüft und korrigiert der Agent die Extraktionsergebnisse im Laufe der Zeit, wenn er auf Inkonsistenzen stößt.

**Komplexität der Aufnahme.** Neotoma berechnet Hash-basierte kanonische IDs aus der Identifizierung von Eigenschaften, sodass dieselbe Entität unabhängig von der Quelle dieselbe ID erhält. Dies ist vorhersehbarer als einbettungsbasierte Ähnlichkeit, hängt jedoch von der Extraktionsqualität ab: „Mark“ und „Mark Hendrickson“ hashen unterschiedlich, bis Sie sie zusammenführen.

**Kaltstart.** Neotoma unterstützt die Aufnahme über zwei Pfade: Sie können Dateien zur Batch-Extraktion hochladen oder den Status durch Agentengespräche inkrementell sammeln. Das geht zwar nicht sofort, aber es geht schneller, als auf genügend Konversationen zu warten, um ein nützliches Diagramm zu erstellen.

**Nur Anhängekosten.** Der Speicherplatz wächst mit jeder Korrektur, was Rollback und Provenienz ermöglicht. Auf persönlicher und betrieblicher Ebene ist dies beherrschbar, stellt jedoch einen echten Kompromiss dar: Abfragen zur Lösung des aktuellen Status sind komplexer.

**Kein Ersatz für den Abruf.** Neotoma bietet strukturellen Abruf nach Typ, ID, Beziehung, Zeitbereich und Diagrammnachbarschaft und erwartet Abruftools wie Agentensuche und Einbettungssuche für die Erkundung. Es ist eine Ergänzung, kein Ersatz.

## Warum ich Neotoma baue

In der Praxis stoße ich an Abrufgrenzen. Aufgaben, Kontakte und Transaktionen benötigen kanonische IDs, Herkunft und werkzeugübergreifenden Zugriff. Die Designentscheidungen reagieren direkt auf die oben beschriebenen Konvergenzbarrieren.

**Schema-first.** Abfragen erfolgen nach Entitätstyp, ID, Beziehung oder Zeitbereich. Es gibt keine Einbettungsähnlichkeit im Abfragepfad und die Ergebnisse sind deterministisch.

**Hash-basierte Identität.** Dieselbe Entität erhält dieselbe ID, unabhängig davon, welche Quelle oder Sitzung sie eingeführt hat.

**Nur anhängen.** Jede Tatsache lässt sich auf ihre Quelle zurückführen. Durch Korrekturen werden neue Datensätze erstellt und ein Rollback ist möglich.

**Toolübergreifend über MCP.** Eine Speicherebene ist von jedem MCP-Client aus zugänglich: Cursor, ChatGPT, Claude oder Claude Code. Überall stehen die gleichen Daten und die gleichen IDs zur Verfügung.

**Lokal-zuerst.** Alle Daten befinden sich in SQLite und lokalen Dateien. Es gibt keine Cloud-Abhängigkeit und keine Telemetrie. Sie können alles überprüfen, was das System tut.

[Neotoma](https://neotoma.io) ist früh. Es handelt sich um eine [Entwicklerversion](/posts/neotoma-developer-release): nur lokal, CLI-first, mit heuristischer Entitätsauflösung, manueller Schemaentwicklung und ohne Web-Benutzeroberfläche. Was es bereitstellt, ist der Vertrag, und das Argument ist, dass dieser Vertrag für Agenten notwendig ist, die den laufenden Zustand verwalten, und dass der Abruf allein ihn nicht bereitstellen kann.

Das Gebiet konvergiert im Bereich des strukturierten Gedächtnisses. Die Frage ist, wer mit Ihren Daten die Schicht aufbaut, der Sie vertrauen, und welche Garantien sie bietet. Ich möchte, dass diese Ebene von Anfang an strukturiert ist und nicht nachträglich aufgeschraubt wird. Lokal zuerst, offen, einsehbar und unter der Kontrolle des Benutzers.