Proactive Memory Agent: The Agent's Second Brain

Why Qoder's memory moved from a fixed pipeline to an autonomous agent, and what changed when the model got to decide what to remember, when to recall it, and what to fix.

1. Background: the ceiling of the task-flow pipeline

Before the Memory Agent existed, memory was carried by a task-flow pipeline. The idea was to break "memory" into a handful of fixed steps on the main conversation path and run them in order, one after another.

Before answering the user, the system first reads the context to understand the user's primary, secondary, and hidden intents, then recalls relevant memories based on those intents. Once the conversation moves into execution, it uses the recalled memories to do the task better and faster and to make the output fit the user's preferences, and it can call tools along the way to pull in more memory. After the task finishes, the system runs an effectiveness evaluation on the memory it used: was it actually used, and did it help or hurt the task? It then extracts reusable user preferences, project info, development conventions, lessons learned, and skills from the conversation. Extracted memories go through a quality check, and only the ones that clear the bar are kept. Finally, the system checks whether a new memory conflicts with an existing one, and merges or corrects it if it does, so the store stays consistent.

Task-flow memory pipeline running intent recognition, pre-recall, conversation, effectiveness evaluation, memory extraction, quality check, and conflict handling in sequence.

This design wins on being simple to engineer, easy to trace, and reliable. But it also exposed a few fatal flaws.

1. Synchronous blocking makes responses slow

Every conversation has to finish intent recognition and pre-recall before anything else happens, and that whole stretch blocks the main task. Because it involves model calls and non-trivial recall logic, the user feels a real lag. That hurts the experience.

2. Low recall initiative means low memory participation

Pre-recall only pulls a limited set of memories. The rest have to be fetched dynamically during execution, based on context. In practice we found that even with explicit instructions on when to use them, the model rarely takes the initiative to call memory tools and recall on its own.

3. Weak recall means low memory hit rate

The recall path was implemented in engineering logic with a fixed search route. It could not adjust strategy based on an overview and what it already knew, could not widen the search, and could not dig into deeper memories. The results were often only semantically related, not necessarily usable in the current context, because the path had no way to judge whether a memory was actually applicable.

4. Fragmented context means weak reflection

After a task ends, the system still has to run effectiveness evaluation, memory extraction, conflict detection, and so on. In the task-flow pipeline these are separate, isolated steps. They can't see the full context, and they can't call a tool to fill in missing information when they need it. The result: reusable memory doesn't get fully extracted, memory quality doesn't really improve, and broken memories don't get cleaned up properly. The whole thing underperforms.

2. The Proactive Memory Agent

The core idea behind the Memory Agent is to take "memory" from a set of fixed steps and turn it into an agent that makes its own decisions, letting the model answer three questions for itself:

What's worth remembering? When should it be recalled? What got remembered wrong and needs fixing?

Following the memory lifecycle, we split the Memory Agent into a Recall Agent and a Reflection Agent.

Memory Agent architecture, with the Recall Agent handling attention monitoring and proactive recall, and the Reflection Agent handling evaluation, extraction, and anomaly handling

Recall Agent

It continuously monitors the main agent's execution, including key events like task creation, task planning, to-dos, tool failures, task completion, and task failure, and quickly identifies the attention signal, the topic, constraints, and intent the current task actually cares about.

The monitor outputs a structured attention list that holds the background, the memory use case, and what needs to be recalled. If the attention is already known, or a new attention's score doesn't beat the historical high, nothing new needs attention, so it short-circuits and skips the downstream cost.

Based on the attention list and a memory overview, it calls the recall tools to do the recall. Each round of recall has to answer:

What is the main agent focused on right now?
Which memories do we already know?
Are the known memories enough to answer what's in focus?

If memory is sufficient or there's nothing more to pull, recall ends. Otherwise it combines several recall tools:

Direct Fetch: get a target memory straight from its title;
Shallow Recall: a fast scan of semantically related memories;
Deep Recall: a wider, more thorough scan;
Topic Exploration: when the memory store is especially large, walk the topic tree level by level for more precise, deeper discovery.

Recall results are proactively injected into the main agent. On its next model request, the main agent carries the latest recall results, which are also marked "known" so the same memory doesn't get injected twice.

Reflection Agent

It kicks in after a conversation ends or fails, and handles reflecting on, optimizing, and tidying up memory. It does three things.

1. Effectiveness evaluation and optimization

It evaluates the memories used in this conversation: did they actually feed into the task, and was the effect positive or negative? For memories that were useless or negative, it digs into why, whether the content itself is wrong or the use case didn't match, then optimizes accordingly: it adjusts the memory's title, keywords, use case, and content, and updates the recall index to make later recall more accurate and efficient.

2. Memory extraction

It checks whether anything in this conversation is worth keeping:

Preference extraction: capture user preferences, project info, and development conventions;
Lessons learned extraction: remember the traps you hit and how you solved them; record the important decisions the user made when there was disagreement; summarize the task goal, the process, the relevant files, and an overview;
Skill extraction: distill the user's guidance, corrections, and complex standardized workflows into skills that guide future tasks.

Extraction references existing memory so it doesn't create duplicates.

3. Anomaly detection and handling

It checks for redundant or conflicting memories and merges or corrects the anomalies to keep memory consistent.

Throughout reflection, the agent keeps pulling relevant information through recall tools and makes its adjustments through update tools. To cut cost and support a self-evolving Memory Agent, the rules use a resource-based design that supports dynamic loading. For example, the anomaly-handling rules only load when an anomalous memory is detected, and stay unloaded when none is found.

3. Evaluation

We ran an offline evaluation set comparing the task-flow pipeline against the Memory Agent across the three core stages of memory: generation, recall, and curation. The Memory Agent posted a clear lift in pass rate at every stage.

Evaluation comparison showing the Memory Agent beating the task-flow pipeline on memory generation, curation, and recall

Key takeaways:

Recall jumped the most: from 40% to 77%. This is the thing users feel most directly, "does the AI remember what I told it," and the success rate went from roughly four in ten to nearly eight in ten;
Curation roughly doubled: the Reflection Agent's anomaly detection surfaces and cleans up broken memories, which keeps the memory system consistent.

4. Closing

The bottleneck in the task-flow pipeline wasn't parameter tuning. It was the lack of a decision-maker. The pipeline assumes rules can enumerate every "remember this / fetch that" situation. But in real conversations, attention keeps shifting, and no static rule can keep up. The Memory Agent hands the decision back to the model, so the model can take the right action with the right tool at the right moment. That's exactly where the task-flow pipeline was weakest and least fixable. The Memory Agent marks the shift in memory from "passive execution" to "active recall and learning."

Community

Proactive Memory Agent: The Agent's Second Brain

Learn More about Qoder

Explore Qoder for Enterprise

1. Background: the ceiling of the task-flow pipeline

1. Synchronous blocking makes responses slow

2. Low recall initiative means low memory participation

3. Weak recall means low memory hit rate

4. Fragmented context means weak reflection

2. The Proactive Memory Agent

Recall Agent

Reflection Agent

3. Evaluation

4. Closing

Read previous post:

Read next post:

Alibaba Cloud Community

You may also like

Comments

Alibaba Cloud Community

Related Products

Token Plan

Alibaba Cloud Model Studio

Qwen

AI Acceleration Solution