Microsoft, Huawei Ship Rival AI Agent Memory Systems (2026)

TL;DR: Forty-eight hours apart, two very different labs shipped new answers to the same problem — AI agents that lose everything the moment a session ends.

Microsoft Research announced Memora on June 29, 2026: a peer-reviewed memory architecture, published at ICML 2026, that claims state-of-the-art results while cutting context tokens by up to 98%.¹ On July 1, Huawei's openJiuwen open-source community shipped JiuwenMemory, a four-layer memory stack with an unusual "Dreaming" consolidation cycle modeled on sleep research.²

Both target the same failure mode. Neither is a finished product, one carries a genuine legal caveat tied to its country of origin, and the whole agent-memory space has a documented habit of self-reported numbers not surviving independent testing.

In one line: Microsoft and Huawei each shipped a new AI agent memory architecture in the same week — Memora is peer-reviewed and lightly adopted, JiuwenMemory is architecturally ambitious but unverified and carries a China-law data caveat, and neither should be trusted on benchmark numbers alone.

What You'll Learn

• Why "agent memory" became its own engineering discipline in 2026, distinct from just expanding the context window
• What Microsoft's Memora actually does differently from RAG, Mem0, and knowledge-graph memory
• What Huawei's JiuwenMemory adds — including the one specific piece its open-source distribution doesn't document the way its launch announcement describes
• Why self-reported memory benchmarks (LoCoMo, LongMemEval) are a genuine credibility problem across this entire category, not just for these two projects
• The concrete legal condition attached to JiuwenMemory that has nothing to do with its code quality
• How to actually evaluate either project before betting a production agent on it

Why This Matters Now

Every large language model is, underneath the product experience, stateless. A conversation ends, the context window empties, and the next session starts from zero. For a chatbot that's an annoyance. For an agent expected to run a multi-week project, track a customer relationship, or accumulate expertise across hundreds of sessions, it's disqualifying. Microsoft Research's own framing of the problem: "every long conversation forces the model to re-read its entire history, and every new piece of information is either stored as raw text (fragmented and noisy) or compressed into a vague summary (precise details lost)."¹

The fix isn't simply a bigger context window — that scales cost linearly and still forces the model to re-read everything on every turn. The industry's answer has been a separate memory layer that sits outside the model: extract what matters from a conversation, store it durably, and retrieve only the relevant slice at the start of the next session. By 2026 this has become a crowded field with its own benchmark suite (LoCoMo, LongMemEval), its own vocabulary, and — as the two launches covered here make clear — its own credibility problems.

What Memora Does Differently

Memora's central move is to stop treating "what gets stored" and "how it gets found" as the same problem. Every memory entry has two parts: a primary abstraction, a six-to-eight-word phrase that captures what the memory is about, and the memory value, the full, un-compressed content. Only the primary abstraction gets embedded and indexed — the rich content underneath is never directly searched, so it never has to be compressed to be efficient.¹

On top of that, cue anchors — short, auto-generated tags pulled from the memory's own content — give a second, parallel way to find the same memory without a fixed schema.

Microsoft's own example: if a user says "Dave and Sarah agreed to push the prototype to April 1, the pilot to May 2, and the MVP to May 30," a knowledge-graph system would need predefined entity and relation types to represent that.

Memora instead creates one primary abstraction ("Updated Project Orion timeline agreed by Dave and Sarah") plus several cue anchors ("Dave Project Orion update," "Project Orion prototype schedule"). A later question about any piece of that sentence routes back to the same memory, without committing to an ontology up front.¹

Retrieval isn't single-shot either. A "policy-guided retriever" iteratively refines its own query, follows cue anchors to related-but-not-obviously-similar memories, and decides for itself when to stop — closer to how a person chases a half-remembered connection than to a single vector lookup.¹

On results: Microsoft reports 86.3% LLM-judge accuracy on LoCoMo (a benchmark with dialogues averaging 600 turns) and 87.4% on LongMemEval (115,000-token contexts), ahead of RAG, Mem0, Nemori, Zep, LangMem, and even feeding the model the full conversation history directly.¹

It does this while storing roughly half as many memory entries per conversation as Mem0 (344 vs. 651) and using up to 98% fewer context tokens than full-context inference.¹

The paper behind this — "Memora: A Harmonic Memory Representation Balancing Abstraction and Specificity"³ — is published at ICML 2026 according to Microsoft Research's own announcement, and the code is open on GitHub under the MIT license.¹⁴

As of this writing, three weeks after the blog post, that repository has 111 stars and 9 forks. Modest but real traction for a research release — and it still ships as a single initial commit with no tagged version, so treat it as research code rather than a stable dependency.⁴

What JiuwenMemory Does Differently

Huawei's openJiuwen community — an open-source AI agent platform effort, not a Huawei product division shipping directly — released JiuwenMemory two days later, on July 1.² The project's launch announcement brands the engine "AutoGenetic Memory" and leans on a gene-segment metaphor: memory should grow and reorganize itself the way genetic information replicates and adapts, rather than simply accumulate as an ever-larger pile of stored text.⁵

Architecturally it takes a different path than Memora's abstraction-plus-cue-anchor design. JiuwenMemory stratifies memory into four persistent layers: L0 stores raw conversation history verbatim as the foundation layer; L1 holds per-turn and incremental LLM-compressed summaries; L2 is structured memory — automatically extracted episodic memory (dated events and decisions) and semantic memory (durable background knowledge that daily chatter shouldn't overwrite),²⁵ plus a general-purpose variable type the schema supports but doesn't itself enumerate;⁶ L3 sits on top as the consolidated user-profile layer — durable affirmative/negative statements about who the user is, including relationships and assets,⁶ alongside concrete fields like name, timezone, and language²⁵ — the tier kept most immediately accessible at the start of every session.

The most distinctive piece is Dreaming — an optional background service, disabled by default, that periodically re-reads a user's stored sessions and distills durable knowledge from them on a schedule, rather than only in the moment a message arrives.⁶

The launch announcement frames it as a three-stage "sleep paradigm" modeled loosely on how human memory consolidates overnight. A lightweight "Light Sleep" pass does incremental screening of new session data. An "REM" stage has the LLM complete extraction and classification in a single pass.

A final "Deep Sleep" stage handles semantic deduplication and conflict resolution before writing to long-term memory.⁶⁵ If a user mentioned one database preference last week and a different one yesterday, this is the stage that decides which version is current.

Per the repository's own README, the incremental scan is checkpointed so it survives restarts, and starting the scheduler is idempotent per scope-and-user pair. Its writes take the same user-level lock as online extraction and reuse the same semantic conflict detection, so the two paths never collide or duplicate.⁶

A companion feature called MemoryTurbo addresses a real engineering tradeoff: if extraction only happens in the background, does retrieval have to wait for it? JiuwenMemory's answer is a mechanism the project's own README names Momentum Decoupling — a two-tier write path where new conversation turns land immediately in a searchable cache-layer vector store, while the heavier extraction pipeline runs asynchronously behind it based on priority and compute load. A smaller model first clusters conversations by topic so related turns get extracted as a group, which keeps the expensive LLM calls from being made once per turn.⁶

Here the project's own numbers don't agree with each other. The README states Momentum Decoupling cuts perceived user latency by 92%;⁶ the launch announcement and press coverage of that same launch both cite a lower 80% figure instead, alongside a further 50%-plus drop in token usage.⁵² Retrieval accuracy is said to hold up even while extraction is still pending, because the cache layer itself stays searchable.⁶ Neither number comes with a named third-party benchmark — both are developer-reported — and the fact that the project's own documentation and its own launch coverage can't agree on the percentage is a small, self-contained preview of the benchmark-credibility problem this piece gets to below.

Two further components round out the announced architecture.

Graph Memory turns conversations, documents, and structured content into a continuously evolving knowledge graph, so the agent can follow entity-and-relationship links rather than relying on semantic similarity alone — closer in spirit to Zep's Graphiti than to a flat vector store.

Episodes retain provenance back to the source, entities and relations hold the structured result, and the graph merges and updates as new conversations arrive.⁵ One real limit worth knowing before evaluating it: per the project's own architecture documentation, Graph Memory currently runs as an independent module and is not yet wired into the main LongTermMemory.add_messages pipeline — so using it today means calling it directly rather than getting it automatically alongside the rest of memory extraction.⁶

Swarm Memory extends the same idea across an agent team. Each agent accumulates its own memory while contributing shareable knowledge to an organization-level pool, so a newly added agent inherits accumulated domain knowledge instead of starting cold.⁵

Binding it all together is a deliberately non-committal adapter layer, split along two axes: a Plugin dimension facing agent platforms and a Provider dimension facing memory engines, with Mem0 shipping as an alternate provider alongside JiuwenMemory itself.⁵ The intent — memory as portable infrastructure rather than something locked to one framework — is conceptually adjacent to what MCP is trying to do for agent tooling more broadly, though the two solve it through entirely different mechanisms.

One caveat is worth flagging for anyone evaluating this today. The English README on the public GitHub repository documents Graph Memory and MemoryTurbo in real detail — both get their own features section, and Graph Memory has a linked, dedicated API doc.⁶ What it does not document as a named feature is Swarm Memory: the only related string in the current README is "JiuwenSwarm," listed as one of several agent platforms the plugin-dimension adapter can hook into — a plugin-compatibility mention, not a described memory capability.⁶

That's a narrower gap than "the announced architecture is largely undocumented" — most of what the launch post describes is genuinely in the public repository, Graph Memory and MemoryTurbo included. But it does mean a developer evaluating the GitHub distribution should confirm Swarm Memory specifically — rather than the whole feature list — before assuming it ships as described. The project's primary repository is hosted on GitCode rather than GitHub. One practical trap on either host: the GitHub repository defaults to the develop branch, and main still serves an older README documenting none of these features — read develop, not whatever main happens to return.⁶⁷

Memora vs. JiuwenMemory vs. the Field

For scale, the two incumbents both projects are implicitly competing against: Mem0 is the current community leader — its GitHub stars grew from roughly 47,800 in June 2026 to about 60,700 as of July 21⁸ — with a vector-plus-optional-graph design, while Zep's open-source Graphiti engine focuses on temporal, relationship-aware memory rather than raw adoption numbers. Neither comparison is apples-to-apples with Memora or JiuwenMemory: Mem0 and Zep are mature, widely-adopted products competing on production polish, while the two systems this piece covers are both barely three weeks old.

The Benchmark Credibility Problem

This is the part that should shape how you read every number in this piece, including Microsoft's. LoCoMo and LongMemEval have become the de facto benchmarks for agent memory the way MMLU became one for general model capability, and the same thing that happened to MMLU is happening here: everyone reports well on them.

Mem0 reports 92.5% on LoCoMo under the new memory algorithm it shipped in April 2026 — up from 71.4% under its previous algorithm — though Mem0's own README specifies that figure reflects its managed platform, adding that open-source users "should expect directionally similar gains but not identical numbers."⁹ Taken at face value, that 92.5% is already higher than Memora's own claimed 86.3%. The two are not quite like-for-like — Memora's paper went to arXiv in February 2026, before Mem0's April algorithm existed, so neither team was measuring against the other's current system — which is itself as good an illustration as any of why every number in this piece, including Microsoft's, needs the same scrutiny. EverMind's EverOS claims 93.05%.² JiuwenMemory claims a 15% relative improvement over an unpublished baseline.

Reporting on JiuwenMemory's numbers specifically, Tech Times cited a separate framework-comparison piece finding a 15-to-37-point gap between what memory frameworks self-report and what holds up under third-party verification.²

That figure comes from that third-party comparison, not from a test either Microsoft or Huawei's team ran on the other's system. Treat it as a signal about the category's track record, not a specific finding about Memora or JiuwenMemory.

The honest takeaway isn't that any one of these numbers is fabricated. Microsoft's paper went through peer review, which is a real if imperfect check that the JiuwenMemory numbers haven't had.

It's that a benchmark score published by the team that built the system, on a public leaderboard with no standardized harness, is a claim to be tested against your own workload — not a verdict to take at face value.

The China Data-Risk Question

This part of the story has nothing to do with code quality and everything to do with jurisdiction, and it deserves the same precision as the technical claims above rather than either alarmism or a shrug.

China's National Intelligence Law — adopted June 27, 2017 by the NPC Standing Committee and effective the following day per the law's own Article 32 — states in Article 7 that "all organizations and citizens shall support, assist, and cooperate with national intelligence efforts in accordance with law."¹⁰

That is a general legal obligation applying to Chinese organizations and citizens — Huawei among them, as a company headquartered in Shenzhen.

On June 30, 2020, the FCC's Public Safety and Homeland Security Bureau formally designated Huawei — jointly with ZTE, along with each company's parents, affiliates, and subsidiaries — as "covered companies" under the agency's national security rules.¹¹

The Commission's November 2019 proposal to cover both companies cited their "substantial ties to the Chinese government" and "Chinese law requiring them to assist in espionage activities." The Bureau based its final designations on "the totality of evidence." Then-Chairman Ajit Pai said both companies are "broadly subject to Chinese law obligating them to cooperate with the country's intelligence services."¹¹

That designation targeted Huawei's telecommunications hardware specifically, and it doesn't extend automatically to an open-source Python memory library. But the underlying legal obligation that motivated it is a standing condition on the company, not something that depends on hardware versus software.

Huawei has publicly denied that it provides user data to the Chinese government. That denial has not been tested in an independent judicial proceeding, and the legal obligation exists as a standing condition whether or not any specific request has ever been made.²

That's exactly why the ambiguity is uncomfortable rather than resolvable with a single fact-check.

The practical relevance for JiuwenMemory specifically: its Dreaming process continuously restructures detailed knowledge about users — preferences, decisions, project context — into a queryable profile.

Open-source licensing makes the code auditable, but it doesn't change which country's legal system governs the organization that wrote it.

For general development and research use, that's a background fact. For anyone considering it in a workload involving regulated, proprietary, or customer data, it belongs in a real risk assessment before deployment, not as an afterthought.

What This Means for Developers

Neither of these projects is production-ready in the way "production-ready" usually gets used.

Memora is a three-week-old research release with no tagged version — genuinely state-of-the-art on paper, backed by peer review, but still a research artifact rather than a maintained dependency.

JiuwenMemory is broader in surface area: multiple storage backends, pluggable memory providers, an opt-in background consolidation service. But it has no independent benchmark verification, Graph Memory isn't yet wired into the main extraction pipeline, and its own documentation doesn't even agree with its own launch coverage on a headline number (92% vs. 80% for MemoryTurbo's latency claim).

And if data sovereignty away from Chinese jurisdiction matters for your workload, that's a legal question to resolve before you touch real user data with it.

The practical move for either one — and really for any agent-memory framework claiming a LoCoMo or LongMemEval score this year — is the same. Read the architecture, because that's where the genuine ideas are.

Memora's abstraction/specificity split and JiuwenMemory's layered-plus-Dreaming design are both legitimate engineering contributions worth learning from.

Then run your own evaluation against your own workload before trusting anyone's leaderboard number, including the ones in this article's own comparison table above.

If you'd rather own the memory layer outright instead of adopting either project, building a Postgres-backed long-term memory store with pgvector is a smaller, fully-verified starting point.

And if you're specifically on Claude, Anthropic's own memory tool and context-editing APIs solve a narrower version of the same problem without a third-party dependency at all.

Bottom Line

Two organizations that don't talk to each other looked at the same failure mode — agents that forget everything the moment a session ends — and shipped architecturally different answers within 48 hours of each other.

That's less a coincidence than a sign the problem has become urgent enough that multiple serious teams are racing to solve it simultaneously, the same way multiple vendors' browser-use agents converged on the same benchmark earlier this month.

What's genuinely new here is the engineering: separating storage from retrieval structure, and consolidating memory on a schedule instead of only in the moment.

What isn't new — and what these two launches underline again — is that a benchmark score from the team that built the benchmark-winning system is a claim, not a fact.

And for at least one of these two projects, there's a second, non-technical question about jurisdiction that a leaderboard number was never going to answer anyway.