MemOS

Große Sprachmodelle vergessen alles, sobald ein Gespräch endet. Jede neue Sitzung startet bei null, also stellen Agenten Fragen erneut, verlieren genannte Präferenzen aus dem Blick und verbrauchen Tokens dafür, bereits etablierten Kontext noch einmal zu lesen. MemOS vom Team hinter MemTensor begegnet dem, indem es Memory als eigenständiges System behandelt und nicht als Nebenprodukt des Kontextfensters. Es versteht sich als selbst entwickelndes Memory-Betriebssystem für LLMs und AI-Agenten: ein einheitlicher Ort, um Langzeitgedächtnis über Sitzungen und Aufgaben hinweg zu speichern, abzurufen, zu bearbeiten und zu löschen. Die Idee ist, dass ein Agent mit der Zeit strukturiertes, abfragbares Wissen über einen Nutzer oder ein Projekt ansammelt, statt sich auf einen mit Rohverlauf vollgestopften Prompt zu verlassen. Es erscheint Open Source unter Apache-2.0 und zusätzlich als gehosteter Cloud-Dienst.

MemOS gliedert Memory in Ebenen statt in einen flachen Embedding-Speicher. Die Schichten reichen von rohen Interaktionsspuren über gelernte Policies und Präferenzen bis zu einem breiteren Weltmodell des Nutzers, ergänzt um verfestigte Fähigkeiten, die über Aufgaben hinweg wiederverwendbar sein sollen. Besonders ist, dass Memory als Graph gespeichert wird und nicht als undurchsichtiger Vektor, was das Projekt als von Grund auf einsehbar und editierbar beschreibt. Der Abruf ist hybrid: Er kombiniert Volltextsuche über FTS5 mit Vektorsuche, und der selbst gehostete Stack stützt sich auf Qdrant für Vektoren und Neo4j für den Graph. Ein Multi-Cube-Konzept erlaubt es, getrennte Memory-Einheiten für Nutzer, Projekte und Agenten zu kombinieren, und ein Scheduler übernimmt die asynchrone Aufnahme. Verarbeitet werden nicht nur Text, sondern auch Bilder, Tool-Ausführungsspuren und Persona-Daten über eine API.

MemOS passt zu Teams, die Agenten über mehrere Sitzungen bauen und dauerhaftes, strukturiertes Memory brauchen, ohne ihre eigene Vektor- und Graph-Infrastruktur von Grund auf aufzusetzen. Konkrete Fälle sind ein Support-Assistent, der Kontohistorie und frühere Tickets eines Nutzers behält, ein Coding-Agent, der Projektkonventionen und Entscheidungen über Tage hinweg bewahrt, oder ein persönlicher Assistent, der Präferenzen lernt und Wochen später abruft. Das Cube-Modell eignet sich für mandantenfähige Setups, in denen jeder Nutzer oder Workspace isoliertes Memory braucht. Da es modellunabhängig ist und neben bestehenden Agent-Frameworks und RAG-Pipelines laufen kann, spricht es Entwickler an, die eine Memory-Ebene über eine einheitliche API zum Hinzufügen, Suchen und Bearbeiten abfragen wollen und Wert darauf legen, Gespeichertes per natürlichsprachlichem Feedback prüfen oder korrigieren zu können.

Die ehrlichen Einschränkungen sind real. Die Codebasis ist stark TypeScript-lastig, mit TypeScript als Hauptsprache und Python als zweiter Sprache, was sich für Python-orientierte Teams ungewohnt anfühlen kann, die eine per pip installierbare Bibliothek erwarten. Die Grenzen zwischen der kostenlosen, selbst gehosteten Laufzeit und den bezahlten Cloud-Stufen sind nicht klar dokumentiert, sodass schwer vorab erkennbar ist, welche Funktionen den gehosteten Dienst voraussetzen. MemTensor ist eine junge Organisation, und der langfristige Wartungspfad ist noch nicht erprobt. Die Schlagzahlen, darunter die rund 35% Token-Ersparnis und die Benchmark-Zugewinne bei LongMemEval und PersonaMem, sind eigene Angaben des Projekts und wurden hier nicht unabhängig nachgeprüft. Selbst-Hosting bedeutet zudem, Qdrant und Neo4j selbst zu betreiben, was Infrastruktur-Aufwand schafft, den die Cloud-Option gerade vermeiden soll.

Gegenüber seiner wichtigsten kommerziellen Alternative Mem0 ist MemOS die architektonisch ehrgeizigere Wahl: gestuftes, graphbasiertes, multimodales Memory mit einsehbarer Struktur, gegenüber dem schlankeren und etablierteren Entwicklererlebnis von Mem0. Wenn deine Agenten einfache Einzelsitzungs-Chatbots sind, bei denen das Kontextfenster bereits alles hält, ist MemOS verfrüht und bringt Komplexität, die du nicht brauchst. Es verdient seinen Platz, wenn du Agenten baust, die viele Sitzungen umspannen, abfragbares Langzeitgedächtnis brauchen und es vermeiden willst, Vektorspeicher und Graphdatenbank selbst zu verdrahten. Für Teams in dieser Lage lohnt ein ernsthafter Test, am besten zunächst über die Cloud-Stufe, um den Ansatz zu prüfen, bevor man sich auf den selbst gehosteten Stack und dessen Betriebslast festlegt.