MemOS

Large language models forget everything the moment a conversation ends. Each new session starts from zero, so agents repeat questions, lose track of stated preferences, and burn tokens re-reading context that was already established. MemOS, from the MemTensor team, tackles this by treating memory as a first-class system rather than a side effect of the context window. It positions itself as a self-evolving memory operating system for LLMs and AI agents: a unified place to store, retrieve, edit, and delete long-term memory across sessions and tasks. The pitch is that an agent should accumulate structured, queryable knowledge about a user or project over time, instead of relying on a prompt stuffed with raw history. It ships both as open source under Apache-2.0 and as a managed cloud service.

MemOS organizes memory into tiers rather than one flat embedding store. The layers run from raw interaction traces up through learned policies and preferences to a broader world model of the user, with crystallized skills meant to be reused across tasks. What is distinctive is that memory is stored as graphs rather than opaque vectors, which the project describes as inspectable and editable by design. Retrieval is hybrid: it pairs full-text search via FTS5 with vector lookups, and the self-hosted stack leans on Qdrant for vectors and Neo4j for the graph. A multi-cube concept lets you compose separate memory units for users, projects, and agents, and a scheduler handles asynchronous ingestion. It accepts not just text but images, tool execution traces, and persona data through one API.

MemOS fits teams building multi-session agents that need durable, structured memory without standing up their own vector and graph infrastructure from scratch. Concrete cases include a customer-support assistant that remembers a user's account history and prior tickets, a coding agent that retains project conventions and decisions across days, or a personal assistant that learns preferences and recalls them weeks later. The cube model suits multi-tenant setups where each user or workspace needs isolated memory. Because it is model-agnostic and can sit alongside existing agent frameworks and RAG pipelines, it appeals to developers who want a memory layer they can query through a unified add, search, and edit API, and who value the option to inspect or correct what the system has stored using natural language feedback.

The honest caveats are real. The codebase is TypeScript-heavy, with TypeScript the majority language and Python secondary, which can feel unfamiliar to Python-first teams expecting a pip-installable library. The boundaries between the free self-hosted runtime and the paid cloud tiers are not clearly documented, so it is hard to know upfront which features require the managed service. MemTensor is a young organization, and its long-term maintenance trajectory is not yet proven. The headline numbers, including the roughly 35% token savings and the benchmark gains on LongMemEval and PersonaMem, are the project's own claims and have not been independently reproduced here. Self-hosting also means operating Qdrant and Neo4j yourself, which adds infrastructure overhead that the cloud option exists to avoid.

Against its main commercial alternative, Mem0, MemOS is the more architecturally ambitious choice: tiered, graph-based, multi-modal memory with inspectable structure, versus Mem0's leaner and more established developer experience. If your agents are simple single-session chatbots where the context window already holds everything, MemOS is too early and adds complexity you do not need. It earns its place when you are building agents that span many sessions, need queryable long-term memory, and want to avoid wiring together a vector store and graph database yourself. For teams in that position, it is worth a serious trial, ideally starting with the cloud tier to validate the approach before committing to the self-hosted stack and its operational weight.