Ich habe „memorize“ gebaut, damit AI-Agenten Projekterinnerungen teilen können — und ich brauche Hilfe

Das begann mit einem Problem, das ich als Solo-Entwickler jeden Tag erlebt habe. Anbieter bringen ständig bessere Modelle heraus, und jedes Mal, wenn ich für die weitere Entwicklung auf ein anderes Modell wechselte (zum Beispiel von Opus 4.7 zu GPT 5.5), kam das Arbeitsgedächtnis des Projekts nicht mit. Während jeder Agent sein eigenes Memory-Silo aufbaute, musste ich den unterbrochenen Kontext jedes Mal von Hand wiederherstellen. Die frühen Memory-Funktionen der Agenten waren viel zu schwach: Nach dem Ende einer Session war der Kontext tot, und weil alles an eine einzelne Maschine gebunden war, ließ sich Arbeit vom Desktop nicht auf dem Laptop fortsetzen.

Projekte brauchen ein eigenes Gedächtnis. Also habe ich genau das gebaut: ein lokal-zuerst gedachtes Open-Source-Projekt, bei dem das Projekt selbst Erinnerungen hat.

Technische Punkte, von denen ich überzeugt bin

• 2-stufiger Speicher nach dem Vorbild des komplementären Lernsystems (CLS) des Gehirns — während der Arbeit werden Beobachtungen ohne LLM günstig nur erfasst (Hippocampus), an Session-Grenzen erfolgt die Konsolidierung im Hintergrund (Neokortex). Vergessen passiert nicht durch Löschen, sondern nur durch Score-Konkurrenz beim Abruf (Wichtigkeit × 14-Tage-Halbwertszeit der Aktualität × Aufgabenrelevanz), und keine Erinnerung wird gelöscht.

• Null API-Keys — für die Integration ist kein separates LLM nötig. Bereits eingeloggte claude -p / codex exec werden direkt gestartet. Der Agent nutzt sich selbst, um seine eigenen Erinnerungen zu ordnen; die dabei entstehende Endlosrekursion (Integration → Hook-Auslösung → Integration → …) wird mit einem Environment-Variable-Guard unterbrochen.

• Verlustfreie Konsolidierung — der Watermark wird nur nach der Event-Persistierung weitergeschoben; wenn also LLM-Timeouts oder Parsing-Fehler auftreten, versucht die nächste Grenze denselben Bereich erneut. Selbst wenn der Watermark selbst verloren geht, verhindert quellbasierte Deduplizierung doppelte Konsolidierung.

• Serverlose Konvergenz über mehrere Maschinen hinweg — synchronisiert man den append-only Event-Log, konvergieren alle Maschinen allein mit inhaltsbasierten deterministischen Regeln zum selben Zustand, ganz ohne Uhrensynchronisation. Selbst wenn zwei Maschinen gleichzeitig denselben Bereich konsolidieren, wählen alle Replikate denselben Gewinner.

• Beim Erkennen von Widersprüchen wird Embeddings nicht vertraut — Kosinus-Ähnlichkeit ist blind für Verneinungen ("merge es" und "merge es nicht" sind fast derselbe Vektor). Deshalb wird Ähnlichkeit nur zum Candidate Retrieval genutzt; die Entscheidung trifft das LLM. Eine unterlegene Erinnerung wird nicht gelöscht, sondern ihr Gültigkeitszeitraum wird geschlossen, sodass sich „damals war das wahr“ wiederherstellen lässt.

• Echtzeitfreigabe zwischen parallelen Sessions — Sessions im selben Projekt sehen die Arbeit der jeweils anderen, und wenn sie dieselbe Datei anfassen, erscheint eine Konfliktwarnung.

• Das Schema wird nicht theoretisch, sondern anhand von Messdaten weiterentwickelt — ob die Klassifikation von Erinnerungen geändert werden soll, entscheide ich datengestützt, indem ich über einige Wochen beobachtungsbezogene Lebensdauerfelder pro Erinnerung und Verhaltens-Telemetrie sammle (wann wurde etwas injiziert, wann wurde es invalidiert). Die gesamte Diskussion dazu ist öffentlich in den Repository-Discussions einsehbar.

Warum ich es jetzt veröffentliche

Ehrlich gesagt hätte ich es lieber ausgereifter veröffentlicht. Aber als ich gesehen habe, dass OpenAI Memory-Funktionen wie dreaming herausbringt, habe ich meine Meinung geändert — wenn große Anbieter anfangen, dasselbe Problem anzugehen, ist das ein Zeichen, dass die Richtung stimmt, und ich finde, es sollte eine anbieterneutrale Alternative geben, bevor in Anbieter eingeschlossene Erinnerungen zum Standard werden. Deshalb veröffentliche ich es jetzt.

Wo ich hinwill

Mit Modellen auf Fable-5-Niveau können Agenten inzwischen miteinander kooperieren, aber es fehlt die gemeinsame Infrastruktur dafür. Langfristig möchte ich eine gemeinwohlorientierte Plattform bauen, die für Erinnerungen und Zusammenarbeit von Agenten das leistet, was Git für Code geleistet hat. Weil mir das Geld fehlt, konnte ich nicht mit Servern anfangen — und gerade diese Einschränkung hat zu einem lokal-zuerst Design geführt, das auch ohne Server konvergiert. Im Moment funktioniert dieses erste Puzzleteil, „Projektgedächtnis lokal teilen“, vollständig. Tatsächlich habe ich große Teile der Designdiskussion, der Implementierung und sogar des heutigen Deployments in den frühen Morgenstunden gemeinsam mit Agenten gemacht — genau in der Art der Zusammenarbeit, die dieses Tool ermöglichen soll.

Wobei ich konkret Hilfe brauche

1. Ausprobieren und Bruchstellen melden — One-Line-Installation, dann ein Issue aufmachen. Allein bei der Verifikation vor dem heutigen Release habe ich schon zwei Bugs im Installationsskript gefunden (PowerShell-5.1-Quotes, Linux EACCES), und es gibt sicher noch mehr.
2. Adapter für andere Agenten — Leute, die sich mit den Hook-Strukturen von Cursor, Gemini CLI oder Windsurf auskennen.
3. Beteiligung an der Debatte zur Klassifikation von Erinnerungen — es gibt offene Discussions dazu, „was für Arten von Erinnerungen es gibt“, und die Entscheidung soll datenbasiert fallen.

Die Installation ist ein Einzeiler (für Windows siehe den PowerShell-Befehl im README):

curl -fsSL https://raw.githubusercontent.com/shakystar/memorize/… | sh

Oder eine Zeile in einer Claude-/Codex-Session: "Set up memorize in this project. Follow
https://github.com/shakystar/memorize/…;

Repository: https://github.com/shakystar/memorize · koreanisches README
(https://github.com/shakystar/memorize/blob/main/docs/i18n/README.ko.md) · Architekturdokument
(https://github.com/shakystar/memorize/blob/main/docs/ARCHITECTURE.md)

AGPL, alles wird lokal gespeichert, keine Telemetrie. Jegliches Feedback ist willkommen.

[shakystar]

Ich bin der Ersteller.

Der Tag direkt vor dem Release dieses Projekts entsprach genau der Art von Zusammenarbeit, auf die dieses Tool abzielt. Ich habe mit dem Agenten eine Design-Diskussion geführt wie „Sind Tags für die Klassifizierung von Erinnerungen wirklich passend, das Gehirn hat doch auch keine Tags“, der erzielte Konsens wurde in GitHub Discussions und Issues festgehalten, der Implementierungs-PR wurde gemergt, und ich habe sogar Dogfooding bestätigt, bei dem der Agent sich selbst (claude -p) als Extraktor verwendet, um echte Arbeitsprotokolle in das Langzeitgedächtnis zu integrieren, bevor ich auf den Deploy-Button gedrückt habe. Die Design-Debatten in diesem Prozess sind alle offen in den Discussions des Repositorys einsehbar.

Eine Frage, die wahrscheinlich häufig kommt und die ich im Artikel nicht beantwortet habe, ist: „Wird das nicht langsamer oder kostet extra?“ Die Antwort vorweg: Während der Arbeit hilft das LLM überhaupt nicht mit. Das Erfassen läuft über einen Regel-Filter, daher gibt es subjektiv 0 Verzögerung, und das LLM läuft nur ein einziges Mal bei der Integration an der Sitzungsgrenze; selbst das geschieht in einem getrennten Hintergrundprozess und blockiert den Agenten keine einzige Sekunde. Sogar dieser Aufruf läuft über Ihr bereits genutztes claude-/codex-Abo, es gibt also keine separate API-Abrechnung. Beim heutigen Dogfooding wurden für eine Sitzung 44 Beobachtungen in einem einzigen Hintergrundaufruf (ca. 30 Sekunden) zusammengeführt, und auch die Injektion beim Sitzungsstart ist nur Text innerhalb eines Budgets von 4.000 Zeichen, sodass die Token-Belastung nahezu null ist. Das Ziel war, dass man es installiert und dann vergisst.

Eines der Dinge, die wir bei der Verifikation auf realer Hardware vor dem Release entdeckt haben, teile ich exemplarisch: Im README stand als Prüfkommando npx memorize, aber das unscoped memorize auf npm ist das Paket von jemand anderem. Gerade solche Punkte, die „nur auf echter Hardware sichtbar werden“, wird es vermutlich noch mehr geben, daher sind Hinweise dazu wirklich wertvoll.

Bitte: Windows sowie WSL/Linux habe ich selbst auf realen Geräten getestet, aber ich habe kein echtes macOS-Gerät. In der CI läuft die komplette macOS-Testsuite erfolgreich durch, aber den vollständigen Zyklus von Einzeilen-Installation → Hook → Injektion beim Sitzungsstart konnte ich nicht auf echter Hardware testen. Wenn jemand mit macOS es einmal installiert und mir per Kommentar oder Issue mitteilt, ob es funktioniert oder kaputtgeht, wäre das eine große Hilfe.

Auch Design-Fragen (warum Embeddings nicht für Entscheidungen verwendet werden, warum es kein Löschen gibt, wie Konvergenz über mehrere Maschinen ohne Uhr funktioniert) sind willkommen — ich beantworte alles.