Memori: persistenter Zustand für Agenten, mit Cloud-Anker

Welches Problem Memori adressiert und für wen es gedacht ist

Ein Agent, der zwischen zwei Aufrufen nichts behält, muss den relevanten Kontext bei jeder Anfrage erneut mitschicken. Bei langen Sitzungen wächst der Prompt, die Kosten steigen, und ab einem bestimmten Punkt verliert das Modell Details, die weiter oben im Verlauf stehen. Genau an dieser Stelle setzt Memori an. Die README formuliert die Prämisse als "Memory from what agents do, not just what they say": nicht nur der Dialog, sondern auch Ausführungsschritte sollen als strukturierter Zustand erhalten bleiben. Die Zielgruppe ist entsprechend nicht das Notebook, sondern das Produktivsystem. Die Beschreibung nennt Enterprise-Kontexte, in denen vorhandene Dateninfrastruktur weiterverwendet werden soll, statt sie zu ersetzen. Wer einen einzelnen Chatbot mit kurzem Verlauf baut, braucht diese Schicht nicht. Wer mehrere Agenten über Sitzungen hinweg mit demselben Nutzerprofil verbindet, für den ist die Fragestellung real. Auffällig ist die Breite der genannten Integrationswege: Python und TypeScript als SDKs, dazu Plugins für OpenClaw und ein Provider für Hermes Agent. Das deutet darauf hin, dass der eigentliche Wert nicht im Speicher selbst liegt, sondern in der Anbindung an bestehende Laufzeitumgebungen.

Der Wrapper um den LLM-Client ist der eigentliche Mechanismus

Memori arbeitet nicht als Proxy und nicht als separater Dienst, den man von Hand aufruft. Laut README registriert man den vorhandenen Client beim Memori-Objekt, danach laufen die normalen Aufrufe weiter. Im Python-Beispiel steht `mem = Memori().llm.register(client)` mit einem zuvor erzeugten `OpenAI()`-Client. Das TypeScript-Beispiel verkettet `new Memori().llm.register(client).attribution('user_123', 'support_agent')`. Der Datenfluss ist damit klar umrissen: Der registrierte Client ist der Ort, an dem Memori ansetzt, und die Antworten werden "automatically in the background" persistiert. Die README sagt nicht, ob das über einen Monkey-Patch, einen Decorator oder eine eigene Transport-Schicht geschieht. Wer das vor einem Produktiveinsatz wissen muss, findet es nur im Quellcode oder in der Dokumentation, nicht in der README. Das zweite Element ist die Attribution. `entity_id` und `process_id` im Python-Beispiel, `user_123` und `support_agent` im TypeScript-Beispiel, legen fest, wem ein Gedächtniseintrag gehört und welcher Prozess ihn erzeugt hat. Das ist die entscheidende Designentscheidung: Ohne diese Zuordnung wäre der Speicher ein globaler Topf, aus dem jeder Agent alles liest. Memori macht die Trennung zur Pflicht, bevor der erste Aufruf erfolgt.

Installation und Inbetriebnahme: zwei Wege, ein Schlüssel

Der kürzeste Weg führt über Memori Cloud. Zuerst `pip install memori` oder `npm install @memorilabs/memori`, dann ein Konto unter app.memorilabs.ai, dann ein API-Key. Die Umgebungsvariablen sind `MEMORI_API_KEY` und der Schlüssel des Modellanbieters, im Beispiel `OPENAI_API_KEY`. Beide müssen gesetzt sein, bevor der Client registriert wird. Der Code selbst bleibt kurz: Client erzeugen, registrieren, attribuieren, `client.chat.completions.create` aufrufen. Die README verspricht, dass die zweite Anfrage nach dem Lieblingsfarben-Beispiel die vorher gespeicherte Information zurückliefert. Das ist ein Beispiel aus der Dokumentation, kein von mir nachgestellter Lauf. Wer den Cloud-Pfad nicht will, wird auf die BYODB-Dokumentation verwiesen, also auf die Anbindung an eine eigene Datenbank. Für Wegwerf-Datenbanken in der Entwicklung nennt die README einen TiDB-Zero-Provisioning-Leitfaden unter docs/memori-byodb/databases/tidb.mdx. Ein Hinweis auf die Reife des Projekts: Die README beschreibt den Cloud-Pfad ausführlich und den BYODB-Pfad mit einem Satz plus Link. Die Reihenfolge der Abschnitte ist ein Signal dafür, welcher Betriebsmodus der bevorzugte ist.

Die LoCoMo-Zahlen und was sie nicht belegen

Memori gibt an, auf dem LoCoMo-Benchmark für Langgesprächs-Gedächtnis 87 Prozent Gesamtgenauigkeit erreicht zu haben, bei durchschnittlich 721 Tokens pro Anfrage. Das seien 2,8 Prozent des Full-Context-Footprints. Die README nennt außerdem Vergleiche: besser als Zep, LangMem und Mem0, rund 67 Prozent weniger Prompt-Größe als Zep und mehr als 36-fach geringere Kontextkosten gegenüber Full-Context-Prompting. Diese Zahlen stammen aus der Projekt-README und verweisen auf eine Benchmark-Übersicht, eine Ergebnisseite und ein Paper unter arxiv.org/abs/2603.19935. Ich habe weder den Benchmark nachgefahren noch die Ergebnisseite geprüft. Wer die Zahlen als Einkaufsargument verwenden will, muss die verlinkten Dokumente selbst lesen, insbesondere die Frage, welche Modelle, welche Datensätze und welche Ausschlusskriterien galten. Ein Token-Durchschnitt von 721 pro Anfrage ist eine Größe, die stark davon abhängt, wie ein Gedächtniseintrag im Prompt landet. Die README erklärt diesen Mechanismus nicht. Das ist die größte Lücke im vorliegenden Material: Die Zahlen sind präzise, die Ursache dahinter bleibt offen.

Zwei Integrationen zeigen, wo der Aufwand wirklich liegt

Der OpenClaw-Pfad läuft über ein Plugin. Die Befehle sind `openclaw plugins install @memorilabs/openclaw-memori`, `openclaw plugins enable openclaw-memori`, dann `openclaw memori init` mit `--api-key`, `--entity-id` und `--project-id`, anschließend `openclaw gateway restart`. Laut README sind keine Änderungen am Agentencode oder an den Prompts nötig, weil das Plugin in den Lebenszyklus von OpenClaw einhängt und nach jeder Runde Tool-Aufrufe, Entscheidungen und Ergebnisse erfasst. Der Hermes-Pfad ist anders aufgebaut. Dort installiert man `pip install hermes-memori` und ruft `hermes-memori install` auf, setzt `hermes config set memory.provider memori` und legt `MEMORI_API_KEY` sowie `MEMORI_ENTITY_ID` in `$HERMES_HOME/.env` ab. Zusätzlich bekommt der Agent explizite Werkzeuge, `memori_recall` und `memori_recall_summary`, also agentengesteuerten Abruf statt automatischer Injektion. `MEMORI_PROJECT_ID` ist hier optional und fällt auf den aktiven Projektkontext zurück. Diese beiden Wege unterscheiden sich nicht in der Speicherung, sondern darin, wer entscheidet, wann erinnert wird. Das ist der interessante Teil der Architektur, und die README benennt ihn nur indirekt.

Grenzen: Cloud-Bindung, Lizenzstatus und die fehlende lokale Antwort

Der Quickstart führt ohne Umweg über einen gehosteten Dienst mit API-Key. Wer den Speicher selbst betreiben will, landet bei BYODB, und die README liefert dafür kein vollständiges Beispiel, nur einen Verweis. Das ist der erste ernste Vorbehalt: Die README beschreibt die eigene Datenbankanbindung nicht in einer Weise, die eine Entscheidung ohne weiteres Lesen erlaubt. Der zweite Vorbehalt betrifft die Lizenz. Das Repository gibt als Lizenz NOASSERTION an, während die README ein Apache-2.0-Badge zeigt und auf opensource.org/license/apache-2-0 verlinkt. Diese beiden Angaben widersprechen sich. Für eine Adoption in einem Unternehmen ist das kein Detail, sondern die erste Frage, die die Rechtsabteilung stellt. Ich kann hier nicht klären, welche der beiden Angaben zutrifft, und gebe dazu auch keine rechtliche Einschätzung ab. Der dritte Vorbehalt ist struktureller Natur. Die README nennt keine Angaben zu Betriebsgrenzen: keine Zahlen zu Durchsatz, Latenz oder Speichervolumen, keine Beschreibung, was bei einem Ausfall des Gedächtnisdienstes mit laufenden Agenten geschieht. Bei einem System, das in den Anfragepfad eingehängt ist, ist das die Frage, die über Produktionstauglichkeit entscheidet. Wer Antworten braucht, wird sie außerhalb der README suchen müssen.

Mem0 als Alternative: gleiche Aufgabe, anderer Ansatzpunkt

Mem0 wird in der README selbst als Vergleichspunkt genannt, was den Vergleich nahelegt. Der Unterschied liegt weniger in der Zielsetzung als im Angriffspunkt. Memori hängt sich nach eigener Darstellung an den LLM-Client, den man ohnehin benutzt, und macht die Registrierung zur Voraussetzung. Der Aufrufcode bleibt unverändert. Mem0 wird in der Regel als eigener Dienst oder als Bibliothek angesprochen, die man explizit mit Nachrichten füttert und explizit abfragt. Das verschiebt die Kontrolle: Bei Memori entscheidet die Schicht im Hintergrund, was gespeichert und zurückgegeben wird. Bei einem expliziten Modell entscheidet der Anwendungscode. Wer nachvollziehen muss, warum ein bestimmter Satz im Prompt gelandet ist, hat es mit einem expliziten Modell leichter. Wer viele bestehende Aufrufstellen hat und sie nicht anfassen will, hat es mit dem Wrapper-Ansatz leichter. Beide Wege sind vertretbar, aber sie passen zu unterschiedlichen Teams. Die README von Memori argumentiert an dieser Stelle mit den LoCoMo-Zahlen; ein Architekturvergleich fehlt. Wer zwischen beiden wählt, sollte den Vergleich anhand der eigenen Abfragemuster führen und nicht anhand eines Benchmark-Ergebnisses.

Wartung, Versionen und was vor dem Einsatz zu prüfen ist

Die letzten Releases liegen bei v3.3.6, v3.3.5 und v3.3.4, alle aus Mai 2026, mit Abständen von einer bis acht Tagen. Das Muster deutet auf einen aktiven Release-Zyklus mit häufigen Patch-Versionen hin. Für Betreiber bedeutet das zweierlei. Erstens: Ein Upgrade ist kein seltenes Ereignis, sondern ein regelmäßiger Vorgang, der eingeplant werden muss. Zweitens: Die Versionsnummern bleiben in der 3.x-Reihe, was auf abwärtskompatible Änderungen hindeutet, aber nichts über Änderungen am Verhalten der Speicherlogik aussagt. Genau dort liegt das Risiko. Ein Patch, der die Auswahl der erinnerten Einträge verändert, ist kein Bruch der API und taucht in keiner Kompatibilitätsprüfung auf. Wer Memori einsetzt, sollte deshalb die eigene Testsuite um Fälle erweitern, die prüfen, ob eine zuvor gespeicherte Information nach einem Upgrade noch zurückgegeben wird. Die Lizenzfrage aus dem vorigen Abschnitt bleibt offen und ist vor jedem produktiven Einsatz zu klären, weil sie die Weitergabe und den Betrieb beeinflusst. Das Repository selbst liefert dazu widersprüchliche Angaben.

Redaktionelles Fazit

Memori passt zu Teams, die bereits einen OpenAI-kompatiblen Client im Code haben und Gedächtnis nicht selbst bauen wollen. Wer den Speicherpfad vollständig kontrollieren muss oder eine klar benannte OSI-Lizenz voraussetzt, sollte zuerst die BYODB-Dokumentation und die LICENSE-Datei im Repository prüfen, bevor Code darauf aufsetzt.

Offizielle Quellen

1. Issues
2. MemoriLabs/Memori on GitHub
3. Project website
4. README
5. Releases