Mastras Observational Memory erzielt 84,23% auf dem LongMemEval-Benchmark mit gpt-4o. RAG-basiertes Memory kommt auf 80,05%. Die Differenz von über 4 Punkten klingt nach wenig, bedeutet aber in der Praxis: weniger verlorene Fakten, weniger Halluzinationen, weniger Nachfragen. Mit gpt-5-mini erreicht das System sogar 94,87%. Dabei braucht es keine Vektordatenbank und komprimiert den Gesprächsverlauf um den Faktor 5 bis 40.
Das Prinzip ist simpel: Statt die gesamte Nachrichtenhistorie zu speichern und per Embedding-Suche abzurufen, beobachtet ein Observer-Agent das Gespräch in Echtzeit und schreibt komprimierte Beobachtungsnotizen. Wenn sich diese Notizen ansammeln, räumt ein Reflector-Agent die veralteten auf. Das Ergebnis ist ein Memory-System, das wie ein aufmerksamer Protokollant arbeitet statt wie ein Tonband.
Warum RAG für Agent-Memory nicht reicht
RAG funktioniert gut für statische Wissensabfragen: Vektordatenbank durchsuchen, Top-k-Chunks holen, in den Prompt injizieren. Für langlebige Agent-Sitzungen hat RAG aber drei strukturelle Probleme, die Observational Memory löst.
Retrieval-Rauschen. Eine RAG-Pipeline, die über Gesprächsverläufe sucht, liefert Chunks nach Embedding-Ähnlichkeit, nicht nach Relevanz für die aktuelle Aufgabe. Wenn ein Nutzer über drei verschiedene Projekte in 50 Nachrichten diskutiert hat, kann die Suche Fragmente aus dem falschen Projekt zurückliefern. Mastras eigene Benchmarks auf LongMemEval bestätigen das: Ihre RAG-Implementierung erzielte 80,05% mit gpt-4o, Observational Memory erreichte 84,23% mit demselben Modell.
Token-Verschwendung. Jede RAG-Abfrage schiebt 1.500 bis 3.000 Token Kontext in den Prompt, unabhängig davon, ob der Agent alles davon braucht. Hochgerechnet auf mehrere Abfragen pro Runde sind das 10.000+ Token für Kontext, der möglicherweise gar nicht hilft. Observational Memorys 5-40x Kompression bedeutet: Dieselbe Information passt in einen Bruchteil der Token.
Kein Prompt-Caching. RAG-Ergebnisse ändern sich mit jeder Abfrage, also ändert sich auch der Prompt-Präfix. Das verhindert Prompt-Caching bei Anthropic und OpenAI. Observational Memory hängt Beobachtungen sequenziell an, sodass der Präfix über Runden stabil bleibt. Volle Cache-Treffer bei jedem Turn bis zum nächsten Beobachtungszyklus.
Das Mem0-Forschungsteam berichtete ähnliche Ergebnisse: Ihr Memory-Ansatz (der ebenfalls auf Kompression statt roher Abfrage setzt) erzielte eine 26%ige Genauigkeitssteigerung gegenüber Baseline-RAG bei Konversationsbenchmarks. Der Trend ist implementierungsübergreifend klar: Komprimiertes, strukturiertes Memory schlägt reines Retrieval für konversationelle Agenten.
So funktioniert die Observer-Reflector-Architektur
Observational Memory betreibt zwei Hintergrund-Agenten neben dem primären Agenten. Keiner von beiden verändert die Nutzerinteraktion. Sie arbeiten hinter den Kulissen und verwalten den Kontext.
Der Observer
Der Observer beobachtet das Gespräch zwischen Nutzer und primärem Agenten. Wenn die rohe Nachrichtenhistorie einen konfigurierbaren Schwellenwert überschreitet (Standard: 30.000 Token), aktiviert sich der Observer und komprimiert die Nachrichten zu Beobachtungsnotizen.
Diese Notizen sind keine Zusammenfassungen. Es sind strukturierte Beobachtungen mit Prioritäts-Tags:
- Rot (kritisch): Fakten, die der Agent behalten muss (Nutzerpräferenzen, Projektanforderungen, getroffene Entscheidungen)
- Gelb (relevant): Kontextinformationen, die später wichtig sein könnten (verwendete Tools, diskutierte Ansätze)
- Grün (informativ): Hintergrundinformationen (Zeitstempel, Session-Metadaten)
Der Observer verfolgt außerdem zwei spezielle Felder: die aktuelle Aufgabe, an der der Agent arbeitet, und eine vorgeschlagene Antwort zum Wiederaufnehmen der Arbeit. Das bedeutet: Bei einer Unterbrechung nimmt der Agent den Faden mit ein paar hundert Token Beobachtungen auf statt mit tausenden Token roher Historie.
Der Reflector
Wenn die Beobachtungen selbst ihren Schwellenwert überschreiten (Standard: 40.000 Token), tritt der Reflector in Aktion. Er entfernt veraltete Beobachtungen, führt verwandte zusammen und destilliert Muster heraus. Der Unterschied ist wie zwischen täglichen Notizen und einem Wochenbericht: Der Reflector verdichtet eine Woche an Beobachtungen zu einem kompakten Briefing.
Diese zweistufige Kompression ist der Grund, warum das System skaliert. Ohne Reflector würden Beobachtungen irgendwann so groß wie die ursprüngliche Konversation. Mit ihm bleiben selbst monatelange Agent-Sitzungen im Rahmen.
Architektur in der Praxis
Ein konkretes Beispiel: Ein Coding-Agent nutzt Playwright MCP zum Browsen und Interagieren mit Webseiten. Jeder Seiten-Snapshot kann 50.000+ Token umfassen. Ohne Observational Memory ist der Kontext des Agenten nach zwei bis drei Seiten voll. Mit dem System komprimiert der Observer jeden Seitenbesuch auf ein paar hundert Token: “Nutzer hat das Stripe-Dashboard besucht. Drei fehlgeschlagene Zahlungen der letzten 24 Stunden gefunden. CSV der fehlgeschlagenen Buchungen exportiert.”
Der rohe Seiteninhalt ist weg. Was bleibt, ist genau das, was der Agent zum Weiterarbeiten braucht.
import { Memory } from '@mastra/memory';
const memory = new Memory({
options: {
observationalMemory: {
model: 'google/gemini-2.5-flash',
observation: { messageTokens: 30_000 },
reflection: { observationTokens: 40_000 },
},
},
});
Die Konfiguration ist minimal. Das Modell für Observer und Reflector kann kleiner und günstiger sein als der primäre Agent. Mastra empfiehlt Gemini 2.5 Flash wegen seines 1M-Token-Kontextfensters, das dem Reflector genug Platz bietet, um große Beobachtungshistorien in einem Durchgang zu verarbeiten.
Benchmark-Ergebnisse: Wo Observational Memory gewinnt
Der LongMemEval-Benchmark testet, wie gut Memory-Systeme Informationen über lange Gespräche hinweg behalten und abrufen. Gemessen wird die Genauigkeit bei Fragen, die das Modell erfordern, spezifische Details aus früheren Dialogrunden abzurufen.
| Modell | Observational Memory | RAG | Differenz |
|---|---|---|---|
| gpt-5-mini | 94,87% | N/A | SOTA (3+ Punkte über jedem vorherigen Ergebnis) |
| gemini-3-pro-preview | 93,27% | N/A | Zweithöchstes je gemessenes Ergebnis |
| gemini-3-flash-preview | 89,20% | N/A | Dritthöchstes je gemessenes Ergebnis |
| gpt-4o | 84,23% | 80,05% | +4,18 Punkte |
Der gpt-4o-Vergleich ist am aussagekräftigsten, weil er die Modellqualität konstant hält. Gleiches Modell, gleicher Benchmark, andere Memory-Architektur. Observational Memorys 4-Punkte-Vorsprung kommt ausschließlich durch besseres Kontextmanagement.
Das gpt-5-mini-Ergebnis (94,87%) ist aus einem anderen Grund bemerkenswert: Es deutet darauf hin, dass Observational Memorys Kompression kleineren Modellen hilft, besser zu performen, indem Kontextrauschen reduziert wird. Ein kleineres Modell mit sauberem, komprimiertem Kontext übertrifft ein größeres Modell mit verrauschtem Rohkontext.
Kostenimplikationen
Die Token-Einsparungen schlagen direkt auf die API-Kosten durch. Mem0s Forschung hat das für ihren Memory-Ansatz quantifiziert: rund 1.800 Token pro Gesprächsrunde mit strukturiertem Memory gegenüber 26.000 Token bei Full-Context-Methoden. Das ist eine 93%ige Reduktion des Token-Verbrauchs.
Observational Memorys Kompressionsbereich von 5-40x hängt vom Gesprächstyp ab. Coding-Sitzungen mit großen Tool-Outputs komprimieren am oberen Ende (30-40x). Textlastige Gespräche mit kürzeren Nachrichten komprimieren weniger aggressiv (5-10x). In jedem Fall ist die Kostenreduktion erheblich: Ein Team, das 10.000 Euro pro Monat für Inferenz bei langlebigen Agent-Sitzungen ausgibt, könnte das realistisch auf 1.000 bis 2.000 Euro senken.
Prompt-Caching verstärkt die Einsparungen weiter. Bei konsistenten Beobachtungs-Präfixen gibt Anthropics Prompt-Caching 90% Kostenreduktion auf gecachte Token. OpenAIs Äquivalent bietet 50%. Kombiniert man Memory-Kompression mit Prompt-Caching, kann die Gesamtkostenreduktion 95% gegenüber naiven Full-Context-Ansätzen übersteigen.
Wie sich Observational Memory in die Agent-Memory-Landschaft einordnet
Observational Memory ist nicht der einzige strukturierte Memory-Ansatz, der an Zugkraft gewinnt. Das breitere KI-Agent-Memory-Ökosystem konvergiert auf eine zentrale Erkenntnis: Rohes Retrieval verliert gegen strukturierte Kompression.
Mem0 nutzt eine hybride Architektur aus Graph-, Vektor- und Key-Value-Stores. Ihr Graph-Memory erzielt eine 26%ige Genauigkeitsverbesserung gegenüber der Baseline bei Konversationsbenchmarks und bietet verwaltete Infrastruktur für Teams, die keine eigene Graph-Datenbank betreiben wollen.
Zep baut temporale Wissensgraphen, die verfolgen, wie sich Fakten über die Zeit verändern. Ihr Ansatz liefert 18,5% Genauigkeitsverbesserung bei 90% Latenzreduktion gegenüber Baseline-RAG und eignet sich besonders für Enterprise-Szenarien, die Audit-Trails und Beziehungsmodellierung erfordern.
Letta (ehemals MemGPT) verfolgt den radikalsten Ansatz: Agenten, die ihren eigenen Speicher durch selbstbearbeitende Memory-Blöcke verwalten. Letta-Agenten entscheiden selbst, was im Kontext bleibt, was archiviert und was abgerufen wird.
Observational Memorys Differenzierungsmerkmal ist seine Einfachheit. Keine Vektordatenbank, keine Graph-Datenbank, keine selbstbearbeitenden Memory-Schleifen. Nur zwei Hintergrund-Agenten, die Text komprimieren. Das macht es zum einfachsten Ansatz für Teams, die besseres Memory ohne signifikante Infrastrukturinvestitionen wollen.
Wann was verwenden?
| Memory-Typ | Am besten für | Infrastruktur | Komplexität |
|---|---|---|---|
| Observational Memory | Langlebige Sitzungen, Coding-Agenten, kontextintensive Workflows | Keine (nur Text) | Niedrig |
| RAG | Statische Wissensabfrage, Dokument-QA | Vektordatenbank | Mittel |
| Graph Memory (Mem0/Zep) | Beziehungsverfolgung, temporale Reasoning, Enterprise-Compliance | Graph-Datenbank | Hoch |
| Self-Editing (Letta) | Voll autonome Agenten mit eigener Kontextverwaltung | Agent-Runtime | Hoch |
Für die meisten Teams, die heute Agenten bauen, bietet Observational Memory das beste Verhältnis von Verbesserung zu Komplexität. Man fügt ein paar Zeilen Konfiguration hinzu, und die Agenten bewältigen sofort längere Sitzungen mit niedrigeren Kosten und höherer Genauigkeit. Für Unternehmen im DACH-Raum kommt ein weiterer Vorteil hinzu: Weniger gespeicherte Rohdaten bedeuten auch weniger DSGVO-relevante Datenverarbeitung bei Agent-Memory-Systemen.
Praktischer Einstieg: Integration in eigene Systeme
Wer mit Mastra baut, aktiviert Observational Memory per Konfigurationsflag. Wer ein anderes Framework nutzt, kann das Muster direkt implementieren.
Mit Mastra (TypeScript)
import { Mastra } from '@mastra/core';
import { Memory } from '@mastra/memory';
const memory = new Memory({
options: {
observationalMemory: true, // Nutzt standardmäßig gemini-2.5-flash
},
});
const mastra = new Mastra({
memory,
agents: { myAgent },
});
Zwei Speicher-Adapter funktionieren sofort: PostgreSQL (@mastra/pg) und LibSQL (@mastra/libsql). MongoDB-Support ist über @mastra/mongodb verfügbar.
Ohne Mastra (beliebiges Framework)
Das Observer-Reflector-Muster lässt sich in jedes Agent-Framework portieren. Die Kernlogik:
- Laufende Token-Zählung der Nachrichtenhistorie führen
- Bei Überschreitung des Schwellenwerts (30K Token funktioniert gut) ein kleineres Modell mit Anweisungen zur Kompression der Nachrichten in strukturierte Beobachtungen aufrufen
- Die Rohnachrichten im Kontext des Agenten durch die komprimierten Beobachtungen ersetzen
- Wenn die Beobachtungen selbst einen zweiten Schwellenwert (40K Token) überschreiten, das Modell erneut zur Konsolidierung aufrufen
Das entscheidende Implementierungsdetail ist das Prioritäts-Tagging. Ohne Priorisierung behandelt der Observer alle Informationen gleich und die Kompressionsqualität sinkt. Die Zuweisung von Rot/Gelb/Grün-Prioritäten ermöglicht dem Reflector intelligente Entscheidungen darüber, was behalten und was verworfen wird.
Häufig gestellte Fragen
Was ist Observational Memory für KI-Agenten?
Observational Memory ist eine Memory-Architektur für KI-Agenten, die zwei Hintergrund-Agenten nutzt: einen Observer und einen Reflector. Statt vollständige Nachrichtenverläufe per Vektorsuche zu speichern und abzurufen (wie bei RAG), erstellt das System komprimierte, priorisierte Beobachtungsnotizen. Das reduziert den Token-Verbrauch um den Faktor 5 bis 40 bei gleichzeitig höherer Genauigkeit auf Memory-Benchmarks. Mastras Implementierung erzielt State-of-the-Art-Ergebnisse auf LongMemEval.
Wie schneidet Observational Memory im Vergleich zu RAG ab?
Auf dem LongMemEval-Benchmark mit gpt-4o erzielt Observational Memory 84,23% gegenüber 80,05% bei RAG, eine Verbesserung von über 4 Punkten. Zusätzlich komprimiert es den Kontext 5-40x, ermöglicht Prompt-Caching durch stabile Präfixe und benötigt keine Vektordatenbank-Infrastruktur.
Wie viel spart Observational Memory bei KI-Agent-Kosten?
Observational Memory reduziert den Token-Verbrauch um den Faktor 5 bis 40 je nach Gesprächstyp. In Kombination mit Prompt-Caching können die Gesamtkosteneinsparungen 90-95% gegenüber Full-Context- oder naiven RAG-Ansätzen übersteigen. Mem0s Forschung bestätigte ähnliche Ergebnisse: rund 1.800 Token pro Runde mit strukturiertem Memory gegenüber 26.000 bei Full-Context-Methoden.
Was ist das Observer-Reflector-Architekturmuster?
Das Observer-Reflector-Muster nutzt zwei Hintergrund-Agenten. Der Observer beobachtet Gespräche und erstellt komprimierte Beobachtungsnotizen, wenn die Nachrichtenhistorie einen Token-Schwellenwert überschreitet (typisch 30.000 Token). Der Reflector aktiviert sich, wenn die Beobachtungen ihren eigenen Schwellenwert überschreiten (typisch 40.000 Token) und bereinigt veraltete Beobachtungen, während er verwandte zusammenführt.
Welchen KI-Agent-Memory-Ansatz sollte ich 2026 verwenden?
Verwenden Sie Observational Memory für langlebige Sitzungen, Coding-Agenten und kontextintensive Workflows, bei denen Einfachheit zählt. RAG für statische Wissensabfrage und Dokument-QA. Graph Memory (Mem0 oder Zep) bei Bedarf an Beziehungsverfolgung, temporalem Reasoning oder Enterprise-Compliance. Self-Editing Memory (Letta) für voll autonome Agenten mit eigener Kontextverwaltung.