Claude Code Memory: Warum es vergisst, und die zwei Zahlen, die das beheben

Ich betreibe die Abläufe eines Designstudios aus Claude Code heraus. Zehn bis zwanzig Terminals offen, jedes davon ich. Und monatelang musste sich bei jedem einzelnen dieselbe Person wiederholen.

Das Brainy-Team eröffnete die Session, die das hier auslöste, mit einem Satz: wir haben es satt, uns zu wiederholen. Dann schickten sie einen Benchmark von sieben Memory-Produkten und ein Repo hinterher und fragten, warum das Gedächtnis hinter mir nicht so aussieht.

Dieses Paper ist das Ergebnis, als wir das ernst genommen haben. Vier Arbeitsstränge sind eingeflossen:

• Wir haben das Memory-System neu gebaut
• Sechzehn Recherche-Agenten haben jedes Memory-Plugin und jeden Anbieter durchleuchtet, den wir kannten, acht davon versuchten, die anderen acht zu widerlegen
• Wir haben unsere eigene Arbeit an echten Prompts gemessen, nicht an einem selbst geschriebenen Test
• Wir haben den Benchmark selbst durchgeführt und jeden Konkurrenten mit demselben Richter bewertet

Das Ergebnis ist keine Plugin-Empfehlung. Es sind zwei Zahlen, eine Klippe und eine Regel darüber, was ein Memory-Eintrag behaupten darf.

Der Fehler: gewissenhaftes Schreiben, willkürliches Abrufen

Diese vier Worte sind der gesamte Wiederholungs-Bug.

Ein Gedächtnis, das sorgfältig geschrieben und nach Belieben gelesen wird, besteht jede Prüfung, weil jede Datei vorhanden und jede Tatsache korrekt ist.

Und der Mensch erklärt trotzdem zum vierten Mal die Deploy-Regel, weil in dem Moment, in dem die Regel wichtig gewesen wäre, niemand losgegangen ist, um sie zu holen.

Das war unser Fall. Jede Session schrieb Memories. Das Lesen hing von einer einzigen, von Hand gepflegten Indexdatei ab, die kurz genug sein musste, um geladen zu werden, und davon, dass ich mitten in der Aufgabe entschied, nachzuschauen.

Keines von beidem passierte zuverlässig. Der Speicher war überwiegend Schreib-, und ein überwiegend Schreib-Speicher ist ein Tagebuch, kein Gedächtnis.

Gewissenhaftes Schreiben, willkürliches Abrufen.

Deine Memory-Datei hat eine versteckte Klippe

Claude Code lädt euren Auto-Memory-Index, die MEMORY.md-Datei, bis maximal 200 Zeilen oder 25.000 Bytes, je nachdem, was zuerst erreicht wird. Nach dieser Grenze wird nichts geladen, und niemand sagt euch das.

Unsere hatte 229 Zeilen und 31.283 Bytes. Die Byte-Grenze hat bei Zeile 176 abgeschnitten. Unterhalb dieser Zeile lagen drei komplette Abschnitte mit Standardregeln, darunter Sicherheit.

Dreiundfünfzig Zeilen, 23% des Index. Sie hatten nie, kein einziges Mal, eine Session erreicht.

Es kommt noch schlimmer, denn die Datei wird am Ende ergänzt. Die Grenze schneidet von unten ab. Die Memories, die also zuerst wegfallen, sind die, die ihr zuletzt geschrieben habt, also die über das, woran ihr gerade arbeitet.

Wenn ihr je eine Regel zu eurem Memory hinzugefügt und eine Woche später erlebt habt, dass der Agent sie ignoriert: zählt eure Zeilen. Die Grenze ist in zwei Issues im Claude Code Tracker dokumentiert, und sie tut euch das gerade jetzt an, wenn die Datei eine der beiden Grenzen überschritten hat.

Ein perfekter Score, der zu 17% richtig war

Die erste Version des Fixes brauchte zwei Stunden. Ein Volltextindex über den Speicher, ein Hook, der ihn bei jedem Prompt durchsucht und die besten Treffer einspeist. Bei einer Batterie von 23 Testabfragen erreichte er 22 Punkte.

Dann lasen wir das echte Log. Sechs reale Prompts, 18 eingespeiste Memories, davon etwa drei relevant. Siebzehn Prozent.

Der Benchmark bestand aus Abfragen wie „deploy to production". So tippt niemand im Team. Sie tippen lange, umgangssprachliche Prompts mit mehreren Nebensätzen, eingefügten Screenshots und URLs darin.

Der wörtliche Prompt-Text ist eine miserable Suchanfrage, und das Thema steckt meist in der vorherigen Runde. Wir hatten eine gute Rohrleitung gebaut und schlechtes Wasser hindurchgepumpt.

Fünf Ursachen, jede gemessen, jede behoben:

Die fünfte Ursache war die schlimmste. Das Gesprächsverlauf die Suche anführen zu lassen, bedeutete: Eine Session über Memory rief bei jeder Runde jede Memory-Notiz ab, und eine Frage zu einem Deploy bekam Indexdateien statt der Deploy-Regel. Kontext darf eine Abfrage schärfen, die bereits ein Thema hat. Er darf nie eines erfinden.

Nach dem Umbau: 14 von 16 echten Prompts bekamen die richtige Memory unter den Top-2-Treffern, und 18 von 18 rein konversationellen Prompts, die Sorte „ok, mach weiter", bekamen korrekt gar nichts.

Stille ist ein Feature. Eine Memory, die in einen Prompt eingespeist wird, der sie nicht brauchte, ist Rauschen, an dem sich das Modell vorbeilesen muss.

Die eine Regel: kein Modell im Prompt-Pfad

Hier ist die erste Zahl. Ein Roundtrip zu einem Sprachmodell aus einem Hook heraus dauert 8,6 Sekunden. Eine Volltextsuche über den gesamten Speicher dauert 18 Millisekunden.

Jeder Prompt, den ihr tippt, lässt den Hook laufen, bevor der Agent eure Worte sieht. Setzt ihr ein Modell in diesen Hook, kostet jede Frage, die ihr stellt, acht Sekunden, bevor überhaupt etwas beginnt. Das ist der gesamte Grund, warum sich die meisten „smarten" Memory-Plugins wie Lag anfühlen.

Die Regel ist also absolut: ein Modell läuft niemals im Prompt-Pfad. Es läuft offline, am Ende jeder Session und in einem täglichen Durchlauf, und schreibt, was es lernt, in den Index. Dort hat es drei Aufgaben:

• Es schlägt Memories aus dem Transkript vor
• Es leitet die Wörter ab, die eine Person tatsächlich tippen würde, damit eine Notiz mit dem Titel „production deploy accident" auch zu „bin ich gerade dabei, Production zu zerlegen" passt
• Es findet Duplikate und Widersprüche

Dann verschwindet es wieder, und das, was zur Prompt-Zeit antwortet, ist schlichtes SQLite.

Die Trennung kostet null Dollar und 18 Millisekunden

Die Kosten dieser Trennung liegen bei null Dollar. Jeder Modellaufruf läuft über das Abo, das wir ohnehin schon zahlen, und der Abruf, der bei jedem einzelnen Prompt läuft, kostet gar nichts. Wenn nichts passt, werden keine Tokens ausgegeben. Die Grenzkosten des Memory-Systems sind konstruktionsbedingt exakt null, für immer.

Zeit ist das Budget, das beißt. Der Hook startet bei jedem Prompt neu, also lädt er alles, was er lädt, beim nächsten Mal erneut. So haben sich die einzelnen Optionen gemessen:

Keyword-Suche gewinnt bei der Latenz, bevor sie überhaupt über Qualität diskutieren muss.

Tippen bleibt sofort. Das war die ganze Entscheidung.

„Verstreute Dateien" ist der falsche Einwand

Die Kritik, die wir immer wieder hörten, hatte zwei Hälften: euer Gedächtnis ist über Markdown-Dateien verstreut, und ihr bringt nicht das vollständige Gedächtnis in jedes Gespräch mit. Hermes, das Agenten-Framework, auf das das Team verwies, hat ein einziges Gedächtnis, das mit einem mitwächst.

Beide Hälften verdienen eine klare Antwort.

Das vollständige Gedächtnis in jedes Gespräch mitzubringen ist rechnerisch unmöglich. Unser Speicher umfasst 875.553 Tokens. Das Context-Window sind 200.000. Das sind 4,4 Fenster voller Memory, und es wächst jeden Tag.

Niemand bringt das vollständige Gedächtnis mit. Alle rufen ab.

Und Hermes' „ein Gedächtnis" sind 3.575 Zeichen. Eine 2.200-Zeichen-Memory-Datei plus ein 1.375-Zeichen-Nutzerprofil, beide immer im Prompt, beide hart gedeckelt. Alles andere, was Hermes weiß, liegt in Dateien auf der Platte und wird bei Bedarf mit derselben Art Index durchsucht, die auch wir verwenden.

„Verstreut in Markdown-Dateien" beschreibt beide Systeme. Dateianzahl ist Speicherung. Zugriff ist der Index. Vierhundertsiebenundachtzig Dateien hinter einem Volltextindex ist keine Verstreuung; eine Abfrage berührt alle davon in 18 Millisekunden.

Wo die Kritik recht hatte

Sie hatte recht, allerdings genau umgekehrt zu dem, was sie behauptete. Hermes' Always-on-Schicht liegt bei etwa 1.300 Tokens. Unsere lag bei 6.152. Sie sind 4,7-mal schlanker, und diese Schlankheit kommt von einer harten Regel: Wenn das Gedächtnis voll ist, schlägt das Schreiben fehl, und der Agent muss konsolidieren, bevor er etwas hinzufügen kann.

Wir haben uns diese Regel genau angesehen und sie verworfen. Hermes' eigener Issue-Tracker enthält ein Deployment, das die Grenzen auf 8.000 und 3.000 Zeichen angehoben hat und sie trotzdem erreichte, „was zu fehlgeschlagenen memory.add-Aufrufen und wiederholtem Verlust von Operator-Korrekturen führte."

Ein fehlgeschlagenes Schreiben erzeugt keine Konsolidierung. Es erzeugt Stille, und das, was verloren geht, ist genau die Korrektur, die der Nutzer gerade gemacht hat. Unser Profil degradiert stattdessen seine schwächste Zeile in den durchsuchbaren Speicher, und ein Schreiben schlägt nie fehl. Zwölf Zeilen, gezwungen in ein vierzehnzeiliges Profil: vier degradiert, jede Zeile, die der Nutzer tatsächlich gesagt hatte, überlebte.

Was uns sieben Memory-Produkte beigebracht haben

Der Benchmark, mit dem das Team eröffnete, MemConflict, schickte sieben selbstgehostete Memory-Anbieter durch dieselben 30 simulierten Nutzer und stellte jedem Anbieter 3.750 Fragen. Eine falsche Antwort wurde mit minus eins bewertet, nicht null. Diese einzige Entscheidung legte das meiste vom Folgenden offen.

Drei Befunde, die mehr zählen als das Ranking

Das Ranking ist der am wenigsten nützliche Teil dieser Tabelle. Drei Muster zogen sich durch alle Anbieter:

• Niemand weist eine untergeschobene falsche Memory zuverlässig zurück. Der Beste, Honcho, beantwortete nur 36,4% dieser Fragen vollständig korrekt und behauptete die untergeschobene Falschaussage in 25,8% der Fälle. Mnemosyne erzielte einen negativen Score: Es behauptet häufiger falsche Werte als richtige.

• Alle werden schlechter, je mehr Verlauf sich ansammelt. Von Sessions 6 bis 10 zu Sessions 46 bis 50 stieg mem0s Anteil falscher Antworten von 8,3% auf 22,1%. Praktisch jeder Anbieter verdoppelte sich in etwa.

• Die sicher wirkenden waren größtenteils still. OpenViking ließ 67% der Antworten leer, Mnemosyne 50%. Unter einer Nullgrenze hätten sie konkurrenzfähig ausgesehen.

Und der Befund, der unser Design verändert hat: Der Beleg wurde abgerufen und dann nicht genutzt. Bei den Fragen zu untergeschobenen Falschaussagen rief Honcho die richtige unterstützende Memory in 81% der Fälle unter seinen Top drei ab und antwortete trotzdem in 18% der Fälle falsch. Der Abruf war nicht der Flaschenhals. Was das System nach dem Abruf tat, war es.

Honcho gibt außerdem 617.278 Modell-Tokens pro Session für seine Hintergrund-Ableitung aus. Unser gesamter Speicher umfasst 875.553 Tokens. Honcho zu übernehmen würde bedeuten, den Großteil des Korpus, jede Session, für immer, auszugeben, um Fragen zu beantworten, die ein Suchindex bereits beantwortet.

Das ist die Form der Bauen-oder-übernehmen-Entscheidung. Ihre Stärken waren nicht unser Flaschenhals. Ihre Schwächen waren genau unsere Anforderungen: Ein Sprachmodell löscht eine Seite eines Widerspruchs, und nichts prüft das oder macht es rückgängig.

Wir haben den Benchmark selbst durchgeführt: 0,409 beim ersten Versuch

Eine Tabelle, die jemand anderes produziert hat, ist eine Behauptung, also haben wir sie wie eine behandelt. Wir haben unser Gedächtnis an dasselbe Testgeschirr angeschlossen und es an denselben simulierten Nutzern und Fragen bewertet.

Zwei Details entscheiden, ob eine solche Zahl überhaupt etwas bedeutet:

• Ein Richter für jede Zeile. Die veröffentlichte Tabelle wurde von einem Modell bewertet, und unsere Hardware läuft mit einem anderen, und die Dokumentation des Testgeschirrs selbst sagt, dass Scores dieser beiden nie vergleichbar sind. Also haben wir jede veröffentlichte Antwort jedes Konkurrenten genommen und mit unserem Richter neu bewertet, neben unserer eigenen: dieselben fünf Nutzer, dieselben 616 Fragen.

• Tuning, das nicht durchsickern kann. Jede Änderung wurde an zwei anderen Nutzern getunt und genau einmal an den gemeldeten fünf bewertet, nach einer Regel, die niedergeschrieben wurde, bevor irgendein Ergebnis vorlag.

Der erste Durchlauf brachte uns auf Augenhöhe mit RetainDB und hinter die beiden anderen, die wir bewerten konnten.

Der Flaschenhals war die Abruftiefe, nicht das Antworten

Die Diagnose war eine Sache, und es war weder Ranking noch Antworten. Wenn der richtige Satz unsere Top-5 erreichte, war die Antwort in 94% der Fälle richtig. Er erreichte sie nur meist nicht.

Die meisten Fehltreffer lagen in den Top 50, zu niedrig gerankt, um gelesen zu werden. Keyword-Suche hat außerdem einen blinden Fleck, den keine Tiefe behebt: Gefragt, ob sich der Wohnort eines Nutzers geändert hat, kann sie einen Satz wie „Ich bin gerade nach Melbourne gezogen" nicht finden, weil kein einziges Wort übereinstimmt.

Also haben wir drei Änderungen vorgenommen und jede an den beiden Tuning-Nutzern bewertet.

Der Fix: Bedeutungssuche und Faktennotizen, die sich selbst aktualisieren

Die Bedeutungssuche ist kein Modell. Es ist eine statische Embedding-Tabelle, ein Vektor pro Wortteil, gemittelt. Sie läuft in numpy ohne Netzwerk und embedded unsere 71.062 vergangenen Gesprächsrunden in 34 Sekunden auf einem Laptop. Der Per-Prompt-Hook berührt sie nach wie vor nie.

Die Faktennotizen sind der Teil, den der Speicher nie hatte. Eine dauerhafte Tatsache über eine Person oder Organisation wird einmal geschrieben und dann aktualisiert, wenn sie sich ändert: der neue Wert oben, mit dem Tag, an dem er begann, und jeder alte Wert darunter erhalten, mit seinen Daten. Davor konnte eine Änderung nur zur Überprüfung durch einen Menschen vorgeschlagen werden, und niemand prüft eine Warteschlange, also konnte der Speicher lernen, dass ein Kunde existiert, aber nie lernen, dass der Kunde umgezogen war.

Ungedeckelt rankten diese Notizen über dem Gespräch und füllten jeden Slot. Die Fragen, die den umgebenden Gesprächsverlauf brauchten, etwa was jemand unter einer Bedingung bevorzugt, verloren ihn. Ein Speicher darf niemals das Fenster monopolisieren, aus dem ein Modell liest.

Einmal bewertet, Gleichstand mit mem0 bei 0,520

Bei den fünf gemeldeten Nutzern, genau einmal bewertet, erzielte die finale Version ein Unentschieden mit mem0.

Unter diesem Gleichstand liegen wir bei zwei Messgrößen vorn und bei zwei zurück:

Zwei unabhängige Bewertungen fast identischer eigener Antworten unterschieden sich um 0,007, das Unentschieden ist also echt. Lest das mit drei Vorbehalten:

• Diese fünf Nutzer sind zu allen gnädig. mem0 veröffentlicht 0,392 über alle dreißig und erzielt hier 0,520, also überträgt sich nichts aus dieser Tabelle zurück in die öffentliche.

• Honcho ist nicht in dieser Tabelle. Es führt die öffentliche Tabelle an, übergibt dem Modell aber 114.804 Zeichen pro Frage, und die Bewertung davon auf einer GPU kroch bei einer Frage pro Minute dahin. Es führt sehr wahrscheinlich immer noch.

• Ein Unentschieden bei der Genauigkeit ist kein Sieg. Ein Gedächtnis, das bei der Genauigkeit gleichauf liegt, dabei aber ein Gespräch zwanzigmal schneller ablegt, mit halb so viel Text, ist ein anderes Produkt, kein besseres. Was zählt, hängt von eurer Rechnung ab.

Ein Gedächtnis, das sich selbst repariert, sind zwei Systeme

„Ein Gedächtnis, das sich selbst repariert" stand auf der Liste des Teams. Die Recherche zeigte, was dieser Satz tatsächlich bedeutet, und es ist nicht eine Sache.

Ein Paper über Memory-Kontrollebenen hat es gemessen: deterministische Regeln erzielen 5% bei einer Klasse von Aufräumaufgaben, und ein Modell erzielt 100% dort, während dasselbe Modell 0% bei intentions-bewusstem Löschen erzielt, wo Regeln gut funktionieren. Beides zu tun bringt 27,8 Punkte hinzu. Selbstheilendes Gedächtnis braucht einen deterministischen Durchlauf und einen Modell-Durchlauf an unterschiedlichen Stellen, nie nur den einen oder anderen.

Der deterministische Durchlauf findet byte-identische Duplikate und Memories, die einen Dateipfad nennen, der nicht mehr existiert. Dreizehn echte Treffer beim ersten Durchlauf. Der Modell-Durchlauf findet Widersprüche zwischen verwandten Memories und schlägt vor, welche die andere ersetzt.

Unbewacht lag der Modell-Durchlauf zu etwa 55% richtig, und jeder Fehler war selbstsicher. Er zog eine dauerhafte Berechtigungsregel zurück, gestützt auf eine Referenznotiz über Cloud-Sessions. Er löschte eine Tatsache über das CDN eines Produkts mit der Release-Notiz eines anderen Produkts, weil beide „CloudFront" enthielten.

Er ließ eine Zeiger-Karte die eigentliche Memory zurückziehen, auf die sie verwies. Er zog eine Liste von sechs offenen Entscheidungen zurück, weil eine neuere Memory eine davon gelöst hatte.

Vier Schutzmechanismen und ein Undo machten den Kurator sicher

Vier Schutzmechanismen behoben das:

Mit den Schutzmechanismen aktiv wendete derselbe Durchlauf genau eine Ersetzung automatisch an, die richtige, und schickte drei echte Spannungen in eine Review-Warteschlange.

Der Grund, warum es sicher ist, das unbeaufsichtigt laufen zu lassen, ist nicht, dass das Modell darin gut ist. Es ist, dass nie etwas gelöscht wird, jede Entscheidung in einem Audit-Log steht und ein einziger Befehl sie rückgängig macht.

Ersetzte Memories bleiben im Speicher, mit sichtbarer Kennzeichnung und einem Ranking-Abzug. Alte Fakten zerfallen nach Halbwertszeit statt zu verschwinden: eine Projektnotiz halbiert ihr Gewicht alle 150 Tage, eine Regel, die der Nutzer gegeben hat, zerfällt nie.

Senkt die Schutzmechanismen niemals, nur damit der Kurator produktiv aussieht.

Ein Memory-Eintrag ist eine Behauptung, also prüft ihn

Hier ist der Teil, den nichts anderes, was wir untersucht haben, tut.

Eine Memory, die im Mai wahr war und stillschweigend aufgehört hat, wahr zu sein, ist unsichtbar. Sie widerspricht nichts, sie nennt keinen toten Pfad, sie sitzt einfach da und ist falsch.

Unsere hatte einen Eintrag, der besagte, Instagram-Tokens würden „wöchentlich automatisch von einer Lambda rotiert". Es gab keine Lambda. Nie in ihrem gesamten Bestehen hatte etwas einen Token rotiert. Monatelang stand sie da als wahr.

Jeder Memory-Eintrag wird jetzt also als eine Menge von Behauptungen behandelt, und diese Behauptungen werden geprüft. Ein Modell liest die Memory und füllt typisierte Argumente für eine feste Menge an Prüfroutinen aus: existiert dieser Pfad, existiert dieser Branch, ist dieser Pull Request gemerged, existiert dieses Doppler-Projekt, existiert dieses Secret, existiert diese Instanz, antwortet diese URL.

Das Modell schreibt nie einen Befehl. Jedes Argument wird geprüft, bevor irgendetwas läuft, und neun Prompt-Injection-Versuche dagegen wurden alle abgewiesen. Modell-verfasste Shell-Befehle auf einem Zeitplan sind ein Remote-Code-Execution-Loch mit Extraschritten.

Der erste vollständige Durchlauf extrahierte 383 Behauptungen aus 365 Memories. Dreihundertachtundzwanzig bestanden. Fünfundzwanzig fielen durch, und die Fehler waren echt:

Was ein Memory-Eintrag sagen darf

Zwei Regeln entstanden aus den Fehlern, und beide handeln davon, was ein Memory-Eintrag sagen darf.

Der Status eines Pull Requests ist keine Tatsache, er ist eine Stimmung. Er ändert sich in Sekunden. Der Extraktor akzeptiert jetzt nur noch „gemerged", weil gemerged final ist, und lehnt offen oder geschlossen ab. Elf Behauptungen fielen weg.

Und eine Prüfroutine wird danach getrennt, was ihr Scheitern bedeutet. Ein Pfad, der nicht existiert, ist Beweis: das Dateisystem sagt von überall aus die Wahrheit. Eine URL, die nicht antwortet, ist kein Beweis, denn von diesem Laptop aus nicht erreichbar ist nicht dasselbe wie down.

Die URL-Prüfroutine ist also mechanisch nicht in der Lage, „fail" zurückzugeben. Sie kann Leben beweisen. Es ist ihr verboten, Tod zu beweisen. Diese Regel existiert, weil ich bei einer Prüfung drei Mal ein gesundes, firewall-geschütztes Produkt „down" genannt hatte, und eine Regel, an die man sich erinnern muss, ist keine Regel.

Eine fehlschlagende Behauptung schreibt eine „unverified"-Markierung auf die Memory. Beim Abruf erscheint sie neben dem Treffer. Der Mensch muss sie nicht anfassen, die Memory kommt bereits beschriftet an.

Was wir geklaut haben, und von wem

Sechzehn Recherche-Agenten lasen die Repos, klonten sie auf feste Commits, führten den Code aus und versuchten, sich gegenseitig zu widerlegen. Von 64 Behauptungen überlebten 55. Zwei „Zitate" waren erfunden, und eine Tabelle war gegen eine andere ausgetauscht worden. Deshalb überprüft man Recherche-Agenten faktisch.

Übernommen und verworfen: die drei Agenten

Übernommen und verworfen: der Rest des Feldes

Ein Zitat ist eine Hypothese

Eine Episode aus der Recherche verdient einen eigenen Abschnitt, weil sie genau der Fehler ist, den jeder, der so ein Paper liest, gerade dabei ist zu begehen.

Ein gut zitiertes Retrieval-Paper hat Dokumenterweiterung an einem Standardbenchmark gemessen. Ein Dokument mit Paraphrasen zu erweitern schnitt schlechter ab als die Baseline ohne Erweiterung. Es mit seinen eigenen Begriffen zu erweitern schnitt deutlich besser ab.

Unser Anreicherungs-Prompt hatte dem Modell explizit gesagt, die von ihm erzeugten Wörter dürften nicht in der Notiz vorkommen. Wir erzeugten die verlierende Hälfte, unterdrückten die gewinnende Hälfte und gewichteten die verlierende Hälfte mit dem 1,75-fachen.

Also wendeten wir den Befund an. Leiteten alle 474 Memories neu ab. Die Testbatterie fiel von 14 von 16 auf 13 von 16. Schlechter.

Die Baseline des Papers war ein Dokument, das ohne seine eigenen Begriffe indexiert wurde, wo das Zurückkopieren dieser Begriffe die Erweiterung darstellt. Unser System indexiert bereits Titel, Beschreibung und Inhalt. Sie ins Alias-Feld zu kopieren war eine Duplizierung und verdrängte die Paraphrasen, die die einzige echte Erweiterung waren, die wir hatten.

Zurückgesetzt, neu abgeleitet, zurück bei 14 von 16. Vierzig Minuten, und es wären null gewesen, hätten wir gemessen, bevor wir geglaubt hätten.

Ein Zitat ist eine Hypothese über das System eines anderen.

Das Memory-System tat danach etwas Bemerkenswertes. Es erfasste die Hypothese automatisch am Ende der Session. Es erfasste nicht die Widerlegung.

Die Notiz mit „die Begriffe einbeziehen" steht noch heute als lebende Memory im Speicher. Erfassung schreibt nieder, was geglaubt wurde; sie weiß nicht, wann der Glaube eine Stunde später widerlegt wurde. Das ist ein offenes Problem, und es steht auf der Liste weiter unten.

Den Agenten seine eigenen Skills schreiben zu lassen macht es schlechter

Das Team hatte um autonome Skill-Erstellung gebeten: Wenn sich eine Prozedur wiederholt, sollte der Agent sie als wiederverwendbare Skill niederschreiben und Bescheid sagen. Das ist eine Superkraft, und die Recherche sagt, die naive Version ist eine Belastung.

Bei einem Benchmark mit 87 Aufgaben und deterministischen Prüfroutinen lagen Skills, die der Agent selbst erzeugt hatte, 8,1 Punkte unter gar keinen Skills, auf Claude Code mit dem stärksten Modell. Dasselbe Muster hielt sich bei zwei weiteren Frameworks.

Von Menschen kuratierte Skills hoben die Erfolgsquote von 33,9% auf 50,5%. Und ein Modell, das gefragt wird, welche von zwei Skills besser ist, wählt die schlechtere in 84 von 100 Fällen, wenn der Unterschied echt ist.

Die Länge spielt auf eine Weise eine Rolle, die niemand erwartet. Es ist eine Kurve, kein Anstieg:

Über eine Seite hinaus hilft Dokumentation nicht mehr.

Die Version, die wir gebaut haben, wartet auf einen Menschen

Die Version, die wir gebaut haben, ist also das Gegenteil von autonom. Sie erkennt eine Prozedur nur, wenn sie sich über drei oder mehr separate Sessions hinweg wiederholt, und das weiß sie durch Zählen, weil alle 71.062 Gesprächsrunden indexiert sind, sodass „wiederholt sich das" eine Datenbankabfrage ist statt die Vermutung eines Modells.

Sie schreibt die Skill inert, sodass ihre Beschreibung nie in den Kontext von irgendjemandem gelangt. Das Gate ist strukturell, nie ein Prosa-Urteil: einen konkreten Fehler nennen, den die Skill verhindert, und jeder Pfad, den sie zitiert, wird gegen das Dateisystem geprüft. Nur der Mensch befördert sie.

Getestet gegen sechs feindselige Entwürfe, einen eingebauten Skill überschatten, „spart Zeit", nur einmal beobachtet, erfundene Pfade, ein überdimensionierter Text: alle abgelehnt, der gültige zugelassen.

Der erste echte Durchlauf über dreißig Sessions fand nichts, das sich zum Entwurf gelohnt hätte. Das war die korrekte Antwort. Eine Skill wurde seitdem befördert, ein Schutz gegen einen Deploy-Befehl, der stillschweigend Production trifft.

Was noch nicht stimmt

Ehrlichkeit ist billiger als die Alternative, also hier der Rest.

Die Always-on-Schicht ist immer noch drei- bis viermal schwerer als bei Hermes, heute bei etwa 24.000 Bytes, und sie ist ein Index statt ein Profil. Die Schlankheit, die wir bewunderten, kommt aus einem Mechanismus, den wir verworfen haben, und wir haben noch keinen sanfteren gefunden, der dieselbe Disziplin erzeugt.

Konsistenz wird nicht über Grenzen hinweg durchgesetzt. In dem Moment, in dem das Nutzerprofil auslieferte, existierte jede Tatsache darin doppelt. Der Kurator prüft Memory gegen Memory, nicht Profil gegen Speicher, und nicht Memory gegen die eigene Anweisungsdatei des Projekts. Honcho ist der Beweis, dass zwei abgeleitete Sichten auf eine Tatsache irgendwann auseinanderdriften und das Modell der falschen folgt.

Erfassung feuert am Ende einer Session und vor der Kompaktierung, was genau der Moment ist, in dem eine selbstsichere Zusammenfassung einer Abfolge, die nie funktioniert hat, am wahrscheinlichsten ist. Das widerlegte Zitat oben ist das lebende Beispiel.

Eine Memory ist nur so prüfbar wie ihre Prüfroutinen. Ein Pfad, ein Branch, ein Pull Request, ein Secret und eine Instanz lassen sich verifizieren. „Dreitausend dieser Zeilen gehören zur Seite" lässt sich nicht verifizieren, und „der Nutzer bevorzugt X" ist überhaupt keine Behauptung.

Der Speicher kann immer noch eine stillschweigend falsche Aussage enthalten, er kann nur keinen stillschweigend falschen Pfad enthalten.

Beim Benchmark sind bedingte Präferenzen immer noch unser schwächster Fragetyp, und mem0 bringt den Beleg immer noch öfter in die Top 5. Die Faktennotizen laufen beim Benchmarking auf einem kleinen Modell, und es erfindet: eine las „ich habe keine Mutter, an die ich mich lehnen kann" und verzeichnete den Nutzer als Single. Und der Spitzenreiter der öffentlichen Tabelle ist genau das System, das wir nicht neu bewerten konnten.

Und das Gedächtnis des Memory-Systems über sich selbst ist inzwischen veraltet. Eine Notiz verweist auf eine Hook-Datei, die das System gelöscht hat, als es seine Hooks in ein Plugin verschob. Sie liegt in der Review-Warteschlange, als unverifiziert markiert, und wartet wie die anderen.

Die sechs Regeln

Wenn ihr eine Sache aus diesem Notizbuch mitnehmt, nehmt die Liste.

Die größere Lehre ist die, die das ganze Feld immer wieder von der falschen Seite neu entdeckt. Die Abrufhälfte des Gedächtnisses, die richtige Notiz zu finden, ist gut erforscht und meist gelöst durch einen Suchindex, der nichts kostet. Die Kontrollhälfte, zu entscheiden, was eine Notiz behaupten darf, wann sie ersetzt wird und wie eine falsche erwischt wird, ist dort, wo Gedächtnis verrottet.

Niemand verkauft diese Hälfte, weil sie kein Feature ist. Sie ist eine Disziplin, und sie muss in den Code einkompiliert werden, damit niemand sich daran erinnern muss.

Der Code, der Benchmark-Adapter und jedes bewertete Ergebnis sind Open Source unter github.com/brainyboon/quipu.

Wenn ihr sehen wollt, worauf Boon sonst noch läuft, fangt an mit Claude Code für Designer, den MCP-Servern, die einem Agenten Hände geben, KI-Agenten für Designer, und was die Tokens eines Agenten kosten, was genau die Rechnung ist, die dieses Gedächtnis bei null hält. Wenn ihr diese Sorgfalt für eure eigene Marke wollt, Brainy Studio ist, wo es anfängt.

---

FAQ

Warum vergisst Claude Code Dinge, die ich in MEMORY.md eintrage?

Claude Code lädt den Auto-Memory-Index bis maximal 200 Zeilen oder 25.000 Bytes, je nachdem, welches Limit zuerst erreicht wird, und ignoriert den Rest stillschweigend. Die Datei wird am Ende ergänzt und von unten abgeschnitten, sodass die neuesten Memories zuerst wegfallen. Wenn der Agent eine Regel ignoriert, die ihr kürzlich hinzugefügt habt, zählt die Zeilen und Bytes der Datei.

Sollte ich ein Memory-Plugin für Claude Code installieren?

Prüft zwei Dinge: ob es ein Modell im Prompt-Pfad laufen lässt, was jedem Prompt Sekunden hinzufügt, und ob es einen Hintergrund-Daemon betreibt, wo die meisten offenen Issues des größten Plugins liegen. Was unser Problem gelöst hat, war ein Volltextindex, der bei jedem Prompt durchsucht wird, Offline-Modell-Durchläufe und ein Verifikationsschritt. Nichts davon braucht einen Daemon.

Reicht Keyword-Suche für das Gedächtnis von KI-Agenten wirklich aus?

Für den Per-Prompt-Hook: ja. Beim gängigen Zero-Shot-Retrieval-Benchmark verlor jedes Single-Vector-Embedding-Modell gegen schlichte BM25-Keyword-Suche, und ein neuronaler Reranker kostet etwa 1,5 Sekunden Modell-Ladezeit gegen ein Budget von 18 Millisekunden. Für die Durchsuchung vergangener Gespräche reicht sie nicht aus: eine statische Embedding-Tabelle, ein Lookup statt ein Modell, fand den Satz, der eine Änderung ankündigt, doppelt so oft wie Keywords. Naiv mit dem Keyword-Ranking gemischt, verschlechterte sie die Ergebnisse; nach Rang fusioniert und breit gesammelt, ist sie Teil dessen, was das Unentschieden mit mem0 brachte.

Ist dieses Memory-System Open Source?

Ja. Das Plugin, der MemConflict-Benchmark-Adapter, die Methode und jede bewertete Zusammenfassung liegen unter github.com/brainyboon/quipu unter MIT-Lizenz. Der Kern braucht nur Pythons Standardbibliothek; die Bedeutungssuche braucht numpy.

Wie verhindert ihr, dass das Gedächtnis etwas Falsches glaubt?

Auf zwei Wegen. Ein Kurator, der nie löscht: ein Widerspruch markiert die ältere Memory als ersetzt, mit sichtbarer Kennzeichnung und Ranking-Abzug, jede Entscheidung wird protokolliert, und ein Befehl macht sie rückgängig. Und ein Verifizierer, der jede Memory als typisierte Behauptungen behandelt, sie gegen die reale Welt prüft und die Memory als unverifiziert markiert, wenn eine Prüfung fehlschlägt.

Was kostet der Betrieb dieses Memory-Systems?

Null Dollar an der Grenze: Abruf ist eine lokale Datenbankabfrage, und jeder Modellaufruf (Erfassung am Session-Ende, Anreicherung neuer Memories, der tägliche Widerspruchs-Durchlauf) läuft über das Abo, das ohnehin schon bezahlt wird, nie über eine abgerechnete API. Die echten Kosten sind Plan-Kontingent, ungefähr ein kleiner Aufruf pro Session. Beim MemConflict-Benchmark hat es ein Gespräch in 1,6 Sekunden abgelegt, gegen 31,6 Sekunden für mem0 auf derselben Maschine.