MemMachine: eine Speicherschicht für Agenten, die Neustarts überleben soll
Universal memory layer for AI Agents. It provides scalable, extensible, and interoperable memory storage and retrieval to streamline AI agent state management for next-generation autonomous systems.
Auf einen Blick
- Was ist das?
- MemMachine trennt episodisches Gedächtnis, Nutzerprofil und Kurzzeitkontext in zwei verschiedene Speicherbackend. Der Ansatz ist nachvollziehbar, verlangt aber einen laufenden Server und macht die Speicherqualität vom Betrieb von Neo4j und SQL abhängig.
- Für wen ist es gedacht?
- Wer bereits Neo4j und eine SQL-Datenbank betreibt und einem Agenten sitzungsübergreifendes Gedächtnis geben will, findet in MemMachine eine klar geschnittene Schnittstelle mit Python-SDK, REST-API und MCP-Server. Wer keine Graphdatenbank betreiben möchte oder nur wenige Dokumente für eine RAG-Pipeline ablegt, ist hier falsch und mit einem Vektorspeicher besser bedient.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem MemMachine adressiert und für wen es gedacht ist
Ein LLM-Aufruf kennt nur den Kontext, den man ihm mitgibt. Sobald die Sitzung endet, ist der Zustand weg. Wer einen Assistenten baut, der sich an Vorlieben, frühere Entscheidungen oder den Verlauf eines Gesprächs erinnern soll, muss diesen Zustand irgendwo ablegen und beim nächsten Aufruf wiederfinden. Genau diese Aufgabe übernimmt MemMachine nach eigener Beschreibung: eine Speicherschicht, die Informationen aus vergangenen Sitzungen speichert und wieder abrufbar macht.
Das README nennt drei Zielgruppen: Entwickler, die Agenten, Assistenten oder autonome Abläufe bauen, Forschende, die mit Agentenarchitekturen experimentieren, und Teams, die sitzungsübergreifenden Speicher für LLM-Anwendungen brauchen. Die Beispiele im Repository zeigen die Richtung: ein CRM-Agent, der Kundenhistorie und Deal-Phasen erinnert, ein Assistent für persönliche Finanzen, der Portfoliopräferenzen speichert, ein Schreibassistent, der einen Stilguide lernt. In allen Fällen geht es um dieselbe Anforderung: Der Agent soll beim nächsten Start nicht bei null anfangen.
Bemerkenswert ist die Abgrenzung, die das Projekt selbst zieht. Es verspricht keine Wissensdatenbank und keine Dokumentensuche, sondern Gedächtnis: episodisch, profilbezogen, kurzfristig. Wer eine RAG-Pipeline über Produkthandbücher baut, hat ein anderes Problem.
Drei Speichertypen, zwei Backends: der Aufbau
Die Architekturbeschreibung im README ist kurz, aber konkret. Agenten sprechen über eine API-Schicht mit MemMachine: REST-API, Python-SDK oder MCP-Server. MemMachine verarbeitet die Interaktion und legt sie in zwei Kategorien ab. Episodic Memory hält den Gesprächskontext und landet in einer Graphdatenbank. Profile Memory hält langfristige Nutzerfakten und landet in SQL. Dazu kommt Working Memory als Kurzzeitkontext der laufenden Sitzung.
Diese Aufteilung ist die eigentliche Designentscheidung. Fakten wie "ich sitze am liebsten am Gang" ändern sich selten und lassen sich relational sauber abfragen. Gesprächsverläufe dagegen haben Beziehungen zwischen Aussagen, Zeitpunkten und Teilnehmern, weshalb das Projekt für sie auf Neo4j setzt. Die Suche liefert entsprechend geschachtelte Ergebnisse: Im Quick-Start-Beispiel greift der Code auf results.content.episodic_memory.long_term_memory.episodes[0].content zu. Diese Pfadtiefe zeigt, dass die Antwort mehr als einen Treffer enthalten kann und der Aufrufer selbst entscheidet, welchen Teil er ausliest.
Wer diesen Aufbau übernimmt, übernimmt auch zwei Betriebssysteme. Neo4j und eine SQL-Datenbank müssen laufen, bevor der Agent etwas erinnert. Das ist keine Nebenbemerkung, sondern der Kern der Betriebskosten.
Inbetriebnahme: Client, Server, MCP
Das README macht eine Voraussetzung sehr deutlich: Der Code braucht einen laufenden MemMachine-Server. Entweder startet man ihn lokal über die Quick-Start-Anleitung der Dokumentation, oder man legt ein Konto auf der MemMachine Platform an. Ohne Server läuft nichts, auch nicht der Client.
Für den Client genügt ein pip-Aufruf: pip install memmachine-client. Danach folgt die Initialisierung gegen eine Basis-URL, im Beispiel http://localhost:8080. Über client.get_or_create_project(org_id="my_org", project_id="my_project") entsteht ein Projekt, aus dem heraus eine Memory-Instanz erzeugt wird. Diese Instanz trägt die Identifikatoren group_id, agent_id, user_id und session_id. Wer mehrere Nutzer oder mehrere Agenten in derselben Installation trennen will, tut das über diese vier Felder, nicht über getrennte Datenbanken.
Das Schreiben erfolgt über memory.add mit einem Text und optionalen Metadaten, im Beispiel metadata={"category": "travel"}. Das Lesen erfolgt über memory.search mit einer natürlichsprachigen Frage. Für MCP-Clients wie Claude Desktop oder Cursor gibt es zwei Startbefehle: memmachine-mcp-stdio für die Stdio-Variante und memmachine-mcp-http für Web-Clients. Das sind die konkreten Einstiegspunkte; alles Weitere verweist das README auf die Dokumentationsseite.
Was das README offen lässt
Die Quick-Start-Sequenz im Repository enthält eine Zeile, die beim genauen Lesen auffällt: from memmachine_client import import MemMachineClient. Ein doppeltes import-Schlüsselwort ist syntaktisch ungültig. Ob es sich um einen Tippfehler im README oder um einen Fehler in der veröffentlichten Client-Version handelt, lässt sich aus dem vorliegenden Material nicht entscheiden. Wer den Schnellstart ausprobiert, sollte diese Zeile zuerst prüfen.
Auch die Antwortstruktur wirft Fragen auf. Das Beispiel greift auf episodes[0].content zu, ein Feld namens long_term_memory und ein Feld namens episodic_memory. Ob Profile Memory in derselben Antwort einen eigenen Zweig hat, ob es eine eigene Suchmethode gibt oder ob Profilfakten in die Episoden eingemischt werden, geht aus dem README nicht hervor. Die API-Referenz wird nur verlinkt, nicht auszugsweise zitiert.
Nicht bestätigen lässt sich ebenfalls, wie das System Einträge verdichtet. Episodisches Gedächtnis wächst mit jeder Interaktion. Ob MemMachine alte Episoden zusammenfasst, ob es eine Obergrenze für die Graphgröße gibt oder ob Aufräumen Aufgabe des Betreibers ist, steht im vorliegenden Material nicht. Das ist die wichtigste offene Frage für jeden, der das System dauerhaft betreibt.
Grenzen und Fälle, in denen MemMachine das falsche Werkzeug ist
Die schwerwiegendste Einschränkung steht im README selbst: Es braucht einen laufenden Server. Für ein Experiment auf dem Laptop bedeutet das, den Server lokal zu starten. Für eine Anwendung bedeutet es, einen Dienst zu betreiben, der ausfällt, aktualisiert und überwacht werden will. Ein Agent, der ohne Gedächtnis weiterarbeiten kann, aber nicht ohne Gedächtnisdienst, hat einen neuen Single Point of Failure.
Hinzu kommt die Abhängigkeit von Neo4j. Die Graphdatenbank ist nicht optional, wenn episodisches Gedächtnis genutzt werden soll. Wer keine Graphdatenbank betreiben will oder in einer Umgebung arbeitet, in der nur ein relationaler Dienst erlaubt ist, kann den zentralen Teil des Versprechens nicht einlösen.
Falsch ist MemMachine außerdem für alle, die eigentlich Dokumente durchsuchen wollen. Der Name legt Gedächtnis nahe, nicht Wissensabruf. Ein Vektorspeicher mit Embeddings über eine statische Dokumentensammlung ist einfacher, weil er keinen zusätzlichen Dienst und keine Graphstruktur benötigt und weil sich die abgelegten Inhalte nicht durch Gespräche verändern.
Ein dritter Fall: Wenn ein Agent nur innerhalb einer Sitzung Kontext braucht, reicht ein Gesprächspuffer im Speicher des Prozesses. Ein Server plus Graphdatenbank plus SQL-Datenbank ist dafür erheblich zu viel Infrastruktur.
Abgrenzung zu Vektorspeichern und zu Framework-eigenem Memory
Der naheliegende Vergleich ist ein Vektorspeicher wie Chroma, FAISS oder pgvector. Der Unterschied liegt nicht im Modell, sondern in der Datenstruktur. Ein Vektorspeicher legt Chunks mit Embeddings ab und findet sie über Ähnlichkeit wieder. Er kennt keine Beziehungen zwischen Einträgen und keine Trennung zwischen einer Aussage über eine Person und einer Aussage innerhalb eines Gesprächs. MemMachine trennt genau dort: Fakten nach SQL, Gesprächskontext in einen Graphen. Der Preis dafür ist die zusätzliche Komponente. Der Gewinn ist, dass sich Episoden über Beziehungen verknüpfen lassen, statt nur als flache Ähnlichkeitstreffer aufzutauchen.
Der zweite Vergleich betrifft Framework-eigenes Memory. LangChain, LangGraph, CrewAI und LlamaIndex bringen jeweils eigene Speicherbausteine mit. MemMachine positioniert sich daneben, nicht darunter: Das Repository listet Integrationsordner für genau diese Frameworks sowie für AWS Strands, n8n, Dify und FastGPT. Wer bereits mit dem Memory-Modul seines Frameworks arbeitet, tauscht damit die Speicherschicht aus, nicht das Framework. Ob sich das lohnt, hängt davon ab, ob man die Trennung von Episoden und Profil tatsächlich braucht. Für einen einzelnen Chatverlauf, der in einer SQLite-Datei liegt, ist der Wechsel kaum zu rechtfertigen.
Wartung, Versionen und Lizenz
Die letzten drei Releases liegen dicht beieinander: v0.3.7 vom 1. Mai 2026, v0.3.8 vom 8. Mai 2026, v0.3.9 vom 18. Mai 2026. Der letzte Push ins Repository ist mit dem 9. September 2026 datiert. Das deutet auf ein Projekt in aktiver Entwicklung, aber auch auf eine Versionsnummer unter 1.0. Wer MemMachine einsetzt, plant besser einen Upgrade-Pfad ein, weil sich Schnittstellen vor dem Erreichen einer stabilen Hauptversion ändern können.
Das Repository steht unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen kenntlich gemacht werden. Für den Betrieb eines Dienstes auf eigener Infrastruktur entstehen daraus keine Abgaben. Das ist eine Einordnung, keine Rechtsberatung; wer MemMachine in ein Produkt einbettet, sollte die Weitergabepflichten mit der eigenen Rechtsabteilung klären.
Ein Kostenpunkt, der leicht übersehen wird: Das README nennt LLM-Agnostik und listet OpenAI, Anthropic, Bedrock und Ollama. Der Speichervorgang selbst scheint also ein Sprachmodell zu berühren. Ob jeder memory.add-Aufruf ein Modell aufruft und damit pro gespeicherter Aussage Kosten erzeugt, geht aus dem vorliegenden Material nicht hervor. Das ist vor einem Produktiveinsatz zu klären, weil es die Betriebskosten direkt bestimmt.
Redaktionelles Fazit
Wer bereits Neo4j und eine SQL-Datenbank betreibt und einem Agenten sitzungsübergreifendes Gedächtnis geben will, findet in MemMachine eine klar geschnittene Schnittstelle mit Python-SDK, REST-API und MCP-Server. Wer keine Graphdatenbank betreiben möchte oder nur wenige Dokumente für eine RAG-Pipeline ablegt, ist hier falsch und mit einem Vektorspeicher besser bedient. Vor dem Einsatz zu prüfen: ob die eigene Installation den Client aus memmachine-client gegen einen selbst gehosteten Server auf http://localhost:8080 verbindet, welche Speichertypen die Suchantwort tatsächlich befüllt und ob die Lizenzangabe im Repository (Apache-2.0) zu den Anforderungen des eigenen Projekts passt.
Community-Notizen