[Shubham Saboo](https://x.com/Saboo_Shubham_) (ein Google PM) [hat letzte Woche im Rahmen des GCP generative-ai Repos einen Always-On-Speicheragenten als Open-Source-Lösung bereitgestellt](https://github.com/GoogleCloudPlatform/generative-ai/tree/main/gemini/agents/always-on-memory-agent). [VentureBeat berichtete darüber](https://venturebeat.com/orchestration/google-pm-open-sources-always-on-memory-agent-ditching-vector-databases-for) als Signal dafür, wohin sich die Agenteninfrastruktur entwickelt. Es handelt sich um ein persistentes Speichersystem, das rund um die Uhr als Hintergrundprozess läuft, Dateien aufnimmt, nach einem Timer konsolidiert und Anfragen beantwortet. Keine Vektordatenbank. Keine Einbettungen. Nur ein LLM, das strukturierten Speicher liest, denkt und in SQLite schreibt.

Das Projekt bestätigt etwas, auf das ich mit [Neotoma](https://github.com/markmhendrickson/neotoma) hingearbeitet habe: Persistenter Speicher für Agenten ist ein realer und wachsender Bedarf. Die beiden Projekte treffen jedoch gegensätzliche architektonische Entscheidungen. Dieser Beitrag vergleicht sie.

## Was der Always-On-Speicheragent ist

Das Projekt ist eine Referenzimplementierung, die mit [Google ADK (Agent Development Kit)](https://google.github.io/adk-docs/) und [Gemini 3.1 Flash-Lite](https://ai.google.dev/gemini-api/docs/models) erstellt wurde. Es wird als einfacher Hintergrundprozess mit drei spezialisierten Subagenten ausgeführt: einem für die Aufnahme, einem für die Konsolidierung und einem für Abfragen.

1. **Aufnahme.** Ein Datei-Watcher überwacht ein Posteingangsverzeichnis. Geben Sie eine Datei ein und der Agent holt sie ab. Es akzeptiert auch Eingaben über HTTP POST. Es verarbeitet Text, Bilder, Audio, Video und PDF. Das LLM extrahiert Zusammenfassungen, Entitäten, Themen und Wichtigkeitswerte.

2. **Konsolidierung.** Der Konsolidierungsagent liest innerhalb eines Timers alle gespeicherten Erinnerungen, findet Verbindungen und Muster darin, komprimiert verwandte Elemente und schreibt neue synthetisierte Erkenntnisse. Dies läuft im Hintergrund ohne Aufforderung.

3. **Abfrage.** Sie stellen eine Frage. Der Abfrageagent liest relevante Erinnerungen und konsolidierte Erkenntnisse, synthetisiert eine Antwort und gibt sie mit Zitaten zu bestimmten Speicherdatensätzen zurück.

Der Speicher ist SQLite. Keine Vektordatenbank, kein Einbettungsindex. Die Architektur geht davon aus, dass ein LLM den Abruf direkt über strukturierte Textdatensätze durchführen kann, ohne dass eine Ähnlichkeitssuche erforderlich ist.

## Wo es sich auszeichnet

**Einfachheit.** Klonen Sie das Repo, legen Sie einen Gemini-API-Schlüssel fest und führen Sie es aus. Dateiüberwachung, HTTP-API und ein Streamlit-Dashboard. Minimale Abhängigkeiten und keine über den einzelnen Prozess hinaus zu verwaltende Infrastruktur. Für Entwickler, die den Agentenspeicher mit Gemini erkunden, ist dies der schnellste Weg zu einer funktionierenden Demo.

**Das Narrativ „keine Vektor-DB“.** Das Entfernen der Vektordatenbank reduziert die betriebliche und konzeptionelle Komplexität. Keine Einbettungsmodelle zur Auswahl, kein zu verwaltender Index, keine Abrufoptimierung. Für kleine Einsätze ist dies eine echte Vereinfachung.

**Aktive Konsolidierung.** Die zeitgesteuerte Konsolidierung ist der markanteste Teil. Die meisten Gedächtnissysteme sind passiv: Dinge speichern, Dinge abrufen. Dieser verbindet, komprimiert und synthetisiert aktiv. Es findet Muster, nach denen Sie nicht gefragt haben. Das kommt bei jedem gut an, der sich eine „Erinnerung, die denkt“ und nicht eine Erinnerung, die wartet, wünscht.

## Wo die Ansätze auseinander gehen

Der Always-On-Memory-Agent und Neotoma haben ein gemeinsames Ziel (persistenter Agent-Speicher), weichen jedoch bei fast jeder Designentscheidung voneinander ab. Die Abweichungen sind kein Zufall. Sie spiegeln unterschiedliche Ausgangsprämissen darüber wider, wofür der Speicher optimiert werden sollte.

### Automatische vs. explizite Aufnahme

Der Dateiwächter ist automatisch. Alles, was im Posteingang landet, wird verarbeitet. Es gibt keinen Genehmigungsschritt, keine Schema-First-Validierung und keine Benutzerbestätigung, bevor das LLM extrahiert und speichert. Neotoma verfolgt den umgekehrten Ansatz: Nichts gelangt in das System, es sei denn, ein Agent oder Benutzer schreibt es explizit über MCP. Für persönliche Notizen ist die automatische Aufnahme praktisch. Für alles mit Datenschutz- oder Compliance-Anforderungen ist die explizite Kontrolle die sicherere Standardeinstellung.

### Wer entscheidet, woran man sich erinnert?

Neotoma verlässt sich darauf, dass der Client-Agent den Speicherspeicher aufruft. Der Agent, mit dem Sie sprechen (ChatGPT, Claude, Cursor), entscheidet, woran Sie sich erinnern sollten und wie er es strukturiert. Wenn es zu dem Schluss kommt, dass ein Fakt, ein Kontakt oder eine Aufgabe bestehen bleiben sollte, ruft es den Speichervorgang über MCP auf. Die Verantwortung dafür, woran Sie sich erinnern sollten, verbleibt auf der Agentenebene, im selben Prozess wie Ihr Gespräch.

Der Always-On Memory Agent teilt diese Verantwortung auf spezialisierte Subagenten auf. Der Aufnahmeagent entscheidet, was aus den Dateien extrahiert werden soll. Der Konsolidierungsagent entscheidet, was zusammengeführt und welche Verbindungen gezogen werden sollen. Der Abfrageagent entscheidet, was zurückgegeben werden soll. „Was es wert ist, sich zu erinnern“ und „Wie“ werden auf diese Subagenten verteilt, die unabhängig von der Konversation laufen. Der Benutzer genehmigt nicht jede Entscheidung. Die Subagenten erstellen sie im Hintergrund.

### LLM-gesteuerte vs. deterministische Extraktion

Der Always-On Memory Agent nutzt das LLM für alles: Entitäten extrahieren, Wichtigkeit zuweisen, Zusammenfassungen erstellen. Führen Sie dieselbe Extraktion zweimal für dieselbe Datei aus. Die Ergebnisse können unterschiedlich sein. Neotoma verwendet [schema-first deterministische Extraktion](/posts/truth-layer-agent-memory). Dieselbe Eingabe erzeugt dieselben Entitäten, dieselben kanonischen IDs und dieselben Beziehungen. Die optionale LLM-Interpretation läuft auf dieser deterministischen Ebene und nicht an deren Stelle.

### Konsolidierung vs. unveränderliche Wahrheit

Der Konsolidierungsagent entscheidet, was zusammengeführt, welche Verbindungen gezeichnet und was komprimiert werden soll. Es verändert das Gedächtnis im Laufe der Zeit. Alte Erinnerungen werden in neue synthetisierte Erkenntnisse aufgenommen. Neotoma konsolidiert sich nicht. Es hängt an. Jede Beobachtung ist unveränderlich. Die Geschichte basiert auf Ereignissen. Wenn Sie sehen möchten, was sich wann und warum geändert hat, finden Sie hier den vollständigen Weg. Es wird nichts überschrieben oder wegkomprimiert.

### Einzelplattform vs. plattformübergreifend

Das Projekt basiert auf Gemini und Google ADK. Der Speicher befindet sich in einer lokalen SQLite-Datei, auf die nur über diesen speziellen Agent-Stack zugegriffen werden kann. Neotoma stellt Speicher über MCP bereit, was bedeutet, dass auf dieselben Entitäten über ChatGPT, Claude, Cursor und jedes andere MCP-kompatible Tool zugegriffen werden kann. Eine Speicherschicht, mehrere Verbraucher.

### Keine Herkunft vs. vollständige Abstammung

Speicherdatensätze im Always-On-Speicheragenten enthalten Zusammenfassungen und extrahierte Entitäten, lassen sich jedoch nicht auf die spezifische Datei, Zeile oder Sitzung zurückführen, die sie erstellt hat. Wenn eine konsolidierte Erkenntnis falsch ist, gibt es keinen Prüfpfad, dem man folgen kann. In Neotoma geht jedes Feld auf jeder Entität auf eine Quellenbeobachtung zurück. Sie können jeden Sachverhalt bis zu seinem Ursprung überprüfen.

### Kompromisse skalieren

Ohne Einbettungen oder einen Vektorindex liest das System strukturierte Textdatensätze direkt über das LLM. Das funktioniert im Kleinen. Wenn der Speicher wächst, funktioniert dieser Ansatz möglicherweise nicht mehr. Durch das Entfernen der Vektor-DB wird das Abrufdesign nicht entfernt. Es verschiebt die Komplexität in das LLM-Kontextfenster. Neotoma verwendet strukturierte Abfragen über typisierte Entitäten, die unabhängig von LLM-Kontextbeschränkungen skaliert werden.

## Substrat vs. Agent

Die klarste Unterscheidung ist die Rolle. Der Always-On Memory Agent ist ein Agent. Es erfasst automatisch, konsolidiert nach einem Zeitplan und synthetisiert Antworten. Es verfügt über eine eigene Argumentationsschleife. Es entscheidet, was zusammengeführt, welche Verbindungen gezogen und wann komprimiert werden soll.

Neotoma ist kein Wirkstoff. Es ist ein Substrat. Es speichert typisierte Entitäten mit kanonischen IDs. Es bewahrt die Herkunft. Es beantwortet deterministische Anfragen. Es entscheidet nichts allein. Keine Hintergrundaufnahme. Keine automatische Konsolidierung. Keine zeitgesteuerte Verarbeitung. Agenten lesen daraus und schreiben über [MCP](/posts/agentic-search-and-the-truth-layer) darauf. Die Argumentation erfolgt auf der Agentenebene. Die Wahrheit lebt im Substrat.

Das ist wichtig, denn was passiert, wenn der Agent falsch liegt. Wenn die Konsolidierung des Always-On-Speicheragenten zu einer schlechten Erkenntnis führt, ist diese Erkenntnis nun Teil des Speichers. Es gibt keine separate Ebene zur Überprüfung. Der Agent ist die Wahrheit.

Mit einer Wahrheitsschicht darunter können Sie nachverfolgen, was der Agent gelesen hat, wann er es gelesen hat und was er zurückgeschrieben hat. Wenn die neue Erkenntnis falsch ist, können Sie zurückkehren. Die Ausgabe des Konsolidierungsagenten ist eine Beobachtung zusätzlich zum deterministischen Zustand und keine Mutation desselben.

| Dimension | Always-On-Speicheragent | Wahrheitsschicht (Neotoma) |
|-----------|---------|------------------------|
| Rolle | Agent mit Argumentationsschleife | Substrat ohne Agentenverhalten |
| Wer entscheidet, was gespeichert wird | Spezialisierte Unteragenten (Aufnahme, Konsolidierung) | Client-Agent (über MCP) |
| Einnahme | Automatisch (Dateiüberwachung, API) | Nur explizit (MCP, CLI, Upload) |
| Extraktion | LLM-gesteuert; probabilistisch | Schema-zuerst; deterministisch |
| Konsolidierung | Timerbasierte LLM-Konsolidierung | Keiner; unveränderliche Wahrheit, ereignisbasierte Aktualisierungen |
| Provenienz | Basic (Quelle/Zusammenfassung in Datensätzen) | Vollständige Abstammung; jedes Feld verweist auf die Quelle |
| Plattform | Nur Gemini/Google ADK | Plattformübergreifend über MCP (ChatGPT, Claude, Cursor) |
| Datenschutz | Nicht als datenschutzorientiert eingestuft | Benutzergesteuert; kein Providerzugriff |
| Rollback | NEIN; Gedächtnis wird durch Konsolidierung verändert | Ja; Nur anhängen, versioniert, rücksetzbar |
| Maßstabsgetreues Modell | LLM liest alle Datensätze; durch den Kontext begrenzt | Strukturierte Abfragen über typisierte Entitäten |

## Wie sie zusammenarbeiten könnten

Die beiden Ansätze schließen sich nicht gegenseitig aus. Ein Konsolidierungsagent und eine Wahrheitsschicht lösen unterschiedliche Probleme. Man findet Muster. Der andere bewahrt das Vertrauen. Die interessante Architektur vereint beides.

Die Skizze ist unkompliziert. Ein Konsolidierungsagent (wie der im Always-On Memory Agent) liest Entitäten aus einer Wahrheitsschicht über MCP. Es hat Zugriff auf den vollständig strukturierten Zustand: typisierte Entitäten, Beziehungen, Zeitleisten, Herkunft. Es führt seine Musterfindungsschleife über diesen Zustand durch und sucht nach Verbindungen, Lücken oder Erkenntnissen, nach denen der Benutzer nicht gefragt hat. Wenn etwas gefunden wird, schreibt es das Ergebnis als neue Beobachtung zurück in die Wahrheitsschicht und markiert es mit seinen Quellentitäten und seiner Begründung.

Die Wahrheitsschicht behandelt diese Erkenntnisse genauso wie jedes andere Schreiben. Es zeichnet es als Beobachtung mit vollständiger Provenienz auf: Welche Entitäten hat der Agent wann gelesen, was hat er daraus geschlossen? Die Erkenntnisse werden Teil des Entitätsdiagramms. Wenn die Erkenntnisse falsch sind, können Sie genau sehen, was der Agent verbraucht hat, die Argumentation verfolgen und die Beobachtung rückgängig machen, ohne dass dies Auswirkungen auf die zugrunde liegenden Entitäten hat, aus denen er gelesen hat.

Dies unterscheidet sich von der heutigen Konsolidierung im Always-On Memory Agent. Dort mutiert der Konsolidierungsagent den Speicher direkt. Alte Erinnerungen werden in neue synthetisierte Aufnahmen aufgenommen. Der vorherige Zustand ist verschwunden. Wenn die Synthese falsch war, gibt es keine separate Ebene zum Vergleich.

Mit einer Wahrheitsschicht darunter wird die Konsolidierung zu einem zerstörungsfreien Vorgang. Der Agent fügt dem deterministischen Zustand eine Interpretationsebene hinzu. Der Staat selbst bleibt unveränderlich. Sie profitieren von den Vorteilen der aktiven Mustererkennung (die Stärke des Always-On Memory Agent) mit den Vorteilen der Überprüfbarkeit und des Rollbacks (die Stärke der Wahrheitsschicht). Oben Intelligenz, unten Vertrauen.

## Was dies bestätigt

Der Always-On Memory Agent ist eine Referenzimplementierung, kein Produkt. Es bestätigt, dass der Bedarf an persistentem, dynamischem Agentenspeicher real ist. „[Vector DB plus RAG](/posts/why-agent-memory-needs-more-than-rag)“ ist nicht das einzige Abrufmodell. Die [strukturellen Trends, die dies vorantreiben](/posts/six-agentic-trends-betting-on) sind klar: Agenten werden zustandsbehaftet, Fehler werden bepreist und Plattformen bleiben undurchsichtig. Das Projekt signalisiert, dass sich die Branche in Richtung ständig verfügbarer Speichersysteme bewegt, die über das einfache Speichern und Abrufen hinausgehen.

Wobei sich die beiden Projekte einig sind: Passives Gedächtnis reicht nicht aus. Wo sie sich nicht einig sind: ob die Speicherschicht selbst schlussfolgern sollte oder ob die Schlussfolgerung in einer separaten Schicht über dem deterministischen Zustand erfolgen sollte. Das ist derzeit eine Kernfrage in der Agentenspeicherarchitektur. Der Markt wird wahrscheinlich beide Ansätze unterstützen. Ich erwarte, dass die Architektur auf Konvergenzagenten konvergiert, die denken und auf Wahrheitsebenen laufen, denen Sie vertrauen können.

## Was ich baue

Ich baue [Neotoma](https://github.com/markmhendrickson/neotoma) als Vertrauensschicht auf. Typisierte Entitäten, kanonische IDs, deterministische Zusammenführung, Herkunft, plattformübergreifender Zugriff über MCP. Ich verwende es täglich für ChatGPT, Claude und Cursor. Die [Entwicklerversion](/posts/neotoma-developer-release) ist ab sofort unter [neotoma.io](https://neotoma.io) verfügbar.

Die Stichprobe von Google zeigt, dass sich die Branche auf persistenten Agentenspeicher konvergiert. Die offene Frage ist nicht, ob sich Agenten erinnern werden, sondern wie. Fähigkeit oder Governance. Wirkstoff oder Substrat. Wahrscheinlichkeitskonsolidierung oder deterministische Wahrheit. Ich tippe auf Letzteres.