Huawei Equips Agents with Transferable Memory

Huawei’s Noah’s Ark Lab recently open-sourced MindMemOS, an attempt to add a portable, self-evolving memory operations layer to AI agents. The project is released under the MIT License. Developers can deploy it locally or access it through cloud services, an SDK, or a CLI.

This is not just another “long-term memory” project that wraps chat logs in a vector database.

What makes MindMemOS more noteworthy is that it decouples memory from specific agents and application frameworks: the same user, project, or organizational memory can be accessed by different agents; the system stores not only current facts but also how those facts change over time; and user corrections no longer remain confined to the current conversation, but can instead be used to adjust both the memories themselves and the strategies used to extract them.

In other words, Huawei is not trying to build a larger agent cache, but a layer of memory middleware positioned between models, agent frameworks, and storage systems.

What Agents Lack Is Not Storage, but “Memory Governance”

Most agents today can remember things, but their memories generally suffer from four problems.

First, memory is locked inside a single application.

A customer service agent may remember the status of a customer’s refund, only for the sales agent to ask about it all over again. A coding agent may have already encountered a problem with a particular dependency version, but after switching to another framework, that failed experience disappears along with the context. The underlying data may still exist, but because the data structures, retrieval interfaces, and scopes are incompatible, the practical result is still close to amnesia.

Second, different tasks define “what is worth remembering” in completely different ways.

A personal assistant cares about user preferences, schedules, and relationships; a coding agent cares about repository structure, build commands, and historical errors; an automated algorithm design system needs to record candidate solutions, evaluation results, and reasons for failure. Uniformly chunking and vectorizing every conversation, then retrieving content by similarity, usually produces nothing more than an ever-growing semantic junkyard.

Third, the memory system itself does not grow.

Many solutions define prompts and extraction rules at launch and then leave them largely unchanged. Even if the system repeatedly misclassifies a temporary arrangement as a long-term preference, it will not automatically revise its memory strategy. A user may correct it once, only for it to make the same mistake again next time.

Fourth, time is often flattened.

For example, a user may first say, “I live in Shenzhen,” then move to Shanghai six months later. The agent needs to know that the user’s current city is Shanghai, while also understanding that the relevant address was in Shenzhen when handling an older order. Simply overwriting the old information loses history, while storing both records side by side may create conflicts during retrieval.

These are precisely the problems MindMemOS is designed to address. Its core premise is that agent memory requires more than writing and searching: it also needs schema definition, version tracking, conflict resolution, feedback-driven updates, and lifecycle management.

Entities, Attributes, and Time: Storing More Than Just the Latest Answer

MindMemOS organizes memories along three dimensions: entities, attributes, and time.

It can be understood as a state table with version history:

• Entity answers “who or what does this memory belong to?”—for example, a user, project, customer, device, or algorithmic task;
• Attribute answers “what aspect of the entity has the system remembered?”—for example, location, dietary preferences, dependency version, or task progress;
• Time answers “when did this state take effect, and when was it superseded?”

This is very different from merely storing a natural-language summary.

Suppose a user preferred hot lattes in 2025 but switched to iced Americanos in 2026. Ordinary vector retrieval might return both similar records and leave the large model to guess on the fly which one is newer. MindMemOS instead aims to explicitly mark the currently valid state and its chain of evolution, allowing the agent to produce different answers to “What do they drink now?” and “What did they usually drink last year?”

Temporal modeling is also a lesson that agents must learn as they move from chatbots into business workflows. Order statuses, contract versions, account owners, code dependencies, and device configurations are constantly changing. In these scenarios, old information is not merely noise; it may be evidence required for auditing, accountability, and postmortems.

Of course, this design also brings greater engineering complexity. Entity disambiguation, attribute normalization, temporal boundary detection, and conflict merging can all go wrong. If “Manager Zhang,” “Old Zhang,” and “Zhang Ming” in the contact list are not recognized as the same entity, even a complete timeline will amount to nothing more than three unrelated sets of records.

MindSchema: Define What Should Be Remembered First, Then Let the Strategy Evolve

MindMemOS introduces MindSchema to describe domain-specific memory schemas and extraction rules.

It addresses a question that RAG solutions have long avoided: not every piece of information that appears is worth turning into long-term memory.

In enterprise customer service, order numbers, reasons for complaints, and promised completion times are worth retaining; pleasantries generated by the model to defuse tension usually are not. For coding agents, a verified build command is valuable, while a repair suggestion generated once but never executed should not be written directly into long-term experience.

MindSchema allows developers to define these areas of focus in advance. For teams that have already accumulated labeled question-answer and task data, the system can also evolve extraction strategies offline around a given task, rather than relying forever on the first manually created template.

This makes MindMemOS closer to a production system than simply “automatically summarizing every chat log.” The primary capability of a genuinely useful memory layer is not storing as much as possible, but refusing to store information that is unreliable, irrelevant, or lacks lasting value.

However, a schema can also become a new point of lock-in. When business requirements change, can old fields be migrated smoothly? How should different schemas be reconciled when multiple agents use them for the same entity? These questions are harder than designing an elegant data structure, and they will be critical to whether the project can ultimately be adopted by large organizations.

Feedback and Dreaming: Memory Can Be Corrected, and It Also Needs to “Sleep”

MindMemOS includes two particularly distinctive mechanisms: Feedback and Dreaming.

Feedback is used to extract corrective signals from user interactions. For example, suppose an agent recommends a hotel based on an old memory, and the user replies, “I don’t want to stay at this hotel on future business trips.” This is not only a new preference; it also challenges the reliability of the previous memory. The system can then reinforce, downgrade, or update related memories so that future retrieval better reflects the user’s actual intent.

The key is to do so “selectively.”

If any contradiction could directly overwrite long-term memory, an attacker might be able to poison an enterprise agent’s knowledge and behavior with just a few crafted conversations. Feedback mechanisms must simultaneously account for identity, permissions, strength of evidence, frequency, and scope of impact. A single statement from an ordinary visitor clearly should not be able to directly modify organization-wide memory.

Dreaming takes place offline. The name borrows from the analogy of memory consolidation during human sleep. In practice, its tasks include organizing fragments, merging duplicates, identifying conflicts, updating confidence levels, and further distilling task trajectories into reusable experience.

Online requests demand low latency and are not suitable for large-scale global reorganization. Moving computation-heavy work to an offline stage is a reasonable engineering trade-off. It is similar to database compaction, offline index construction in search engines, and periodic data cleansing in data warehouses.

However, “letting the system dream” sounds more romantic than the actual implementation. If the offline model makes a bad judgment, it may contaminate large numbers of related memories all at once. Dreaming therefore cannot simply involve asking a large model to rewrite summaries; it also requires version snapshots, change audits, rollback mechanisms, and evaluation thresholds. In high-risk domains such as healthcare, finance, and government services, automatic consolidation may even need to retain a human approval step.

From Remembering Facts to Distilling Skills

Another direction pursued by MindMemOS is to allow memory and skills to evolve together.

Factual memory answers “what happened,” while a skill answers “what should be done next time.” For example, if a coding agent remembers the log from a failed build, it has merely preserved the experience. Only when it further concludes that “this repository must undergo a compatibility check before dependencies are upgraded,” and consistently follows that rule in subsequent tasks, has it formed a reusable skill.

The project has already been used in the automated algorithm design platform LLM4AD NEXT. Tasks of this kind require continuously generating candidate algorithms, running evaluations, comparing results, and iterating. Without long-term memory, a model can easily repeat approaches that have already failed; after switching tasks, the design experience accumulated during the previous search also disappears with the context.

MindMemOS’s role here is to turn the trajectories and feedback produced during algorithmic search into retrievable assets. Successful solutions can be reused, while failed solutions become boundary conditions that reduce fruitless exploration in the next search cycle.

This is a more compelling scenario than remembering personal preferences. User preferences usually require only a small number of structured fields, whereas algorithm design, software development, and long-term research tasks genuinely require experience to accumulate across rounds and tasks. If MindMemOS can consistently reduce the cost of repeated trial and error in these tasks, its value will extend beyond merely making chatbots appear to “understand you” better.

Deployment Is Not Lightweight, and This Is Not Just a Small Python Plugin

Based on the publicly available deployment information, the complete form of MindMemOS is a service-oriented system rather than an in-memory dictionary embedded in an agent.

Its core dependencies include:

• Qdrant for vector retrieval;
• Neo4j for representing entities and relationships;
• Kafka for asynchronous events and data flows;
• Optional ClickHouse, OpenTelemetry, and Grafana components for analytics, tracing, and monitoring.

Local development commands provided in community materials include:

# Start core dependencies such as Qdrant, Neo4j, and Kafka
make dev-core

# Start ClickHouse, OTel, and Grafana in addition to the core dependencies
make db-observability

# Stop the local development environment
make dev-down

This technology stack indicates that MindMemOS is designed for agent systems that must run continuously and support observability and scaling. It may be clearly overbuilt for personal projects; for teams running multiple agents that need to share memory across applications, however, an independent service of this kind makes sense.

Nor should the “OS” in its name be interpreted literally as a traditional operating system. More accurately, MindMemOS is a control plane and operational layer for memory: it connects upward to agents and models, downward to vector databases, graph databases, and event systems, and provides relatively unified capabilities for writing, retrieving, updating, and organizing memory.

How Is It Different From RAG, MemOS, and mem0?

The agent memory space is already crowded.

Traditional RAG is better suited to finding information in relatively stable document repositories, focusing on the question, “Where is the content relevant to this query?” Long-term memory must also answer: “Who said it? When was it valid? Is it still valid now? Can it be modified? Who should be able to see it?” RAG can therefore serve as the retrieval component of a memory system, but it is difficult for it to handle complete memory governance on its own.

Lightweight solutions such as mem0 emphasize rapid integration and automatic extraction, making them suitable for adding user-preference memory to chat applications. Their advantage is simplicity; the trade-off is that developers generally still need to build additional engineering support for complex temporal relationships, cross-agent portability, and strategy evolution.

MemOS, meanwhile, places greater emphasis on managing multiple forms of memory, bringing plaintext memory, activation memory, and parametric memory under unified scheduling while focusing on coordination among the KV cache, model parameters, and external storage. By comparison, the currently available information on MindMemOS focuses more heavily on entity–attribute–time modeling, business schemas, feedback-driven correction, and offline evolution.

The two are not entirely competing answers to the same question. MemOS is more concerned with “where different forms of memory should reside and how they should be scheduled,” while MindMemOS places greater emphasis on “how external memory should be organized, corrected, and allowed to grow.” If they continue to develop, these two approaches will likely overlap in functionality.

The Direction Is Right, but “Self-Evolution” Is Not Yet a Solved Problem

MindMemOS’s most valuable insight is that memory should be treated as an independent asset rather than an auxiliary cache belonging to a particular agent.

When an enterprise simultaneously uses customer service, sales, coding, and data analysis agents, having each application maintain its own copy of user and project state not only duplicates effort but also creates factual conflicts. An independent memory layer can centralize data governance, permissions, and lifecycle management while reducing migration costs when changing models or agent frameworks.

But open-sourcing an architecture is not the same as solving every problem associated with long-term memory. At least four hurdles remain:

1. Independent evaluation: Beyond official metrics, it is necessary to examine incorrect write rates, conflict rates, retrieval latency, and token costs in real-world, long-running tasks;
2. Security and privacy: Sharing memory across agents amplifies the risk of data leakage. Fine-grained permissions, tenant isolation, the right to deletion, and auditing must be first-class capabilities;
3. Memory poisoning: Feedback-driven evolution mechanisms may be exploited by malicious inputs, requiring trusted identities, provenance tracking, and change rollback;
4. Forgetting mechanisms: Not every memory should be retained permanently. Expired, low-confidence, and low-value information must decay or be deleted; otherwise, the system will still succumb to information bloat.

The term “self-evolution” warrants particular caution. Allowing the system to automatically improve extraction rules and skills is certainly a step beyond fixed prompts. But as long as this evolution depends on judgments made by large models, hallucinations, bias, and compounding errors cannot be avoided. What enterprises truly need is not an agent that is always confidently learning, but one that knows what it can learn automatically and what must wait for confirmation.

The Next Competition Among Agents Will Be About Who Can Accumulate Experience

As the capabilities of large models increasingly converge, the differences between agent products will no longer be determined solely by the underlying models.

Given access to the same model, an agent that knows a project’s current state, remembers what has failed before, understands how users have corrected it, and can distill successful trajectories into skills will significantly outperform a competitor that starts from a blank context every time over the long term.

This is the layer MindMemOS is betting on: making memory portable across agents, preserving the temporal trajectories of facts, allowing feedback to alter memory, and then using task experience to drive skill evolution.

This direction is useful and sufficiently pragmatic. It does not attempt to solve every problem by endlessly expanding the context window. Instead, it acknowledges that memory must be filtered, structured, updated, and governed. A larger context window is like a wider desk; what MindMemOS wants to build is a filing system, version control, and an experience manual.

As of August 3, MindMemOS remains at an early stage, undergoing developer scrutiny following its open-source release. It is worth testing for teams planning to build long-running agents. For projects that only provide one-off question answering or simple workflows, directly deploying the entire service stack may cost more than it is worth.

Whether it can become a truly general-purpose memory operations layer will ultimately depend not on how novel the concept is, but on three more prosaic questions: Can it reduce the number of incorrect memories? Can it forget when it should? And after switching to another agent, can the experience accumulated in the past still genuinely be used?

References

• MindMemOS GitHub repository search: For finding the project’s code, license, deployment documentation, and subsequent version updates.
• Zhihu: Introduction to MindMemOS Features and Deployment: Introduces cross-agent memory, skill evolution, core dependencies, and local startup procedures.
• MemOS open-source repository: For comparison with another approach to an agent memory operating system and its ideas for managing multiple forms of memory.