VentureBeat · Aug 7, 2026 16:30 UTC

Tencent's Team Memory shares AI agent memory across a team — with no governance yet for when it's wrong

Summary

A <a href="https://venturebeat.com/data/57-of-enterprises-have-watched-ai-agents-be-confidently-wrong-the-fix-is-an-agentic-context-layer-but-who-has-one">VB Pulse survey this June found that 57%</a> of enterprises had traced a confidently wrong agent answer back to missing or inconsistent context — the latest sign of how central context has become to whether AI agents can be trusted to act on their own.Most of the fixes so far have solved a narrower version of that problem: one agent remembering more, in one session. What's been missing is a way for a team of agents to draw on the same context at once, and that gap is where a newer problem is surfacing. Once an agent's context is shared across a whole team, a wrong fact doesn't cost one person a repeated explanation. It costs the whole team.Tencent's answer to that gap is<a href="https://github.com/TencentCloud/TencentDB-Agent-Memory"> Agent Memory</a>, an open-source project the team said grew out of six months spent fixing a narrower problem: agents losing context in long sessions. Part of that system is a persona layer, a stable, distilled picture of who a user is and how they work, built up over many conversations rather than reconstructed each time. On Tencent's own benchmark for whether an agent still applies that picture correctly after extended use, accuracy rose from 48% to 76%, a 59% relative improvement, once the persona layer was added. This week, Tencent extended that project with the beta launch of Team Memory, which opens the same approach up to a whole team instead of one agent. Tencent said <a href="https://x.com/tencentai_news/status/2085272380759581092">the repo hit No. 1 on GitHub's TypeScript trending list</a> this week.Agents on a team can now read from a shared memory hub instead of keeping separate, siloed context, governed through an access control layer that determines who can read what.<h2>What Team Memory actually does</h2>The core idea is a shared hub rather than a shared prompt. Instead of pasting one large context block into every agent's window, Team Memory registers four kinds of reusable assets and equips each agent with only the ones it needs.<ul><li>Chat Memory. Retains preferences, facts, decisions, and interaction history, distilled through four layers, from raw conversation up to a stable long-term persona, so an agent does not need to be reintroduced to a user it has already worked with.</li><li>Skill. Captures procedures pulled from completed work, versioned and reviewed before they are shared rather than dropped into a folder as-is.</li><li>LLM-Wiki. Turns documents and specs into structured, linked pages.</li><li>Code-Graph. Indexes a codebase's symbols, files, and call relationships so an agent can check what a change might affect before making it.</li></ul>Tencent's<a href="https://github.com/TencentCloud/TencentDB-Agent-Memory"> documentation</a> draws the distinction directly: "RAG answers 'what can be found?' Team Memory also answers 'who can use it, which version is valid, and which Agent should receive it.'" In practice, that's what Tencent calls an "Agent Loadout": a Scout agent doing research can be equipped with market research and competitive analysis assets, while a Builder agent gets the code graph and product docs it needs instead, rather than every agent getting access to everything.Which assets an agent gets equipped with is governed through four visibility tiers:<ul><li>Private. Readable only by the asset's owner.</li><li>Team. Readable by anyone on the team.</li><li>Restricted. Gated by user, role, or agent-level access control.</li><li>Agent. Equipped to one specific agent within a team.</li></ul>New assets default to private, so sharing has to be a deliberate action rather than something that happens automatically.<h2>What happens when a memory is wrong</h2>That access model answers a real question, who is allowed to read a given memory asset. It does not answer a second one, which is what happens once a memory asset turns out to be wrong. Tencent's own documentation lays out ownership, versioning, and status tracking for each asset, but 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.That gap is what practitioners flagged within hours of the launch post."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,"<a href="https://x.com/BlakeMurphy/status/2085385624115138828"> Blake Murphy</a> wrote on X.The concern wasn't only about fixing a bad fact after the fact. It was about the decision to leave something out of the record in the first place. "the governed part is the hard part. once teammates' agents can read each other's context, someone has to decide what never gets written down,"<a href="https://x.com/_virgil19/status/2085403856624922852"> Virgil Maro</a> wrote on X.Others pushed further into what happens once two agents' memories actively contradict each other, not just go stale."The Code-Graph plus LLM-Wiki split is the right call. The part I'd want to see benchmarked: 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,"<a href="https://x.com/wgi_dev/status/2085382411613872341"> Austin Green</a> wrote on X.The reaction wasn't uniformly critical. "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,"<a href="https://x.com/MoezZhioua/status/2085400880208126350"> Moez Zhioua</a> wrote on X.None of these are edge cases specific to Tencent's implementation. A March 2026 paper on production multi-agent memory architecture,<a href="https://arxiv.org/html/2603.17787"> "Governed Memory: A Production Architecture for Multi-Agent Workflows,"</a> published independently of any single vendor, identifies governance fragmentation and silent quality degradation without feedback loops as structural risks in shared multi-agent memory generally. The pattern the paper describes matches what the commenters above pointed at directly: a wrong fact in a single-agent memory system costs one user a repeated correction, while the same wrong fact in a shared, team-wide memory system propagates to every agent that inherited it before anyone catches it.<h2>How Team Memory compares</h2>AI agent memory work in 2026 has mostly focused on a single agent remembering more, in one session, about one user:<a href="https://venturebeat.com/ai/enhancing-ai-agents-with-long-term-memory-insights-into-langmem-sdk-memobase-and-the-a-mem-framework"> LangChain's LangMem SDK</a>,<a href="https://venturebeat.com/orchestration/google-pm-open-sources-always-on-memory-agent-ditching-vector-databases-for"> Google's Always On Memory Agent</a>, and Anthropic's work inside the<a href="https://venturebeat.com/ai/anthropic-says-it-solved-the-long-running-ai-agent-problem-with-a-new-multi"> Claude Agent SDK</a> all work this way. A different line of work has focused on giving agents access to a shared model of business data. VB's own June survey found only 25% of enterprises had that kind of governed context layer in production, while vendors including<a href="https://venturebeat.com/data/aws-enters-the-context-layer-race-with-a-graph-that-learns-from-agents-not-manual-curation"> AWS</a>, <a href="https://venturebeat.com/data/ai-agents-need-context-everywhere-they-run-even-where-the-cloud-cant-follow"> Couchbase, Oracle, Redis, and Pinecone</a> have all shipped versions of it this year.Team Memory's closest existing comparison is likely Asana, which built<a href="https://venturebeat.com/orchestration/shared-memory-is-the-missing-layer-in-ai-orchestration"> shared memory across a company's AI teammates</a> so an agent doesn't need to be re-briefed on context another agent already has. Asana's CPO described the same tradeoff Tencent's practitioners are now raising,<a href="https://venturebeat.com/orchestration/asanas-ai-agents-share-memory-across-your-company-but-not-your-secrets"> an access control system built specifically to stop one agent's memory from leaking into a project another agent isn't cleared to see</a>. Tencent's version is open-source and portable across frameworks rather than scoped to one platform, but it's answering a question Asana's team already ran into while building a closed one.For teams evaluating this category, the upside is real: agents stop relearning what the team already knows. The tradeoff is just as real: one bad write is no longer contained to one agent — it's inherited by every agent that reads from the shared pool, with no correction or expiry process yet in place to catch it.

Original reporting

Open original source

Related coverage

Read full article on VentureBeat