MIRIX-2.0: Multi-Agent Memory System: what it means for business leaders

MIRIX-2.0 is an open-source memory system for LLM agents that keeps every record intact, indexes it with a citation-carrying hypergraph, and consolidates offline without rewriting anything stored.

1. What the method is

MIRIX-2.0 is a long-term memory system for LLM agents built in two layers. Six typed memory agents (core, episodic, semantic, procedural, resource and knowledge vault), routed by a manager agent, write complete records into a vector database that is the system of record. On top sits a hypergraph that is only an index: it stores entities as anchors and facts as n-ary frames, so a flight is one frame with traveller, origin, destination and carrier rather than several disconnected triples, and every frame cites the rows it came from. Retrieval enters through the graph under fixed budgets, and the answering model receives graph facts together with their source records. A background process, AutoDream, merges duplicate entity anchors without touching stored records and distills finished task sessions into reusable skills. Nothing is fine-tuned, it runs with closed and open models, and the code is public.

2. Why the method was developed

The authors argue a memory worth deploying must be accurate on particulars, practical to run, and bounded in cost, and that each existing family gives up one. Systems that consolidate conversations into extracted facts are compact, but the details they discard are gone for good. Systems that keep everything search an ever larger and noisier history. Graph memories built on binary triples split a multi-party fact into fragments. Hypergraph and file-based memories that descend from summaries can only reach a detail its summary happens to mention. Memories stored in model weights need training and rule out closed models. The paper also notes that the two uses of memory pull in opposite directions: remembering a user requires broad, connected recall, while remembering how to do a task requires a small, refined set of procedures, and retrieving too much distracts the agent. MIRIX-2.0 is an attempt to serve both from one store.

3. Who should care

Product and engineering teams building assistants or agents that work across sessions are the direct audience, because this is a candidate replacement for the memory layer they already run or are about to buy. Platform and infrastructure owners should note where the cost lands: graph construction moves work into ingestion, so write-heavy workloads pay more upfront and answer-heavy workloads benefit. Risk, audit and support functions should care about the traceability, since every graph fact handed to the model cites the stored rows behind it and consolidation cannot delete or rewrite a record, which makes an answer easier to explain after the fact. Teams running task agents in operations or commerce should look at the procedural side, where skills are distilled from past sessions and each edit can be traced to quoted transcripts. Procurement should weigh that the authors are affiliated with the company behind the product.

4. How the method works

On write, the record is committed to the vector database first, then an extractor turns episodic and semantic records into frames; a failed graph write never rolls back a stored memory. Dates, prices and counts stay on the frame as literals, and an occurrence key keeps two similarly worded undated events apart. A language model decides whether a new name matches an existing anchor, but only among candidates that nearest-neighbour search proposes. On read, a deterministic planner classifies the question into one of five operators and sets budgets, from 6 base rows and 4 cited rows for a lookup to 8 and 12 for a count. Retrieval recalls fifteen anchors, scores at most 240 candidate frames, and fuses the cited rows with the base rows. The answering agent may retrieve up to five times, and a rule-based check triggers one more search and rewrite when the draft looks unsupported. AutoDream runs outside the write path, verifies candidate merges under pair caps and caches rejections.

5. How it was evaluated

User memory was tested on conversational recall with LoCoMo (1,540 non-adversarial questions) and LongMemEval-S, on three document question-answering tasks from MemoryAgentBench, and on personalized review writing with MemoryCD for 100 users. Baselines were mem0, A-Mem, MemoryBank, Graphiti and HyperMem, plus long-context and retrieval baselines for personalization. Answers came from gpt-4.1-mini at temperature zero, with a gpt-4o-mini judge voting three times on the conversational sets. Three configurations separate the parts: flat vector memory, graph added, and graph plus AutoDream. Procedural memory was tested on ALFWorld and WebShop against ReasoningBank and Agent Workflow Memory, learning from 39 and 40 training tasks and then frozen for 134 and 140 held-out tasks over three runs, and on the 346-question MetaClaw-Bench Part I. The document tasks and every timing used the configuration without AutoDream, and the MetaClaw GPT-5.2 baselines are that paper's published figures rather than reruns.

6. How it performed

The full system scored 91.4% on LoCoMo against 91.0% for HyperMem in the authors' own run (HyperMem reports 92.7% for itself), and 72.6% on LongMemEval-S, 14.3 points ahead. The graph added 2.7 and 11.2 points over flat memory and AutoDream a further 3.0 and 2.6. Without AutoDream it reached 83.0% and 71.0% on single-hop and multi-hop document questions, 31.0 and 22.0 points above HyperMem, but trailed two baselines on DetectiveQA. As procedural memory it reached 76.4% on ALFWorld against 73.6% for the next method, with a 6.2-point standard deviation over three runs, and 37.4% on WebShop. It answered faster than HyperMem on all five timed benchmarks, yet document ingestion was 3.8 to 4.0 times slower than flat memory, the full system was never timed, and merge precision was not measured. Our call: pilot it on one agent with long user histories, measuring ingestion cost and merge quality ourselves before committing. (Source: arXiv 2611.12068, 2026)