Back to Tech News

tech-news · 22 October 2026

Tencent Open-Sources a Memory Stack for Long-Running AI Agents

Hy-Memory 2.0 separates remembering from answering, with an open model, framework and shared-memory app aimed at agents that must carry useful state across sessions.

Tencent Hunyuan released Hy-Memory 2.0 on 16 October as an open stack for a deceptively difficult agent problem: deciding what should survive after a conversation or task ends. The release includes a specialist memory-writing model, an SDK covering several kinds of memory, and MemHub, an application intended to share one memory store across multiple AI tools.

That makes this more interesting than another model competing to answer prompts. Hy-Memory moves attention to the write path behind a persistent agent: extracting durable facts and decisions, recording changes without losing history, and avoiding a memory bank filled with every transient detail. For long-running coding and automation agents, those choices can determine whether the next session resumes intelligently or confidently repeats yesterday's mistakes.

What changed this week

The model is called Hy-Memory-30B-A3B. It has 30 billion total parameters but activates roughly 3 billion for each token through a mixture-of-experts design. Instead of acting as the agent's general answer model, it can replace the general-purpose model normally used to write records inside systems including Mem0, MemOS and Tencent's own Hy-Memory framework.

The distinction matters. A memory system usually has at least three jobs: a writer turns an interaction into persistent records, a retriever selects records for a later query, and a reader uses those records to answer. A better reader cannot recover a fact that the writer discarded. At the other extreme, storing everything raises storage and retrieval costs while burying useful evidence in noise.

Tencent's technical paper trains specifically for that first job. An on-policy distillation stage teaches the different write operations and schemas used by several memory frameworks. A reinforcement-learning stage then scores whether facts written from each chunk remain useful downstream. It also traces later answer evidence back to contributing chunks and applies a penalty for excessive storage. The goal is not a prettier summary; it is a policy for deciding how an external state should change.

Hy-Memory 2.0 wraps that writer in a wider framework. It separates chat memory, working memory and coding memory. Chat memory links facts into evolving events and handles contradictions. Working memory records goals, settled approaches, interim results and the conditions under which previous experience applies. Coding memory is meant to preserve the decisions and history needed when a long task resumes. Those are sensible categories because a preference, a task checkpoint and the reason for a code change have different lifetimes and retrieval needs.

The third layer, MemHub, aims to make those records portable across ten listed tools, including Cursor, Codex, Claude Code, OpenCode and Hermes. It imports past sessions, synchronises new ones and supplies relevant memories through plugins. That is an ambitious product claim, but the key design idea is sound: persistent context becomes a separate service rather than property trapped inside whichever assistant happened to collect it.

Why it matters

Agent memory is often discussed as if it were simply a larger context window or a vector database. Neither solves the full problem. Context windows are temporary and expensive to refill. Retrieval can find only what was stored, and similarity alone does not explain whether a fact is current, superseded, conditional or worth keeping. A specialised writer offers a place to enforce those distinctions before they become retrieval problems.

For self-hosted agents, the release also offers a useful separation of concerns. An operator could keep a preferred reasoning model while assigning memory maintenance to a smaller active model. The published weights and framework code make local inspection and experimentation possible, and compatibility with more than one memory framework reduces dependence on a single storage design.

There is still a hardware trade-off. Sparse routing reduces computation, not the size of the complete model that must be available to the runtime. The official model card publishes a 30-billion-parameter checkpoint rather than a genuinely three-billion-parameter download. That may be practical on a capable inference server, but it is not automatically a lightweight addition to every homelab.

The performance headline also needs careful handling. Tencent reports a 55.49 macro average across four memory harnesses, compared with 54.62 for Claude Opus 5 and 53.64 for DeepSeek V4.1 Flash. The experiment holds the retrieval setup, reader and judge fixed so that the writer is the changing component, and EverMemOS is described as unseen during training. Those are useful controls.

However, the evaluations use fixed 20% benchmark subsamples, and the results come from the team releasing the model. As independent coverage notes , the claimed lead has not yet been independently reproduced. The margin over Claude is less than one point, so the important signal is not that one model has “beaten” another. It is that a purpose-trained writer appears competitive across several memory systems while activating far fewer parameters than a frontier general model.

Operational questions matter just as much as benchmark scores. A shared memory service may contain personal preferences, project history, source-code context and previous instructions. Administrators need clear controls for retention, deletion, provenance, tenant isolation and plugin access. Open weights make local processing possible, but they do not by themselves guarantee that every surrounding connector or synchronisation path stays local.

What to watch next

The next evidence should come from reproducible evaluations on the full benchmark sets and from deployments outside Tencent's own stack. In particular, it will be useful to see how the writer handles malicious instructions embedded in remembered content, conflicting updates over months, schema migrations, and deletion requests that must propagate through derived records.

It is also worth watching whether smaller or quantised variants preserve the reported quality, and whether MemHub's cross-tool integrations prove reliable without widening the privacy boundary. Hy-Memory 2.0 does not settle agent memory. It does, however, turn the act of remembering into a distinct, testable component — exactly where long-running agents need more engineering and fewer assumptions.