agent-memory

Ein Agent, der seine Session schließt, vergisst alles, was er in ihr gelernt hat, und die beiden üblichen Lösungen kosten beide etwas: ein Retrieval-Stack aus Embeddings und Graph, der einen undurchsichtigen Textschnipsel zurückgibt, den man nicht inspizieren oder migrieren kann, oder ein flaches Markdown-Dateisystem, das lesbar bleibt, aber nicht mehr rankt, sobald der Baum über eine Listing-Ansicht hinauswächst. agent-memory von tigerless-labs, veröffentlicht im September 2026, versucht beides zugleich zu sein. Reine Markdown-Dateien in einem Store sind die einzige Quelle der Wahrheit, ein lokaler, jederzeit neu baubarer SQLite-Index daneben dient nur als Ranking-Cache. Claude Code, Codex CLI und alles, was eine Shell aufrufen kann, teilen sich denselben Store, sodass eine in einem Host festgehaltene Entscheidung im anderen auffindbar ist.

Recall antwortet mit einer L0-Liste, eine Zeile pro Treffer mit Pfad, Abstract und Score, und der Agent öffnet nur so tief, wie die Aufgabe es braucht: Gliederung, dann die volle Datei, dann das zitierte rohe Sitzungsprotokoll. Drei unabhängige Lesepfade sichern sich gegenseitig ab: deterministisches Einspielen einer Root-Datei MEMORY.md beim Sessionstart, BM25-Volltextsuche über einen FTS5-Index, und, falls beide nichts finden, das schlichte Verzeichnis, das ein Agent von Hand mit ls und grep durchsuchen kann. Schreibvorgänge passieren an Gesprächsgrenzen, statt darauf zu vertrauen, dass der Agent selbst ans Festhalten denkt, und ein optionaler Sleep-Time-Durchlauf konsolidiert und räumt nach eigenem Zeitplan auf, schlägt Löschungen aber immer nur zur Bestätigung vor, löscht nie unbeaufsichtigt.

Die natürliche Zielgruppe ist ein Team, das Memory über mehr als eine Coding-Agent-CLI hinweg vereinheitlicht und will, dass der Store selbst nachvollziehbar bleibt: Jede Memory ist eine Markdown-Datei mit Frontmatter, in Git diffbar, ohne jedes Tool greifbar per grep und nachweislich rekonstruierbar, denn Index löschen und neu bauen verliert laut Test nichts. Im Innern der Bibliothek steckt kein LLM-Client, also gibt es keinen API-Key zu konfigurieren und keine separate Abrechnungsfläche; das Urteilsvermögen leiht sich das System von der jeweils schon laufenden Host-CLI, was auch bedeutet, dass jeder Schreibvorgang im Transkript dieses Hosts sichtbar bleibt, statt unsichtbar zu passieren.

Das Projekt ist zum Zeitpunkt des Schreibens drei Wochen alt, noch ohne paketiertes Release, die Installation bedeutet also Klonen und uv sync aus dem Quellcode. Der eigene Benchmark-Abschnitt ist ungewöhnlich vorsichtig darin, was er nicht beweist: Die berichtete 120-Episoden-Studie auf LongMemEval-S wird ausdrücklich als nicht vergleichbar mit veröffentlichten LongMemEval-Zahlen markiert, weil der Heuhaufen bewusst begrenzt ist, um eine Studie zur Schreibstrategie zu bleiben statt eine zur Korpusgröße. Separat erwähnenswert: Die Organisation tigerless-labs hat im Jahr 2026 etwa alle zwei bis drei Wochen ein neues Open-Source-Tool veröffentlicht, mehrere davon erreichten innerhalb weniger Wochen Tausende Stars, ein Launch-Tempo und eine Star-Geschwindigkeit, die man im Blick behalten sollte, auch wenn die Commit-Historie hier echte, extern verfasste Pull Requests mit echten Bugfixes enthält.

agent-memory lohnt einen Blick, wenn du Claude Code und Codex parallel nutzt und einen einzigen, inspizierbaren, portablen Memory-Store hinter beiden willst statt eines Blackbox-Retrieval-Dienstes. Das Engineering wirkt sorgfältiger als das Marketing vermuten lässt, der Text steht zu den Grenzen des eigenen Benchmarks statt sie zu verstecken, aber drei Wochen Historie, kein paketiertes Release und eine sehr schnell taktende Mutterorganisation bedeuten, dass es weiterhin eine Wette auf ein junges Projekt ist und keine gesetzte Wahl. Behandle die Retrieval-Genauigkeitszahlen als interessante interne Studie, nicht als unabhängiges Ergebnis, bis das Projekt oder eine dritte Partei sie reproduziert.