MemoryOS: A Hierarchical Memory Layer for Personalized AI Agents
[EMNLP 2025 Oral] MemoryOS is designed to provide a memory operating system for personalized AI agents.
At a glance
- What is it?
- MemoryOS is an Apache-2.0 Python project from BAI-LAB that gives agents a three-tier memory structure plus an MCP server. It is a research artifact with a published paper, a LoCoMo evaluation, and a configuration surface that assumes you already run an LLM stack.
- Who is it for?
- Adopt MemoryOS if you are building a conversational agent that must recall a specific user across sessions and you are willing to run an LLM plus an embedding model plus a vector store yourself. Do not adopt it if you need a managed service, a stable API surface, or a memory layer that works without calling out to a model provider.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 71 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem MemoryOS targets: an agent that forgets who it is talking to
A stateless LLM call has no memory between turns beyond whatever you paste into the context window. Long conversations push older material out, and a new session starts from zero. MemoryOS is aimed at that gap. The README describes it as a memory operating system for personalized AI agents, and the framing is deliberate: it borrows from operating system memory management, where data moves between fast small storage and slow large storage under a policy. The project's own paper, Memory OS of AI Agent (arXiv 2506.06326), describes managing short-term, mid-term and long-term personal memory through hierarchical storage, dynamic updating, retrieval and generation. The intended user is someone building a companion, assistant or agent that needs continuity about a particular person over weeks, not a single session. The README also states the project was accepted to the EMNLP 2025 main conference, so the target audience includes researchers reproducing a published method as much as application developers.
Four modules and three tiers: the mechanism the README describes
The architecture has four named modules: Storage, Updating, Retrieval and Generation. Storage holds the memory tiers. Updating decides what gets written and when. Retrieval selects relevant memory for a query. Generation turns retrieved memory plus the current turn into a response. The paper abstract in the README frames this as short-term, mid-term and long-term persona memory with automated user profile and knowledge updating. The tiering is the interesting part: rather than one flat vector index of every utterance, memory is promoted or demoted between levels, which is what makes the OS analogy more than branding. The README does not spell out the promotion policy in the material available here, so treat the exact demotion and eviction rules as something to read in the paper or the documentation page rather than assume. What is confirmed is that the modules are described as pluggable: storage engines, update strategies and retrieval algorithms can be swapped. A later release note confirms this in practice, since V1.2 added ChromaDB as a vector database option and fixed an issue with fixed LLM calls inside it.
Getting it running: PyPI package, MCP server, Docker
There are three entry points visible in the material. The first is the PyPI implementation, which the README's news entries treat as the primary library and which received a parallelization upgrade described as 5 times faster in latency. The second is MemoryOS-MCP, an MCP server that exposes memory as modular tools so an MCP-capable client can call it. The README's support table lists Claude Desktop as an agent client under MCP configuration. The third is Docker, integrated into deployment as of July 2025. Configuration is file-based. The README names one concrete key, similarity_threshold, added in July 2025, and points to the documentation page for the full config file. Model selection is also configuration: the README states support for OpenAI, Deepseek and Qwen, with specific mentions of Deepseek-r1 and Qwen3 inference models, and BGE-M3 and Qwen3 embeddings on both PyPI and MCP. A Playground platform exists at baijia.online/memoryos but requires an invitation code obtained by contacting the team, so it is not a self-serve path. The exact install command and the full config schema are not in the material supplied here; check the documentation page before writing your config.
What the LoCoMo numbers do and do not tell you
The headline claim is an average improvement of 49.11% in F1 and 46.18% in BLEU-1 on the LoCoMo benchmark. Two things matter about that sentence. First, it is a benchmark result reported by the authors, measured on a long-term memory benchmark, not a production latency or cost measurement. Second, the README links a reproduce section, which is the right posture for a paper artifact: the evaluation is publicly available rather than asserted. BLEU-1 on conversational memory is a lexical overlap measure and will reward responses that reuse the user's phrasing; F1 on the same task is the more informative of the two, and neither captures whether the agent retrieved the right memory for the wrong reason. If you are choosing a memory layer for a product, run the reproduce path against your own conversation distribution before trusting the delta. The number is a reason to look, not a reason to adopt.
Where MemoryOS is the wrong tool
The project is a research release with a fast-moving surface. Three releases landed in six days in July 2025, and the changelog includes an API-adjacent fix (fixed LLM calls inside ChromaDB) in the same window that added the ChromaDB backend. That cadence is normal for a lab project and hostile to anyone pinning a dependency for a multi-year product. The second constraint is operational: MemoryOS does not run standalone. It needs an inference model, an embedding model and a vector store, and the README's supported model list is a configuration burden rather than a convenience. If your deployment cannot call an external model provider, or if you need memory that works offline with a small local model, this is not the layer for you. Third, the Playground is gated behind an invitation code, so the hosted experience is not something you can evaluate without contacting the team. And if your agent only needs to remember the last twenty turns of a single session, a context window and a summarization step will cost less to build and less to maintain than a three-tier store.
The real alternative: a plain vector store with your own write policy
The obvious comparison is a general-purpose vector database used directly, for example ChromaDB or a similar store, with your own logic for what to embed and when to retrieve. The difference in approach is where the policy lives. A vector store gives you similarity search and nothing else: you decide what counts as a memory, when a memory is stale, and how a user profile is assembled. MemoryOS ships those decisions as the Storage, Updating, Retrieval and Generation modules, with the tiering between short, mid and long-term memory as the packaged part. That is the trade: you get an opinionated promotion policy you did not have to design, and you inherit its assumptions about what a persona memory looks like. If your memory needs are unusual, for instance a shared memory across a team of agents rather than one user's persona, the packaged policy will fight you and a raw vector store plus your own rules will be less work. The project's own framing supports this reading: the modules are described as pluggable, which is an admission that the default policy is one choice among several.
Maintenance cost, licence and what to check before you depend on it
MemoryOS is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. That is a permissive licence and the practical implication is that you can vendor it into a closed product. It is not legal advice and you should read the licence text and your own obligations, particularly the notice and attribution requirements, before shipping. On maintenance: the project is active, with the last push recorded in July 2026 and a survey paper released in January 2026, so the research line is alive. The cost you carry is integration, not the library itself. You are maintaining a configuration that spans a chat model, an embedding model and a vector backend, and the release history shows those surfaces moving. Pin a version, read the documentation page for the config schema rather than inferring keys from the README, and decide up front whether you are using the PyPI library, the MCP server, or the Docker deployment, because the material presents them as separate paths with separate setup. The MCP route is the lowest-commitment way to try it: it plugs into an existing client without restructuring your application.
Editorial conclusion
Adopt MemoryOS if you are building a conversational agent that must recall a specific user across sessions and you are willing to run an LLM plus an embedding model plus a vector store yourself. Do not adopt it if you need a managed service, a stable API surface, or a memory layer that works without calling out to a model provider. Before committing, verify the exact config keys in the documentation page at bai-lab.github.io/MemoryOS/docs, confirm which storage backend you will use (the V1.2 release note covers ChromaDB support), and reproduce the LoCoMo evaluation yourself using the reproduce section linked from the README, because the 49.11% F1 figure is the project's own measurement on its own benchmark.
Community notes