AuthorsZhiyu Li, Shichao Song, Hanyu Wang et al.
TL;DR
MemOS uses the MemCube abstraction plus MemScheduler and MemGovernance to turn LLM memory into a first-class OS resource, unifying parametric, activation, and plaintext memory without new benchmarks.
Read our summary here, or open the publisher PDF on the next tab.
THE PROBLEM
MemOS highlights that current LLMs “fundamentally lack a unified and structured architecture for handling memory,” causing fragmented parametric, activation, and plaintext memory.
MemOS shows that this fragmentation breaks long term conversational state, user preference persistence, and multi agent workflows, leading to cross platform memory silos and poor knowledge evolution.
HOW IT WORKS
MemOS centers MemCube, MemScheduler, MemLifecycle, MemOperator, MemVault, and MemGovernance to treat memory as a schedulable, governed resource across parametric, activation, and plaintext forms.
You can think of MemOS like an operating system where MemCube is a process, MemVault is disk, and MemScheduler is the CPU scheduler coordinating memory access.
This OS style design lets MemOS perform cross type memory transformations and lifecycle control that a plain context window or ad hoc RAG pipeline cannot achieve.
DIAGRAM
This diagram shows how MemOS routes a prompt through MemReader, MemScheduler, and MemOperator, then persists MemCube units via MemVault and MemGovernance.
DIAGRAM
This diagram shows how MemOS organizes Interface, Operation, and Infrastructure layers around MemCube to manage the full memory lifecycle.
PROCESS
Interface Layer Memory API and Pipeline
MemOS uses MemReader and the Memory API to parse natural language into structured MemCube based operation chains that define provenance, updates, and log queries.
Operation Layer Memory Scheduling and Lifecycle Management
MemScheduler, MemOperator, and MemLifecycle coordinate which MemCube units to load, how to organize them, and when to version, rollback, or freeze them.
Infrastructure Layer Governance and Memory Store
MemVault, MemGovernance, and MemStore enforce access control, expiry policies, and cross platform circulation for MemCube units across agents and applications.
Closed loop Memory I O Path
MemOS routes prompts through scheduling, injection into LLM inference, and back into MemVault, forming a reusable, traceable MemCube lifecycle across sessions.
KEY CONTRIBUTIONS
Memory Cube as unified abstraction
MemOS introduces MemCube to encapsulate parametric, activation, and plaintext memory with descriptive, governance, and behavioral metadata for cross type scheduling and evolution.
Three layer MemOS architecture
MemOS defines Interface, Operation, and Infrastructure layers with MemScheduler, MemLifecycle, MemOperator, MemVault, MemGovernance, and MemStore to manage full memory lifecycles.
Memory Interchange Protocol and marketplace
MemOS proposes a Memory Interchange Protocol and MemStore to support cross LLM memory sharing, self evolving MemBlocks, and a decentralized memory marketplace.
RESULTS
Memory types unified
3 types
Parametric, activation, and plaintext unified in MemOS
MemCube metadata fields
11 fields
Created, last used, source, model, usage, priority, expires, access, tags, embedding fp, storage mode
MemOS architecture layers
3 layers
Interface, Operation, and Infrastructure layers in MemOS design
Future directions
3 goals
Cross LLM sharing, self evolving MemBlocks, scalable memory marketplace
MemOS is a systems and architecture paper without benchmark tables, so the key quantitative facts describe how many memory types, metadata fields, and architectural layers MemOS unifies. These design numbers show that MemOS systematically covers the full memory lifecycle rather than optimizing a single metric.
BENCHMARK
MemOS is a systems and architecture paper without benchmark tables, so the key quantitative facts describe how many memory types, metadata fields, and architectural layers MemOS unifies. These design numbers show that MemOS systematically covers the full memory lifecycle rather than optimizing a single metric.
BENCHMARK
Relative emphasis of parametric, activation, and plaintext memory in the MemOS design.
KEY INSIGHT
MemOS argues that simply scaling pre training and post training hits diminishing returns, and that a new “mem training” scaling law is needed.
This is counterintuitive because most builders assume larger models and better fine tuning are enough, but MemOS claims structured memory governance is the real next frontier.
WHY IT MATTERS
MemOS unlocks LLMs that can accumulate experience, retain user specific preferences, and evolve behavior over time through MemCube based lifecycle control.
With MemOS, builders can design agents that share governed memory across users, platforms, and models instead of relying on brittle prompts or siloed RAG stores.
Nikhil Verma
· 2026
Focus Agent adds start_focus, complete_focus, a persistent Knowledge block, and an optimized Persistent Bash plus String-Replace Editor scaffold to actively compress context during long software-engineering tasks. On five hard SWE-bench Lite instances against a Baseline ReAct agent, Focus Agent achieves 22.7% token reduction (14.9M → 11.5M) while matching 3/5 = 60% task success.
Xingyu Lyu, Jianfeng He et al.
· 2026
ADAM combines Anchor extraction, Distribution estimation, Anchor selection, and Query generation to adaptively probe agent memory via an auxiliary generator and entropy based selection. On the EHRAgent benchmark with Llama2-7b-chat, ADAM reaches EQ=77 and ASR=1.00, compared to MEXTRA’s EQ=44 and ASR=0.89.
Shannan Yan, Jingchen Ni et al.
· 2026
AdaMem organizes dialogue history into Working Memory, Episodic Memory, Persona Memory, and Graph Memory coordinated by a Memory Agent, Research Agent, and Working Agent. On LoCoMo with GPT-4.1-mini, AdaMem achieves 44.65 F1 overall, beating the best baseline LangMem at 41.76 F1 by +2.89.
Answers use this explainer on Memory Papers.
Checking…