Moving beyond passive RAG: How to implement active memory reconstruction for AI agents

brain-inspired AI agent memory

This article is part of our coverage of the latest in AI research.

AI agents struggle to reason over long-term conversational histories because of limited context windows and rigid memory retrieval pipelines that create noise in the context. 

To solve this, researchers at the National University of Singapore developed MRAgent, a framework that replaces the static “retrieve-then-reason” with an active memory reconstruction mechanism. MRAgent integrates the memory reconstruction into the LLM’s reasoning process and enables the agent to gradually develop its memory based on accumulating evidence and experience. 

Experiments show that MRAgent is highly accurate and resource-efficient for real-world applications. It achieves up to a 23% performance improvement on complex reasoning tasks. It also drastically reduces prompt token consumption (dropping from 632k to 118k) and runtime costs, paving the way for more reliable and context-aware AI agents that can scale to use cases with long-term interactions.

The limits of passive retrieval

The classic passive retrieval pipeline poses several limitations for agentic applications. In these systems, documents are retrieved through methods like vector search or graph traversal and then passed on to an LLM for reasoning. Passive retrieval fails because it separates reasoning from memory access, which creates major bottlenecks when scaling to enterprise use cases.

“The main limitation we see in current passive retrieval or flat vector memory architectures is that they treat memory access as a one-shot matching problem,” explains Shuo Ji, first author of the paper, in comments provided to TechTalks.

This works reasonably well when the user query is semantically close to the relevant document. However, in long-running enterprise settings, useful evidence is often distributed across many interactions, policies, tickets, and decisions. A single embedding search may retrieve what looks similar to the current query, but miss the intermediate facts needed to connect different pieces of evidence. 

As memory grows, Ji notes that this creates two practical problems: “token cost increases because systems retrieve too much context, and reasoning quality drops because the model receives many partially relevant or conflicting snippets.”

Furthermore, current systems rely heavily on pre-constructed structures and static relevance functions. For example, if a system’s graph is explicitly built to connect “people” with “events,” it will fail to answer a spontaneous question about a person’s “location” unless that specific structural link was pre-mapped. This limits the flexibility required to scale across unpredictable, long-horizon user interactions.

Passive retrieval vs active memory reconstruction
Passive retrieval vs active memory reconstruction (source: arXiv)

The researchers believe that to overcome these limitations, developers must shift toward an “active and associative reconstruction process,” a concept inspired by cognitive neuroscience. In this paradigm, memory recall unfolds sequentially instead of a passive read-out of a static database. 

The system starts with small, specific triggers from the user’s prompt, like a person’s name, an action, or a place. These initial hints do not point directly to massive blocks of text. Instead, they point to connecting concepts or categories, which the paper calls “tags” or “engrams.” You can think of these as index cards or metadata that tell the system where to look next. By following these tags, the agent gradually gathers evidence and uses each new piece of information to guide its next step until it has successfully pieced together the full, accurate story.

Adopting this dynamic paradigm introduces two fundamental engineering challenges:

– Developers must transform memory access from one-shot retrieval into a multi-step, adaptive process that progressively reveals new information across reasoning steps.

– Developers must design the memory database to enable the LLM to efficiently navigate associative items and prune irrelevant paths without exploding compute costs.

How MRAgent structures and navigates memory

MRAgent (short for Memory Reasoning Architecture for LLM Agents) treats memory as an interactive environment. The agent uses the LLM’s reasoning abilities to maintain an active “reconstruction state” and iteratively query the memory graph. When processing a complex query, the agent explores multiple candidate retrieval paths across a structured memory graph. 

At each step, the LLM evaluates the intermediate evidence it has gathered and uses it to revise its search. The agent infers new search constraints, pursues the paths with the best information, and prunes irrelevant branches. This allows MRAgent to adjust its trajectory to piece together deeply buried information without filling the LLM’s context with noise.

To make this active exploration computationally efficient and scalable, the framework organizes its database using a “Cue-Tag-Content” mechanism that acts as a multi-layered associative graph:

Cues are fine-grained keywords, such as entities or contextual attributes extracted from user interactions.

Content is the stored memory units, divided into multi-granular layers like “episodic memory” for concrete events and “semantic memory” for stable facts and user preferences.

Tags are critical semantic bridges that summarize the relational associations between specific Cues and Content.

MRAgent is inspired by human memory reconstruction
MRAgent is inspired by human memory reconstruction (source: arXiv)

This structure is used in a two-stage retrieval process. The LLM first navigates from Cues to candidate Tags. Because Tags reveal the semantic relationships and structural associations of the data, the agent can use these short summaries to judge relevance. The LLM can then identify promising traversal paths and discard irrelevant branches before spending compute and prompt tokens to access the detailed, heavy memory contents.

To see how this works in practice, consider a concrete enterprise use case: a customer success agent that needs to answer, “Why was this customer promised a different renewal price, and should we honor it?” 

The answer may require reconstructing a causal chain across a support conversation, a sales exception, a contract clause, a billing-system update, and a later internal note. Traditional similarity-based RAG might retrieve the most recent billing document or the most semantically similar support ticket, but fail to connect the causal chain. 

With MRAgent’s active reconstruction, the agent can extract cues like the customer’s name, follow associative tags to the original support ticket, retrieve the sales exception, and link it to the billing update. It navigates these semantic relationships, prunes irrelevant branches, and iteratively stops once it has enough evidence to answer the query.

“During inference, the agent can iteratively explore and prune memory paths based on what it has already discovered,” Ji said. “This allows retrieval to adapt to the reasoning process, rather than being fixed before reasoning begins.”

MRAgent architecture
MRAgent architecture (source: arXiv)

Evaluating MRAgent against industry benchmarks

MRAgent enters a space with several existing frameworks for agentic memory. Other notable approaches include A-MEM, a graph-based agentic memory framework; MemoryOS, a hierarchical memory framework; and persistent memory frameworks like LangMem and Mem0.

However, MRAgent is largely orthogonal to these systems. “Systems such as Mem0 focus strongly on production-ready memory tracking and state management, while other approaches… focus on what to store,” Ji said. “MRAgent focuses on how memory should be accessed at inference time. Its main contribution is not simply a new storage format, but an active reconstruction process that lets the agent decide where to look next based on intermediate evidence.” 

Rather than replacing existing memory systems, MRAgent can potentially be layered on top of them to improve reasoning-time memory access.

The researchers tested MRAgent on two industry benchmarks, LoCoMo and LongMemEval. These datasets evaluate the abilities of agents to resolve queries on long-horizon tasks and conversations spanning dozens of sessions and hundreds of dialogue turns. Using Gemini 2.5 Flash and Claude Sonnet 4.5 as the backbone models, they tested MRAgent against the standard RAG approach, A-MEM, MemoryOS, LangMem, and Mem0.

MRAgent consistently outperformed the baselines across both models and all question types by a significant margin. 

MRAgent performance
MRAgent performance on different benchmark (source: arXiv)

For practitioners, the most critical metric is often computational cost. Because MRAgent defers complex relational mapping to the retrieval stage, it avoids the massive upfront processing costs of existing systems. In the LongMemEval tests, MRAgent slashed prompt token consumption to just 118k per sample. By comparison, A-Mem consumed 632k tokens, and LangMem burned through 3.26 million tokens per query. MRAgent also effectively halved the runtime compared to A-Mem, dropping from 1,122 seconds to 586 seconds.

What makes MRAgent so efficient in practice is its “on-demand” behavior. Evaluating tags and pruning irrelevant paths before retrieval saves money and context space. Furthermore, the system evaluates its own accumulated context and detects when to stop searching to avoid redundant data exploration.

Implementing MRAgent in production pipelines

Given the trade-offs between retrieval depth and token efficiency, engineering teams must evaluate when to deploy active reconstruction versus traditional vector search. 

Ji gives a “green light” for active reconstruction when three conditions hold: “First, the task requires multi-hop or temporal reasoning over long histories. Second, the relevant evidence is sparse and distributed, so simply expanding the context window becomes expensive and noisy. Third, the system needs to justify its answer by tracing which memories or records were used.”

On the other hand, traditional vector search remains a better choice “when the task is simple lookup, FAQ retrieval, semantic search over static documents, or when latency and implementation simplicity are more important than deep reasoning over memory.”

While MRAgent is highly effective, the Cue-Tag-Content structure needs to be prepared before the agent can query it. 

The authors designed MRAgent with an automated distillation pipeline that uses LLMs to process raw interaction histories and automatically populate the memory graph. The authors emphasize that this is a “lightweight construction phase.” By deferring complex, query-specific relational reasoning to the retrieval stage, developers save significantly on upfront ingestion costs and database complexity. 

However, teams should manage their expectations regarding production readiness. “We currently see the Cue–Tag–Content graph as a research memory-access layer rather than a plug-and-play enterprise product,” said Ji. While the design is conceptually compatible with existing enterprise data infrastructure, there are no pre-built adapters for specific CRM or ticketing systems. “In practice, engineers would still need to adapt the ingestion and graph-construction steps to their own data schemas, access-control rules, and observability requirements.”

For teams looking to explore the methodology, the MRAgent code is open source and available on GitHub.

As enterprise agents transform from isolated task-runners into long-lived digital employees, memory infrastructure will need to evolve. “Memory will not just be a database behind the agent,” Ji said. “It will become a governed reasoning substrate that determines what the agent remembers, how it reconstructs context, and how reliably it can act over time.”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.