Context has become decisive for whether AI agents can be trusted to act autonomously. A VB Pulse survey in June found that 57% of enterprises had traced a confidently wrong agent answer back to missing or inconsistent context, underscoring how central context management is to agent reliability.
Most fixes so far have focused on a narrower problem: enabling a single agent to remember more within a session. What has been missing is a way for an entire team of agents to draw on the same context simultaneously. When an agent's context is shared across a team, a wrong fact no longer costs just one user repeated corrections — it can propagate to every agent in the team.
Agent Memory and the new Team Memory beta
Tencent developed Agent Memory, an open-source project it says grew out of six months spent addressing agents losing context in long sessions. A key element is a persona layer: a stable, distilled representation of who a user is and how they work, accumulated across many conversations rather than reconstructed each time.
On Tencent's internal benchmark that measures whether an agent still applies that persona after extended use, accuracy rose from 48% to 76% — a 59% relative improvement — after adding the persona layer. This week the company extended the project with the beta launch of Team Memory, which applies the same approach to an entire team instead of a single agent. Tencent also noted the repository reached No.1 on GitHub's TypeScript trending list this week.
What Team Memory does
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 only with the assets it needs:
- 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 need not be reintroduced to a user it has already worked with.
- Skill: captures procedures from completed work, versioned and reviewed before they are shared rather than dropped into a folder as-is.
- LLM-Wiki: turns documents and specs into structured, linked pages.
- Code-Graph: indexes a codebase's symbols, files and call relationships so an agent can check what a change might affect before making it.
Tencent's documentation frames the distinction succinctly: "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 Team Memory implements "Agent Loadouts": a Scout agent doing research can be equipped with market research and competitive-analysis assets, while a Builder agent receives the code graph and product docs it needs rather than giving every agent access to everything.
Visibility tiers and defaults
Which assets an agent receives is governed through four visibility tiers:
- Private: readable only by the asset's owner.
- Team: readable by anyone on the team.
- Restricted: gated by user-, role- or agent-level access control.
- Agent: provisioned to one specific agent within a team.
New assets default to Private, so sharing must be a deliberate action rather than automatic.
The missing piece: what happens when a memory is wrong?
The access model answers who may read a memory asset, but it does not resolve what should happen once a memory asset proves incorrect. Tencent's documentation describes ownership, versioning and status tracking for each asset, but it does not describe a correction or expiry process for a fact that has already been read and reused by other agents on a team, nor a mechanism to reconcile two agents' conflicting memories.
Practitioners highlighted this gap hours after 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," Blake Murphy wrote on X.
Concerns included not only fixing a bad fact after the fact but who decides what gets recorded at all. "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," Virgil Maro wrote on X.
Others pushed further: what happens if two agents write directly contradicting facts about the same thing? "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," Austin Green wrote on X.
Not all reactions were 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," Moez Zhioua wrote on X.
This is not unique to Tencent
These issues are not specific to Tencent's implementation. A March 2026 paper published independently, "Governed Memory: A Production Architecture for Multi-Agent Workflows," identifies governance fragmentation and silent quality degradation without feedback loops as structural risks in shared multi-agent memory generally. The paper's pattern matches the practitioners' concern: a wrong fact in a single-agent memory costs one user repeated correction, while the same wrong fact in a team-wide memory propagates broadly before detection.
How Team Memory compares with other approaches
Through 2026 much agent-memory work focused on enabling a single agent to remember more within a session: examples include LangChain's LangMem SDK, Google's Always On Memory Agent and Anthropic's work within the Claude Agent SDK. Another track has aimed to give agents access to a governed model of business data; VB's June survey found only 25% of enterprises had that kind of governed context layer in production. Vendors including AWS, Couchbase, Oracle, Redis and Pinecone have shipped versions of those solutions this year.
The closest comparison to Team Memory is Asana, which built shared memory across a company's AI teammates so an agent need not be re-briefed on context another agent already has. Asana's approach also emphasized an access-control system to stop one agent's memory from leaking into a project another agent isn't cleared to see. Tencent's implementation is open-source and portable across frameworks, while Asana's was platform-scoped, but both faced the same governance trade-offs.
Bottom line
For teams evaluating shared agent memory, the upside is tangible: agents stop relearning what the team already knows. The trade-off is equally tangible: one bad write is no longer contained to one agent — it can be inherited by every agent that reads from the shared pool, and Team Memory currently lacks a detailed correction or expiry mechanism to catch such propagation. The technology's practical success will therefore depend as much on governance decisions — who can write, what is allowed to be written, and how corrections or expiries are enforced — as on the underlying implementation.
