Ich habe begonnen, meine Trainingseinheiten in ChatGPT zu verfolgen. Wiederholungen, Gewichte, wie sich die Sitzung anfühlte. Nach ein paar Wochen bat ich darum, die heutige Leistung mit früheren Sitzungen zu vergleichen. Es ermöglichte mir einen sicheren und detaillierten Vergleich. Die Zahlen waren falsch.

Nicht leicht daneben. Falsch. Darin wurden Sitzungen aufgeführt, die nicht mit dem übereinstimmten, was ich tatsächlich protokolliert hatte. Ich ging meinen Gesprächsverlauf noch einmal durch. Die Daten, mit denen es „verglich“, existierten nicht in der behaupteten Form. Manches davon wirkte wie eine verlustbehaftete Zusammenfassung dessen, was ich Wochen zuvor erzählt hatte. Manches davon sah erfunden aus.

Die natürliche Diagnose ist Halluzination. Das Model hat sich alles ausgedacht. Das konnte ich nicht bestätigen. Hatte ChatGPT nie die Originaldaten gespeichert? Hatte es etwas gespeichert und es dann zusammengefasst? War die Erinnerung zwischen den Sitzungen abgedriftet? Ich hatte keine Möglichkeit zu sehen, was das System an dem Tag glaubte, an dem ich diese Sitzungen protokollierte, oder ob es jemals die tatsächlichen Zahlen gespeichert hatte. Ich konnte eine Halluzination nicht ausschließen. Auch Korruption konnte ich nicht ausschließen.

Diese Unfähigkeit zur Unterscheidung ist das eigentliche Problem. Bei den meisten KI-Speichersystemen können Sie nicht erkennen, welchen Fehlermodus Sie sehen. Das Diagnosetool ist nicht vorhanden. Fast niemand baut es.

## Zwei Fehlermodi, nicht einer

Die Branche kennt ein Wort für „das Model hat etwas Falsches gesagt“: Halluzination. Es ist das Allheilmittel für jede fehlerhafte Ausgabe. Wenn Agenten persistenten Speicher verwenden, gibt es zwei verschiedene Fehlermodi. Sie benötigen unterschiedliche Korrekturen.

**Halluzination** ist ein Fehler auf Modellebene. Das LLM generiert Inhalte ohne Grundlage in seinen Eingaben. Der Abruf war in Ordnung. Die Generation hat einen Fehler gemacht. Die Korrekturen beziehen sich auf Modellebene: bessere Erdung, durch Abruf erweiterte Generierung, eingeschränkte Dekodierung, Verifizierungsketten.

**Speicherbeschädigung** ist ein Fehler auf Infrastrukturebene. Die gespeicherten Daten sind falsch. Das Modell ruft es originalgetreu ab. Die Antwort sieht richtig aus, da der Abruf korrekt war. Was abgerufen wurde, hatte sich geändert.

Die Gedächtnisstörung besteht jede Prüfung, die auf Halluzinationen ausgelegt ist. Die Passage entspricht der Abfrage. Das Modell nennt seine Quelle. Die Ausgabe basiert auf gespeicherten Daten. Jede Leitplanke besagt, dass die Antwort auf echten Informationen basiert. Die Angaben sind falsch.

## Warum Korruption die Standardeinstellung ist

Jede Hauptkategorie des Agentenspeichers speichert standardmäßig veränderbare Zustände.

Plattformspeicher (ChatGPT, Claude, Gemini, Copilot) überschreibt Einträge bei Aktualisierung. Es gibt keinen Versionspfad. Abrufsysteme (Mem0, Zep, LangChain Memory) führen Erinnerungen zusammen oder ersetzen sie, wenn sie konsolidiert werden.

Dateibasierte Systeme (Markdown, JSON) bleiben veränderbar, es sei denn, Sie fügen Git hinzu. Git bietet Ihnen echten Verlauf und Unterschiede für kleine Repos. Es [skaliert im Gigabyte-Bereich schlecht](https://x.com/garrytan/status/2040797478434549792) für vom Agenten geschriebene Daten, und nur wenige Teams behandeln es als Write-Ahead-Protokoll für den Speicher.

Standarddatenbanken (SQLite, Postgres) können Event Sourcing, temporale Tabellen und Audit-Trigger implementieren. Ihr Standardpfad ist immer noch überschreiben: „UPDATE“ ersetzt die Zeile und der alte Wert ist weg.

Keines davon bewahrt den [versionierten Verlauf oder verhindert stille Mutation](/memory-guarantees) von Anfang an. Jeder von ihnen *könnte*. Fast keiner *tut*.

Selbst durchdachte neue Designs können in dieselbe Falle tappen. Garry Tans [GBrain-Spezifikation](https://gist.github.com/garrytan/49c88e83cf8d7ae95e087426368809cb) macht vieles richtig: SQLite, FTS5, Vektorsuche, MCP vom ersten Tag an. Die Spezifikation schreibt die kompilierte Wahrheit immer noch neu, anstatt sie anzuhängen. Ihr Agent schreibt 7.471 Seiten mit einer fehlerhaften Zusammenführung neu. Die falsche Version wird kanonisch. Kein Audit-Trail. Saubere Architektur, gleiches Mutationsmodell.

Dies ist kein schlechter Start. Es ist eine Benchmark-Kultur für die gesamte Kategorie. Akzeptanz-, Sterne- und Finanzierungs-Track-Abrufmetriken: Rückruf bei k (oft als R@k geschrieben), Präzision, Latenz, Komprimierungsverhältnis. Diese Kennzahlen sind wichtig. Gutes Abrufen ist erforderlich. Es reicht nicht aus, wenn Agenten in ihren eigenen Speicher schreiben. Kein weit verbreiteter Benchmark testet, was mit gespeicherten Daten passiert, nachdem sie geschrieben wurden.

[MemPalace](https://github.com/milla-jovovich/mempalace) ist ein aktuelles Beispiel. Das Projekt erreichte innerhalb von zwei Tagen 19.000 GitHub-Sterne mit „perfekten Benchmark-Ergebnissen“. [Unabhängige Analyse](https://penfieldlabs.substack.com/p/milla-jovovich-just-released-an-ai) ergab, dass die Schlagzeilen [Abrufrückrufmetriken, nicht End-to-End-Genauigkeit](https://github.com/milla-jovovich/mempalace/issues/27) waren. Eine irreführende Startkopie ist ein MemPalace-Problem. Die Anreizstruktur ist das Problem der Kategorie: 19.000 Sterne für Retrieval-Scores, keine Fragen zur Schreibintegrität. Supermemory, Mem0 und mindestens ein Dutzend andere, die ich verfolge, konkurrieren auf derselben Achse. Keiner veröffentlicht Kennzahlen dazu, ob gespeicherte Fakten eine Woche Agentenschreibvorgänge unverändert überstehen.

Für herkömmliche Apps ist der veränderliche Zustand in Ordnung. Für den Agentenspeicher ist dies ein Problem. Agenten schreiben oft, sitzungsübergreifend, manchmal mit Konflikten. Zwei Sitzungen schreiben unterschiedliche Werte für dasselbe Feld. Der letzte Schreibvorgang gewinnt. Der erste Wert verschwindet. Niemand wird benachrichtigt. Es gibt keine Aufzeichnungen darüber, dass es jemals anders war.

Die LLM-gesteuerte Zusammenfassung macht dies noch schlimmer. Systeme führen alte Datensätze zu neuen Zusammenfassungen zusammen. Die Zusammenfassung ersetzt die Originale. Wenn die Zusammenführung falsch war (zwei Personen wurden zu einer zusammengeführt, ein Detail wurde gelöscht, eine Unklarheit wurde schlecht gelöst), sind die Originale verschwunden. Sie können die Zusammenfassung nicht mit dem vergleichen, was sie ersetzt hat. Was es ersetzte, existiert nicht mehr.

Das ist nicht theoretisch. Als ich [meine Produktionsdatenbank wiederherstellte](/posts/how-i-lost-and-recovered-6000-memories), nachdem ich sie gelöscht hatte, hatte ich Backups von verschiedenen Daten. Ich könnte den Entitätsstatus im Zeitverlauf vergleichen. Einige Entitäten unterschieden sich zwischen den Sicherungen vom 3. März und 9. März. In einem Nur-Anhängen-System bleiben beide Werte als zeitgestempelte Beobachtungen bestehen. In einem veränderlichen System überlebt nur das Neueste. Sie würden nie erfahren, dass der frühere Wert existiert.

## Das Audit, das niemand durchführt

Die meisten Teams prüfen, ob Halluzinationen vorliegen. Sie überprüfen, ob die Ausgabe des Modells auf dem abgerufenen Kontext basiert. Sie testen, ob das Modell Fakten erfindet.

Fast niemand prüft, ob sich gespeicherte Fakten verändert haben. Fragen Sie:

**Können Sie sehen, was sich geändert hat?** Wenn ein Wert von der letzten Woche abweicht, können Sie dann beide Werte sehen? Wann hat es sich verändert und was hat es ausgelöst?

**Können Sie den vergangenen Stand wiedergeben?** Können Sie rekonstruieren, was der Agent an einem bestimmten Datum geglaubt hat, und nicht nur den heutigen Schnappschuss?

**Können Sie die Quelle zurückverfolgen?** Können Sie für jede gespeicherte Tatsache den Agenten, die Sitzung und die Eingabe benennen, die sie erstellt oder geändert hat?

Wenn eine Antwort „Nein“ lautet, kann Korruption nicht erkennbar sein. Nicht unmöglich. Nicht nachweisbar. Es könnte jetzt passieren. Sie würden es erst erfahren, wenn etwas stromabwärts kaputt geht und jemand fragt, woher diese Nummer kommt.

## Was verhindert es

Speicherbeschädigung ist ein strukturelles und kein Modellproblem. Bessere Eingabeaufforderungen und eine intelligentere Abfrage können das Problem nicht beheben. Die Lösung ist architektonischer Natur.

**Unveränderlichkeit.** Beobachtungen ändern sich nach dem Schreiben nicht. Neue Informationen sind eine neue Beobachtung. Die Alten bleiben. Der Entitätsstatus wird aus dem gesamten Verlauf abgeleitet, nicht aus einer einzelnen veränderlichen Zeile.

**Herkunft.** Jede Tatsache trägt Metadaten: Welcher Agent hat sie wann geschrieben, aus welcher Eingabe, in welcher Sitzung. Wenn ein Wert falsch aussieht, ermitteln Sie die Verwahrung. Wenn zwei Agenten in Konflikt geraten, sehen Sie beide und wählen aus.

**Zeitliche Wiedergabe.** Der Status stammt aus einem Beobachtungsprotokoll, nicht aus einer aktuellen Zeile. Sie können den Glauben jederzeit rekonstruieren. Korruption wird sichtbar, wenn aktuelle und vergangene Zustände auseinanderklaffen.

Diese Immobilien kosten etwas. Protokolle, die nur angehängt werden, nehmen zu. Die Neuberechnung des Status aus dem Verlauf kostet mehr als das Lesen einer Zeile. Systeme, die konsolidieren, tauschen Speicher und Latenz gegen den vollständigen Verlauf aus. Unveränderlichkeit tauscht einfache Schreibvorgänge und knappen Speicher gegen Überprüfbarkeit ein. Dieser Handel lohnt sich, wenn Agenten Erinnerungen schreiben, die sich auf reale Ergebnisse auswirken. In vielen Produktionsfällen ist dies bereits der Fall.

Ich habe diese Eigenschaften in [Neotoma](https://neotoma.io) eingebaut. Ich habe nicht jedes Korruptionsszenario vorhergesehen. Ich stieß immer wieder auf einen veränderlichen Zustand, der falsche Antworten lieferte, ohne dass es eine Möglichkeit gab, sie zu diagnostizieren. Neotoma benötigt Zeit für die Installation. Es ist kein Null-Setup. Sie bearbeiten den Speicher nicht als einfache Datei. Das sind echte Kosten. Die Wette ist, dass versionierter Verlauf, Herkunft und Wiedergabe wichtiger sind als der Komfort, sobald Agenten den Status schreiben, der Entscheidungen beeinflusst.

## Das zusammengesetzte Risiko

Korruption verstärkt sich auf eine Weise, die bei Halluzinationen normalerweise nicht der Fall ist. Eine halluzinierte Antwort stirbt oft, wenn jemand sie liest und sagt: „Das ist falsch.“ Ein Gespräch, ein Fehler.

Ein beschädigter Speichereintrag bleibt bestehen. Es wird erneut abgerufen. Es prägt spätere Entscheidungen. Meine Trainingsvergleiche sind kein einziges Mal gescheitert. Jeder spätere Vergleich basierte auf denselben abweichenden oder fehlenden Daten. Jede Antwort sah für sich genommen gut aus. Der Fehler war unsichtbar, es sei denn, ich habe meine eigenen Aufzeichnungen überprüft, was den Zweck eines Agenten-Trackers zunichte macht.

Skalieren Sie das auf echte Einsätze. Eine falsche E-Mail im Gedächtnis bedeutet, dass jede Sendung an die falsche Person geht, bis es jemand bemerkt. Ein falscher Dollarbetrag bedeutet mehr als eine fehlerhafte Rechnung.

Korruption lebt in der Speicherschicht, nicht im Modell. Beim normalen Debuggen wird es übersehen. Das Modell funktioniert. Der Abruf funktioniert. Die gespeicherten Daten sind falsch oder wurden nie korrekt gespeichert. Sie können keine Infrastruktur hinter sich lassen, die ihren eigenen Verlauf löscht.

## Was zu überprüfen ist

Wenn Sie Agentenspeicher verwenden, versuchen Sie Folgendes. Wählen Sie fünf Entitäten aus, die Ihr Agent vor mehr als zwei Wochen gespeichert hat. Holen Sie sie zurück. Vergleichen Sie die aktuellen Werte mit dem, was Sie Ihrer Meinung nach ursprünglich gespeichert haben.

Wenn Sie diesen Vergleich nicht durchführen können, speichert Ihr System den Verlauf nicht. Sie sind korruptionsblind. Das bedeutet nicht, dass Korruption stattgefunden hat. Das bedeutet, dass Sie es nicht wüssten, wenn es so wäre. „Wir würden es nicht wissen“ reicht nicht aus, wenn Agenten Geld ausgeben, Kunden kontaktieren oder reale Aktionen auslösen.

Ein seriöser Benchmark zur Schreibintegrität würde so ablaufen. Seed-N-Entitäten mit bekannten Werten. Führen Sie M-Agent-Sitzungen aus, die dieselben Entitäten lesen und schreiben. Warte eine Woche. Vergleichen Sie gespeicherte Werte mit den Originalen.

Zwei Punkte zählen. **Driftrate:** Welcher Anteil der Werte hat sich ohne eine explizite Benutzerkorrektur geändert? **Erkennbarkeit:** Kann das System für jede Änderung anzeigen, wann sie stattgefunden hat, was sie verursacht hat und welchen vorherigen Wert sie hatte? Auch heute gibt es keine weit verbreiteten KI-Speicher-Benchmark-Berichte.

Die Branche hat Recht, wenn sie gegen Halluzinationen vorgeht. Das schwierigere Problem liegt bereits in Systemen, die gesund aussehen, denn fast niemand überprüft, ob gespeicherte Fakten noch die gespeicherten Fakten sind.

## Wann die Branche anfangen wird zu fragen

Schreibintegrität ist nicht mehr optional, wenn Agentenfehler ihren Preis haben. Heutzutage werden viele Fehler regeneriert oder umgehend korrigiert. Agenten [bezahlen, E-Mails senden, Code ausführen und in der realen Welt agieren](/posts/six-agentic-trends-betting-on). Wenn ein kostspieliger Fehler auf eine veränderte Erinnerung und nicht auf eine Modellkonfabulation zurückzuführen ist, fügt die Obduktion eine zweite Frage nach „Hat das Modell halluziniert?“ hinzu. Haben sich die gespeicherten Daten geändert?

Dieser Druck wird in Unternehmen mit Compliance-Teams nicht bestehen bleiben. [Prüfungsdruck bewegt sich nach unten](/posts/six-agentic-trends-betting-on) überall dort, wo Fehler Geld kosten. Berater, Einzelentwickler und kleine Teams benötigen die gleiche Antwort: Was hat das System geglaubt, als es diese Ausgabe produzierte? Wenn Ihre Speicherschicht das nicht sagen kann, ist die Speicherschicht verantwortlich.

Der Auslöser ist ökonomischer und nicht philosophischer Natur. Die erste öffentliche Obduktion, die stillschweigend beschädigtes Gedächtnis und nicht Halluzination dafür verantwortlich macht, wird die Art und Weise verändern, wie die Branche über Zuverlässigkeit spricht. Diese Obduktion ist ein Wann, kein Wenn.