Background and Motivation: Why Universal Memory Falls Short
LLM-driven agents performing long-horizon tasks rely on memory systems to accumulate and reuse knowledge. Current mainstream approaches often adopt a one-size-fits-all fixed memory design — e.g., semantic retrieval optimized for dialogue (vector databases), or skill libraries for coding tasks. This "universal memory" paradigm tends to fail when transferred across domains.
The reason is that different tasks have fundamentally different memory needs:
- Chat dialogue: requires semantic retrieval of history based on context; fuzzy vector matching works well here.
- Household planning (e.g., robots executing home tasks): requires precise state tracking (e.g., "which room's light is already off") — exact structured queries like SQL far outperform fuzzy vector retrieval.
- Medical QA: requires extracting structured fields from conversations (symptoms, medications, dosages) and exact field matching.
- the memory data schema,
- the storage logic, and
- the agent workflow instructions.
- ALFWorld (household planning): evolved a memory program with SQL readers/writers plus caching, to precisely track environment state.
- LoCoMo (long conversation): evolved a hybrid memory combining vector retrieval with relational tables, offering both semantic and structured querying.
- HealthBench (medical QA): evolved structured information extraction plus field matching — extracting key entities and attributes from dialogue and comparing by field.
These differences mean a universal memory architecture cannot satisfy all needs. The paper's authors (Microsoft and City University of Hong Kong) explicitly note: "a memory system optimized for one purpose often cannot serve other purposes." This fundamentally questions the feasibility of finding a single "universal" memory architecture.
The M* Method: Letting AI Evolve Its Own Memory Code
M* addresses this through executable program evolution, automatically discovering memory architectures optimized for specific tasks (a "Memory Harness"). The core idea: don't have humans design memory systems — let the AI write and optimize the memory management code itself.
Specifically, M* models the memory system as a Python program encapsulating:
M* optimizes this program via Reflective Code Evolution: using a population-based search strategy, candidate memory programs are evaluated on training tasks, their failure cases are analyzed, and a large model acts as a "reflector" proposing improvements. The code is iteratively modified and re-tested.
After multiple evolution rounds, each task automatically evolved a structurally distinct memory program:
Experimental Results: The Power of Task-Customized Memory
M* was evaluated on four benchmarks spanning dialogue, planning, and reasoning: LoCoMo (long conversation), ALFWorld (household planning), HealthBench (medical QA), and PRBench (expert reasoning). M* beat all fixed memory baselines in 7 of 8 configurations, including those carefully designed by humans. Notably, M* used no domain-specific prior knowledge during evolution — it was simply asked to "write a memory management program," then found the optimal solution through reflection and iteration.
| Approach | Winning configurations (out of 8) | |---|---| | M* (task-customized evolution) | 7 | | Fixed memory baselines | 1 |
The evolved memory programs exhibited "structurally different processing mechanisms in every domain," showing that specializing memory for a given task can explore a broader design space and outperform generic paradigms.
Implications: Universal Memory Is a False Premise
M*'s real value is the fact it reveals: a universal memory architecture is a false premise. Different tasks have different optimal memory solutions, and seeking one "universal" memory system is futile. The good news: humans don't need to design each one — AI can find them automatically through code evolution.
For anyone building LLM agents, the takeaway is: rather than agonizing over "which vector database to use," first ask "what kind of memory structure does my task actually need." M* provides an automated answer: let agents evolve their own memory architecture based on task requirements, rather than applying fixed templates. This task-driven adaptive memory paradigm may become the new direction for LLM memory system design.