Team Memory Is Here. Nobody Agrees on How to Fix a Wrong Fact.

The week team memory shipped

On August 3, 2026, Tencent tagged v2.0.0 of TencentDB Agent Memory and open-sourced it as a team-level memory hub for AI agents. One command to deploy (./start-all.sh), MIT-licensed, self-hosted — and the numbers moved fast: roughly 7,000 stars in the first week, 19.9k total with roughly 1,800 forks as of this writing, putting it among the fastest-moving repos on GitHub's TypeScript trending list. The repository describes itself as "a team-level memory hub for AI Agents — turning conversations, docs, and code into four reusable memory assets (Chat Memory, Skill, LLM-Wiki, Code-Graph) that are governed, shared, and equipped across agents and frameworks."

That last word — governed — is doing more work than the launch coverage gave it credit for. A memory hub is not a chatbot gimmick. It is the context substrate of a team: the place where the facts, decisions, and working knowledge that agents act on are written once and read by every teammate's agent. When that substrate is shared, the stakes change. A wrong fact is no longer a wrong answer in one conversation; it is a wrong answer waiting in every conversation that retrieves it. The difference between a chatbot that remembers and a team that remembers is exactly this: the first is a convenience, the second is infrastructure, and infrastructure has to be trustworthy.

The launch itself is honest about its maturity. Team Memory is still described as "beta" in the README banner, and VentureBeat describes the release as "the beta launch of Team Memory," grown from "six months spent fixing a narrower problem: agents losing context in long sessions." The narrow problem is solved — the hub holds context across sessions, across agents, across the team. The wide problem — what happens when a team's agents share a store and the store is wrong — is the subject of this post.

The timing is not incidental. Team memory arrives at the moment the ecosystem is already converging on memory as shared infrastructure: the MCP memory-server field guide mapped the "one memory, many clients" story, and the shared-memory post mapped the "one memory, many agents" extension. Tencent shipped the first serious open-source implementation of that extension. What it did not ship is the part that makes shared memory safe to trust: a way to fix the store when the store is wrong.

Who remembers vs. who governs

The escalation has been visible all year, and each step moved the hard question one level up.

Single-agent memory was the first step: the assistant that persists facts across sessions, so "does it remember?" stopped being the question. The store exists, the write survives the session, and the answer to "does it persist" is yes. That is the layer this series mapped in why context windows aren't memory: context is what the model sees; memory is what the system commits. The unit of memory is the episode, and the memory layer is what makes episodes retrievable later. Single-agent memory is a solved problem — not because it is easy, but because the industry built memory servers for it, and a memory server is a layer any client can attach to.

Shared memory between agents was the second step, and the question moved to "who can read it." When agents talk to each other, who remembers? — the gap covered in the shared-memory post — the answer is access: the store is reachable, the read is authorized, and the protocol layer deliberately declines to carry memory at all. A2A's contextId is correlation, not memory; the protocol moves tasks and messages, and nothing else. Teams that wanted shared state built it themselves, badly, in five recurring ways — pass-everything, KV scratchpads, per-agent databases, framework checkpoints, vector stores — each with a ceiling, each a silo in miniature. The gap was never that the state was hard to store; it was that nobody had claimed the layer.

Team memory is the third step, and it raises the question nobody has answered: who corrects it? The store is now the team's shared truth — written by any member's agent, read by every member's agent. Access control solved who can read. It did not solve what happens when what they read is wrong. That is the escalation in one line: single-agent memory solved persistence, shared memory solved access, and team memory has made correction the open problem.

The distinction that matters is the one in this post's title: who remembers versus who governs. Remembering is a storage question — where the facts live, who may read them. Governing is a trust question — who decides the facts are true, who fixes them when they are not, and what happens to the agents that already read the wrong version. The industry has spent the year solving the first. The second is where team memory runs out of answers.

Notice what the escalation does to the trust requirement. Single-agent memory has to be correct for one user; team memory has to be correct for everyone who reads it, including people who were not in the room when the fact was written. Trust scales with readership, and the current products scale the readership without scaling the trust. That is the mismatch this post is about, stated in its plainest form: sharing multiplied the audience for every fact without adding a way to keep the facts right.

What Tencent shipped

The hub turns raw material into four reusable assets. Chat Memory "retains preferences, facts, decisions, and interaction history" — the conversational record, the thing single-agent memory already does, now shared. Skill is the executable knowledge: it "has versions, resource files, trigger boundaries, execution steps, and validation rules" — a procedure an agent can run, not just a fact it can recall, and the only asset with versioning built in. LLM-Wiki "turns product docs, design specs, and ops runbooks into structured pages with a link graph" — the team's documentation, made retrievable, with the links between pages preserved so a question can walk from one spec to the next. Code-Graph "indexes code symbols, files, call relationships, and impact paths" — the codebase, made navigable, so an agent asked "what breaks if this function changes" can follow the call graph instead of guessing. Four asset types, one hub, and a distillation ladder underneath.

The ladder is the interesting part. Raw conversation is distilled layer by layer: L0 Conversation → L1 Atom → L2 Scenario → L3 Persona. L0 is raw turns with full context; L1 is facts, preferences, constraints, and events; L2 is knowledge blocks organized around projects and scenarios; L3 is long-term profiles and stable patterns — "Core / Persona." The hub's own benchmark, PersonaMem, reports 48% accuracy without the persona layer and 76% with it, a +59% relative improvement — self-reported on Tencent's own benchmark, with no independent reproduction published yet. The ladder is a real design: it separates the ephemeral from the durable, and it gives the hub a notion of what deserves to persist. It is also, notably, a one-way distillation — nothing in the ladder describes what happens when a distilled fact turns out to be wrong.

The access model is where the design shows its care. Visibility has four tiers — private (only the Owner can read, not even team admins), team (team members can read), restricted (precise access via User/Role/Agent ACLs), and agent (targeted equipping of specific agents). New Chat Memory and Skills are private by default: "sharing is an explicit action, not a default leak." Combined access uses "Fixed Binding + ACL" — first narrow the permission scope by Team, User, Agent, and visibility, then retrieve based on the current query. Roles run global System Admin plus team-level Admin/Member, with asset ownership tracked via Owner. The design is careful, and the care is visible: the default is private, sharing is deliberate, and every asset has an owner who can be asked about it.

That is a real answer to "who remembers" — the hub knows who may read what, and the default is private. It is not an answer to the question the launch raised. The four tiers govern read access; nothing in the model governs truth. A fact that passes every ACL check can still be wrong, and the ACLs have nothing to say about that.

The gap: access control is not correction

VentureBeat's Sean Michael Kerner put the critique precisely on August 7: "nothing in the documentation describes a correction or expiry process for a fact that's already been read and reused by other agents on a team, or a way to resolve it when two agents' memories of the same thing disagree." Note the hedge — it is a documented gap, not a proven absence. But the documentation is the contract, and the contract has no correction loop. The four tiers govern who may read; nothing in them governs what happens when the thing being read is wrong.

The reactions, as VentureBeat reported them, converged on the same point from three directions. Blake Murphy: "Shared memory makes the write path the interesting problem. Retrieval gets most of the attention, but a wrong fact written once now propagates to every teammate's agent instead of just yours. Curious how the governance layer handles correction and expiry." Moez Zhioua: "Interesting shift: making memory a shared service turns agents into a real team rather than isolated bots. Governance will be the trickiest part, especially when facts conflict." Austin Green sharpened the blast radius: "in shared mode, whose memory wins when two teammates' agents have written contradicting facts about the same module? Single-agent memory drifts slowly. Shared memory drifts fast, because one stale write propagates to people who never saw the session that produced it."

The shift is the blast radius. In single-agent memory, a wrong write is contained: one assistant answers one user wrong until the user corrects it, and the correction is a private edit. In team memory, one wrong write fans out to every agent that retrieves the asset — including agents whose sessions never saw the conversation that produced the error. The agent that wrote the wrong fact is not the only one that acts on it; the whole team's agents do, and none of them know the write was wrong. The correction, when it comes, has to reach all of them — and the store has no mechanism for that.

VentureBeat's closest comparison is Asana, which built shared memory across a company's AI teammates. Asana's chief product officer described an access control system built to stop one agent's memory leaking into a project another agent is not cleared to see — the same instinct as Tencent's four tiers, applied to the same problem. Access control again: the solved half. The correction half is where the comparison runs out, because neither product documents one.

It is worth pausing on the two words VentureBeat used, because they name two different failures. Correction handles the fact that was never true — someone wrote it wrong, and it needs to be replaced with the right version. Expiry handles the fact that was true and stopped being true — the vendor shipped, the deadline passed, the policy changed. Both are lifecycle events a memory store has to process, and both change what every agent that reads the store should see. Tencent's documentation describes neither. A fact that stopped being true is, in the current model, indistinguishable from a fact that is true: it stays retrievable with the same confidence until someone happens to correct it in a session nobody else reads.

Why wrong facts propagate

This is not Tencent's bug; it is the category's. Independent research on governed memory — Hamed Taheri's paper at Personize.ai, arXiv:2603.17787, submitted March 18, 2026, and in production at the company — names five structural challenges: "memory silos across agent workflows; governance fragmentation across teams and tools; unstructured memories unusable by downstream systems; redundant context delivery in autonomous multi-step executions; and silent quality degradation without feedback loops." The last one is the one team memory inherits: without a feedback loop, a wrong fact degrades silently, and shared memory makes the degradation shared. The first four are the reasons the industry built memory layers at all; the fifth is the reason the layers keep being wrong. Silos explain why memory was fragmented; fragmentation explains why governance is scattered; unstructured memories explain why downstream systems cannot act on what is stored; redundant delivery explains why context costs keep climbing. And the fifth — silent degradation — is the one that explains why a wrong fact survives: nothing in the loop notices.

The industry numbers agree. VentureBeat's Pulse survey from June 2026 found 57% of enterprises had traced a confidently wrong agent answer back to missing or inconsistent context — while only 25% had a governed context layer in production, even as AWS, Couchbase, Oracle, Redis, and Pinecone all shipped versions of it this year. The gap between the failure (57%) and the fix (25%) is the market's open question, and it is the same gap in miniature: everyone has context, nobody has governance. The vendors shipped the storage; the governance layer is the part that did not ship with it. A majority of enterprises have already felt the failure mode this post is about — a confidently wrong answer traced to context — and only a quarter have the layer that would govern it.

And the honest caveat cuts both ways. The same paper that names the challenges admits its own limits: its evaluation tests temporal conflicts between sequential writes but not concurrent writes from multiple agents on the same entity simultaneously. Even the independent research does not cover the exact scenario the commenters asked about — two agents writing contradicting facts at the same time. Nobody has validated that case, because nobody has shipped the system that needs to handle it. The gap is documented, not hypothetical, and it is documented at every level: in Tencent's README, in VentureBeat's critique, and in the research that was supposed to be ahead of the products.

What governance actually requires

The paper's four mechanisms translate into four concrete requirements for a governed memory layer. Each one answers a specific failure in the five structural challenges, and each one is missing from the shipped products.

A dual memory model — facts plus typed properties. Open-set atomic facts ("the migration is blocked") sit alongside schema-enforced typed properties ("status: blocked, owner: platform-team"). The typed half is what downstream systems can act on deterministically — a workflow can branch on status, a dashboard can count owner — and the atomic half is what stays flexible when the world does not fit a schema. Governance needs both, because a fact you cannot type is a fact you cannot route, and a fact you cannot route is a fact you cannot govern. This is the mechanism that answers the "unstructured memories unusable by downstream systems" challenge: the typed layer is what makes memory machine-actionable rather than merely human-readable.

Governance routing with progressive context delivery. Instead of dumping the whole book into every prompt, the layer routes context progressively — only the delta a task needs, delivered at the point it needs it. The paper reports a 50% token reduction from progressive delivery on its own controlled data. The point is not the number; it is the principle: governance is a routing decision, not a storage detail. The same routing that saves tokens is the routing that decides which context is authorized for which task — the two are the same mechanism, and the shipped products have neither. This answers the "redundant context delivery" challenge, and it is also the closest thing the paper has to a correction mechanism: if context is routed per task, a corrected fact can be routed differently from the fact it replaced.

Reflection-bounded retrieval with entity-scoped isolation. Retrieval is bounded by reflection — the system checks what it is about to inject — and isolated per entity, so one entity's context cannot leak into another's. The paper reports zero cross-entity leakage across 500 adversarial queries and 100% adversarial governance compliance. Again: self-reported, on controlled and synthetic data the paper itself calls an "upper-bound demonstration" free of production noise. The direction is what matters: retrieval as a governed decision, not a similarity search. This is the mechanism that would have contained the blast radius the commenters worried about — a wrong fact about one entity stays with that entity instead of contaminating every answer.

A closed-loop schema lifecycle. Schemas are authored with AI assistance and refined per property, automatically, as the data changes — a feedback loop that keeps the typed layer from rotting. This is the mechanism the five structural challenges point at: without a loop, memory degrades silently; with one, degradation is caught and corrected. It is also the mechanism closest to the correction question, because a feedback loop is where a correction would enter the system at all — and it is the one mechanism that requires the system to notice when a fact stops being true.

The paper's own numbers, with the caveat attached: 99.6% fact recall, 92% governance routing precision, quality saturation at roughly seven governed memories per entity, and 74.8% overall accuracy on LoCoMo against a human baseline of 87.9%. The honest read: governed memory is not a solved problem — the LoCoMo gap to the human baseline is real, and the numbers are self-reported on synthetic data — but the requirements are no longer mysterious. The gap between the requirements and the shipped products is exactly the gap this post is about.

The mechanisms also compose, which is why they are requirements rather than a feature list. The dual memory model gives routing something to route; routing gives retrieval a scope to enforce; the schema lifecycle gives the feedback loop a place to land corrections. Shipped in isolation, each one is an optimization. Shipped together, they are the governance layer the products lack — the layer that would have made the answer to "who fixes a wrong fact" a designed property instead of an open question.

The governance table

Read the table as a map of the category, not a leaderboard: every layer governs a different slice, and the correction slice is empty in every row but one. Classic RAG governs nothing but retrieval — it has no write path to govern, which is why it is the baseline. Tencent governs access: who may read, who owns, who administers — the solved half, done carefully. The paper governs routing and schema: which context goes where, and how the schema stays alive. Asana governs project boundaries: one agent's memory cannot leak into a project it is not cleared to see. Access control is the solved part; correction is the part nobody ships. That is the whole gap in one table.

The correction loop: supersede, not delete

The missing primitive is not a delete button. It is retirement and re-assertion: a wrong fact must be closed and replaced, not overwritten, so the store keeps its timeline and rollback is a transactional change. Delete destroys the ability to reconstruct what happened — which agent read the wrong fact, which answers it shaped, what the truth was before. Supersession preserves all of it: the old fact stays queryable as of its time, the new fact takes over from its time onward, and the correction is one transaction instead of a data-loss event. The store does not forget that the wrong fact existed; it records that the wrong fact was believed until a specific moment — and that is exactly the record a team needs when it audits which answers were shaped by the error.

This is the write-path discipline this series covered in the new attacks on AI memory: a poisoned or wrong fact is retired, not deleted, so the store can roll back to a point before the error. The correction loop is the governance version of the same discipline — the difference between an incident and a data-loss event. The poisoning post's defense spine applies here almost unchanged: provenance on every write, verification before persistence, temporal versioning so a wrong fact is retired rather than deleted, scoped retrieval so a wrong fact has a bounded blast radius, and an audit trail because it is frequently the only trace of what happened. The write path is the security boundary in the poisoning post; it is the governance boundary here. The same discipline that stops a poisoned fact from becoming permanent is the discipline that stops a wrong fact from becoming permanent.

OpenZync is one architecture that already has the primitive: a self-hostable temporal knowledge graph where facts supersede rather than overwrite, so a correction closes one validity window and opens the next while the timeline stays intact. It is a starting point, not a claim of completion — the point is that the primitive exists and is implementable, which is more than the shipped products document. The correction loop is not a research problem; it is a design decision, and the decision is supersede-not-delete.

What to watch

Four signals will mark the category's maturity. None of them are product announcements; all of them are evidence.

An independent PersonaMem reproduction. Tencent's benchmark is self-reported; a third-party reproduction — or a competing benchmark — would turn the +59% claim from marketing into evidence. Until then, the number is a claim about the hub's value, not a measurement of it. The same applies to the paper's numbers: 99.6% fact recall and 92% routing precision are upper-bound demonstrations on synthetic data, and the field will not know how they hold in production until someone runs them there.

A documented correction process. The first vendor to ship a correction, expiry, and conflict-resolution process — in the documentation, not a blog post — closes the gap VentureBeat named. Watch for it in the next release cycle of every governed-context vendor: Tencent, Asana, and the AWS/Couchbase/Oracle/Redis/Pinecone cohort. The documentation is the contract, and the contract is where the gap lives. The tell will be specific: a documented endpoint or workflow for retiring a fact, a stated expiry policy, a defined answer to "whose memory wins."

Governed-context adoption. The 25% figure is the marker: when governed context layers move from a quarter of enterprises to a majority, the correction question stops being theoretical. Adoption is what forces the write path to be taken seriously — a store that a quarter of enterprises trust can be wrong quietly; a store that most of them trust cannot. The 57% who have already traced a wrong answer to context are the demand side; the correction loop is what the supply side has not yet shipped. The vendor cohort is not standing still — AWS, Couchbase, Oracle, Redis, and Pinecone all shipped governed-context versions this year — but shipping storage is not shipping governance, and the correction question is what distinguishes the two.

The "what never gets written down" decision. As VentureBeat reported, Virgil Maro put it best: "once teammates' agents can read each other's context, someone has to decide what never gets written down." Governance is not only about fixing wrong facts; it is about deciding which facts are written at all. That decision — who writes, who reviews, what stays out of the store — is the governance layer nobody has built yet, and it is the one that will define whether shared memory is a team asset or a team liability. Access control answers who may read; nothing yet answers who may write, and what should never be written at all.

The correction loop is the next feature

Team memory shipped this week, and it is a real step: sharing is solved, access is governed, and the hub is serious infrastructure. The question it raises — who fixes the wrong fact every agent now inherits — is the next feature of the category, and nobody has shipped it yet. Not Tencent, not the research, not the vendors with governed-context layers. The correction loop is the open slot, and the requirements for filling it are no longer mysterious: a dual memory model, governance routing, entity-scoped retrieval, a feedback loop, and a correction primitive that supersedes rather than deletes. The gap is documented, the requirements are named, and the primitive exists in at least one architecture. What is missing is a product that puts them together.

If you are building memory infrastructure — a memory server, an agent memory layer, a shared store — that list is the start. OpenZync is a self-hostable starting point: a temporal knowledge graph where facts supersede rather than overwrite, exposed over REST and MCP, so the correction loop lives on infrastructure you control. Start with the memory & context docs and the openzync-mcp repository.

This is part of a series on agent memory. Read why context windows aren't memory, then how a temporal knowledge graph is built, then the MCP memory-server field guide, then when agents talk to each other, who remembers, then the new attacks on AI memory.