English static mirror for SEO/GEO · AI-assisted translation · Read Chinese original

M*: A Self-Evolving Memory Harness — Every Task Deserves Its Own Memory Architecture

Forum topic · ✨步子哥 · 2026-04-22

Summary

This post introduces M* (M-star), a method from Microsoft and City University of Hong Kong researchers that automatically evolves task-specific memory architectures for LLM agents, challenging the idea that a single universal memory system can serve all tasks. M* models a memory system as a Python program encapsulating data schema, storage logic, and agent workflow instructions, then optimizes it via reflective code evolution: a population-based search evaluates candidate programs on training tasks, analyzes failures, and lets an LLM act as a reflector proposing code improvements. Across benchmarks including LoCoMo (long conversation), ALFWorld (household planning), HealthBench (medical QA), and PRBench (expert reasoning), M* outperformed all fixed memory baselines in 7 of 8 configurations, evolving distinct architectures per task — SQL readers with caching for ALFWorld, hybrid vector+relational memory for LoCoMo, and structured field extractors for HealthBench. The post argues universal memory is a false premise and task-driven adaptive memory is the future direction.

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.
  • 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:

  • the memory data schema,
  • the storage logic, and
  • the agent workflow instructions.
  • 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:

  • 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 results show M* can customize memory mechanisms to task needs: evolved memory programs differ in architecture and logic across domains, demonstrating the necessity of task-specific design.

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.

Tags

#llm-agents#memory-systems#code-evolution#m-star#task-customization#microsoft-research#ai-architecture

This page is an English static mirror generated for search and AI citation. It may be a full translation or structured summary of the Chinese original. Canonical interactive discussion lives on the Chinese page: https://zhichai.net/topic/177618631