Tencent's Hy-Memory-30B: an Apache-2.0 Agent Memory Writer

The Short Answer

Tencent Hunyuan released Hy-Memory-30B-A3B on 15 October 2026 under Apache 2.0: a 30B mixture-of-experts model with about 3B active parameters whose only job is writing agent memory — deciding what to keep and how new facts overwrite old ones. It makes memory policy an artifact you can host and inspect. On ibl.ai you own all the code and the data, so that policy runs inside your perimeter.

The benchmark margin over Claude Opus 5 is 0.87 points on a macro average, and 0.01 points on one of the four harnesses. That is parity. The change worth acting on is licensing and location, not capability.

What is Tencent's Hy-Memory-30B-A3B and what job does it do?

Hy-Memory-30B-A3B is a model from Tencent Hunyuan that does not answer questions. It performs the write step inside an external memory system: reading a conversation or a coding trace and deciding what goes into the persistent store.

The model card describes it as a long-term-memory writer that "directly replaces the general-purpose LLM inside Mem0, MemOS, and Hy-Memory," deciding what to retain, how precisely to represent it, and how new evidence updates the memory bank.

That last clause is the interesting one. Most memory discussion is about retrieval. Writing is where the harder failure lives — a fact recorded in March and contradicted in July leaves two true-looking rows and no marker saying which one is current.

We measured that failure directly in agent memory fails at state transitions, not retrieval: on StateMemBench, leading memory systems returned the current state only 13–20% of the time. Hy-Memory-30B-A3B is trained against exactly that step.

The release has three software parts, all Apache 2.0. The weights are on Hugging Face. The framework is the hy-memory Python package on GitHub, published alongside a desktop and CLI application.

Documenting them is the tech report, arXiv:2610.22196, submitted 15 October 2026 and carrying arXiv's own licence rather than Apache 2.0.

Is Hy-Memory-30B-A3B the first model built to decide what an agent remembers?

Tencent does not claim to be the first such model, and neither should anyone quoting the release. The phrasing circulating online — the first model built to decide what an agent remembers — is not in the paper.

What the abstract actually says is narrower and checkable: existing frameworks "typically place a general-purpose large language model behind framework-specific prompts," and "a unified model that can operate across established memory frameworks remains largely unexplored."

Unexplored is a claim about coverage. First is a claim about history, and it is the kind that ages badly in a field this crowded.

The defensible version is this: Hy-Memory-30B-A3B is an open-weight model purpose-built for the memory write path, trained to run across several existing frameworks rather than one.

That distinction matters commercially. A buyer who finds one unsupportable superlative in a technical brief stops trusting the rest of it, including the parts that were true.

How much does Hy-Memory-30B-A3B actually beat Claude Opus 5 at writing memory?

By 0.87 points on the macro average, and by far less than that on three of the four test harnesses.

Here is the headline table from the model card, with every writer evaluated against identical harness versions, prompts, retrieval configuration, answer model and judge — only the memory writer changes.

Two caveats belong next to those numbers, and Tencent states both. Every benchmark in the matrix is run on a fixed 20% subsample for compute reasons.

Each harness score is the equal-weight mean of six metrics — LoCoMo Judge, LongMemEval, PersonaMem-v2, Travel SPS, Shopping PS and Code Memory Bench.

On the Hy-Memory harness the margin is 0.02 points. On MemOS it is 0.01. On a one-fifth subsample, those are ties. The honest reading of the top two rows is that a 3B-active specialist and a frontier model write memory about equally well.

The number that is not a tie is the one further down the same column. The tech report says training started from the Hy3-30B-A3B instruction-tuned checkpoint — the Hy3 row, at 51.63. After memory-specific training the same checkpoint scores 55.49.

Specialising it added 3.86 points, roughly four and a half times the 0.87-point gap to Opus 5. Against the untrained Hy3-A3B Base row at 47.66 the apparent gain is larger, but that is a different checkpoint and not the honest comparison.

That is the actual finding. Most of the value came from training a small model for one job, not from out-scoring a large one.

Why does an open-weight memory writer matter for governance rather than benchmarks?

Because the memory writer is the component that decides what your organization's agents still believe next quarter, and until now that decision has usually lived inside a hosted product as a prompt nobody outside it reads.

Consider what the write policy controls. Whether a customer's one-off complaint becomes a durable "dissatisfied" flag. Whether a corrected salary figure overwrites the wrong one or sits beside it.

Whether an offhand remark in a support chat is retained at all, which in a GDPR or FERPA context is a lawful-basis question before it is a product question.

When that policy belongs to a vendor, three things follow. You cannot read it, so you cannot tell a regulator what your system retains and why. You cannot pin it, so it changes on their release schedule. And you cannot test a change before it reaches production.

Published Apache-2.0 weights change all three. The writer becomes a versioned artifact: you pin a revision, run it against your own held-out conversations, diff the memory banks two revisions produce, and keep the record.

None of that is a benchmark improvement. All of it is the difference between an audit you can pass and one you cannot.

This is the same reason the licence on Tencent's 770B Hy4 release mattered more than its parameter count. A permissive licence at the component level is leverage; the weights are just how it is delivered.

It is also why memory, the model gateway and the store are one ownership decision rather than three features. An auditable writer pointed at a database you do not control has moved the opacity, not removed it.

Does Hy-Memory-30B-A3B solve persistent patient memory for clinical AI?

No, and nothing in the release claims it does. Neither the model card, the tech report nor the repository mentions healthcare, clinical workflows or patient records.

The evaluation set is conversational recall, persona tracking, travel and shopping preference, and repository question-answering.

That matters because the framing has started circulating anyway, and it inverts the real constraint. A clinical memory layer is not blocked on a model that writes good summaries.

It is blocked on provenance, retention limits, consent scope, the right to erasure, and an audit trail that survives a subpoena — none of which a 30B model supplies.

What does transfer is narrower and still useful. A memory writer whose weights you hold can run on infrastructure inside a HIPAA boundary with no outbound call, and its behaviour can be evidenced rather than attested.

That is a precondition for a regulated deployment, not a solution to one.

Treat any vendor claim that a memory model closes a clinical gap as the superlative problem again: the defensible sentence is smaller, and the smaller sentence is the one that survives procurement.

What does ibl.ai give you for agent memory, and what would you still have to build?

On ibl.ai, the memory store is yours and documented. Per the memory system documentation, memories are rows in PostgreSQL with PGVector alongside a 1,536-dimension embedding, scoped either globally to a user or to a single agent.

The store already does some of what a specialised writer is for. Duplicates are caught by a SHA-256 hash and a semantic check at a cosine distance of 0.15. Memories carry categories.

Temporary facts carry an expiry and are purged nightly, added in the 11 September 2026 release. Capture and use are separate switches, gated at the organization, agent and user levels.

What ibl.ai does not do is ship Hy-Memory-30B-A3B as a bundled component. The platform is model-agnostic, so a self-hosted Hy-Memory-30B-A3B endpoint is a provider like any other.

But pointing the write path at it is integration work you would do: standing up the inference server, mapping its JSON output onto the platform's memory schema, and re-validating your dedup thresholds against a writer that phrases facts differently.

That is the honest boundary. Ownership of the store, the gateway and the deployment target is what the platform gives you. Ownership of the write policy is now purchasable separately, from Tencent, for nothing — and the two compose only if you own both halves.

The alternative composes badly. A hosted assistant that writes memory you cannot read, into a store you cannot export, priced per seat whether anyone used it that month, is three dependencies wearing one logo.

Related reading: agent memory fails at state transitions, not retrieval — the measured supersession failure this model is trained against; who owns an AI agent's memory when you switch models — why the store, the gateway and network governance are one decision; Tencent's 770B Hy4 is Apache-2.0, and 1.56 TB of weights — the same vendor's licence record, and the hardware catch.

Sources: parameter counts, the Apache 2.0 licence, the cross-harness table and the evaluation protocol from the Hugging Face model card; the abstract, the "largely unexplored" novelty claim and the 15 October 2026 submission date from the tech report, arXiv:2610.22196; the framework, application and licence statement from the Hy-Memory repository; ibl.ai's memory schema, dedup thresholds and gating from the memory system documentation.