Shared Agent Memory Has an Access-Control Problem, and Nobody's Solved It

Here is a claim I'd have resisted a year ago: the hard part of agent memory was never getting an agent to remember. It is deciding what happens when fifty agents remember the same wrong thing. Single-agent memory is a convenience problem. The moment memory is shared across a team, it becomes an organisational access-control problem, with correction, deletion and conflict semantics attached, and those are the exact features the current crop of products is thinnest on.

Two vendors shipped answers to this within weeks of each other. Tencent Cloud's Team Memory release, which I covered in a separate piece when it launched, open-sourced a governed memory hub on 13 August. Asana has been quietly running the closed, platform-bound version, Agentic Work Management, with its AI Teammates since late last year. This piece is not another announcement recap. It is the comparison the announcements skip: what each system actually does when a memory needs correcting, deleting or adjudicating, and who inside an organisation gets to decide.

Key Takeaways - Shared memory turns a wrong fact from one user's annoyance into every agent's inheritance. The governance layer, not the retrieval quality, is now the load-bearing feature. - Tencent's Team Memory ships the most explicit access model (four visibility tiers, per-agent loadouts, private by default) but no documented correction or expiry process for a fact already consumed by other agents. - Asana's Agentic Work Management solves the confidential-leak case properly, by inheriting the Work Graph's existing permissions, but the memory lives inside Asana's platform and its correction semantics are opaque. - Zep's Graphiti is the only mainstream implementation with a principled answer to stale facts: it invalidates rather than deletes, keeping the history. But it governs one agent's memory, not a team's. - Nobody yet ships conflict resolution for the case where two agents have written contradicting facts about the same thing. That question is currently answered by "retrieval ranking," which is not an answer.

What happened

Within the first two weeks of August, shared agent memory went from research topic to shipping category. The two events worth anchoring on:

• On 13 August, Tencent Cloud announced Team Memory, the team-scale extension of its open-source TencentDB Agent Memory project. Conversations, documents, code graphs and distilled skills become governed team assets with owners, versions and a four-tier visibility model, assembled per agent role.

• A week earlier, VentureBeat's fireside chat with Asana CPO Arnab Bose gave the first real technical detail on Agentic Work Management (AWM), the shared-memory system behind Asana's AI Teammates, which Asana says is already in production with customers including FedEx.

Around them sits the open-source single-agent memory layer (Mem0, Zep's Graphiti, Letta), which is where most teams' actual memory infrastructure still lives. The interesting shift is that all of these now get evaluated against the same four questions. Who can read a memory? What happens when it's wrong? What happens when it's deleted? And what happens when two memories disagree?

Tencent Cloud shipped Team Memory, a governed shared-memory hub for agent teams, on 13 August 2026, per the announcement. Days earlier, Asana's CPO detailed Agentic Work Management, the shared-memory system behind its AI Teammates, in a VentureBeat interview published 3 August 2026.

The four questions, compared

The lazy framing for this category is "Tencent versus Asana," Chinese open-source versus American SaaS. That misses the actual shape of it. The real split is between systems that govern memory as documents with permissions and systems that govern memory as facts with lifecycles, and neither camp has both halves yet.

Read down the correction and conflict rows and the pattern is uncomfortable: the two cells that matter most are the two nobody has filled in.

Team Memory's own documentation distinguishes "who can use it, which version is valid, and which Agent should receive it," per Tencent's documentation as reported by VentureBeat. Zep's Graphiti invalidates stale facts rather than deleting them, per the project repository. Neither Tencent nor Asana publicly documents a correction or conflict-resolution process for shared memories already consumed by other agents.

What each system gets right

Tencent's contribution is the access model, and it deserves credit for being explicit where everyone else is vague. Every memory asset carries an owner, a version and a visibility tier (private, team, restricted, agent), new assets default to private, and agents are equipped with an "Agent Loadout" matched to their role rather than given the run of the hub. A Scout agent doing research gets the market-analysis assets; a Builder agent gets the code graph. That is memory treated as organisational infrastructure with a lock policy, and as VentureBeat's coverage noted, the documentation itself draws the line against plain RAG: retrieval answers what can be found, Team Memory also answers who can use it.

Asana's contribution is the leak boundary, and its example is the one that should be in every governance deck. If an executive's AI Teammate builds memory on a confidential M&A project, a colleague who later talks to the same Teammate must not inherit that context. Bose's answer, per the VentureBeat interview, is that AWM sits on Asana's 18-year-old Work Graph, so memory access inherits the same permissions as the underlying work: if you can't see the project, the agent's memory of the project isn't yours either. That is a genuinely hard problem solved by refusing to build a new permission system, and it only works because Asana already knows who can see what. Asana has talked about team-wide memory and enterprise controls since the AI Teammates announcement last September, but the M&A boundary is the first concrete mechanism.

Graphiti's contribution is the lifecycle. Most systems treat a wrong fact as a deletion problem. Graphiti treats it as a time problem: when a fact stops being true, the edge is invalidated and timestamped, not erased, so the agent can answer both "what is true now" and "what was true in March." For anything involving audit, that is the right primitive, and it is notable that it comes from the single-agent world rather than either of the new team systems.

Tencent ships the most explicit access tiers with private-by-default sharing; Asana scopes agent memory to existing Work Graph permissions so confidential-project memory cannot leak to uncleared colleagues, per Asana CPO Arnab Bose in VentureBeat; Zep's Graphiti invalidates stale facts with timestamps instead of deleting them, per its repository.

The unsolved middle: correction, conflict, propagation

Now the part both launch narratives skip. A wrong fact in a single-agent memory costs one user a repeated correction. A wrong fact in a shared store propagates to every agent that read it before anyone noticed, and none of the shipping systems documents a process for that. VentureBeat's launch coverage collected practitioners flagging the gap within hours: correction and expiry for consumed facts, the decision about what should never be written down at all, and the case where two teammates' agents have written contradicting facts about the same module and the shared store has to pick a winner. Single-agent memory drifts slowly. Shared memory drifts fast, because one stale write reaches people who never saw the session that produced it.

This is not an implementation nitpick that a point release fixes. A March 2026 paper, "Governed Memory: A Production Architecture for Multi-Agent Workflows," identifies governance fragmentation and silent quality degradation without feedback loops as structural risks of shared multi-agent memory generally, which is a polite academic way of saying the failure mode is baked into the architecture, not the vendor. And the security framing compounds it: OWASP's agentic threat guidance names memory poisoning as a distinct attack class, and a shared store is a shared blast radius. Asana's permission inheritance and Tencent's private-by-default tiers both limit who can read a poisoned or stale memory. Neither addresses what happens after a bad one has been read.

My honest read: correction and conflict resolution will end up working the way they do in every other shared information system, which is socially. A named owner per asset, a review habit, an expiry norm. The tools that win this category will be the ones that make that social process easy rather than the ones that promise to automate it away. I've seen this film with wikis, with CRMs, with feature flags. The governance features are the product, which is the same conclusion I reach in the agent governance piece, and the same reason "just add memory" is not a plan in agentic architecture work.

Practitioners responding to the Team Memory launch flagged correction, expiry and conflict resolution as undocumented gaps, per VentureBeat. The March 2026 "Governed Memory" paper identifies the same risks as structural to shared multi-agent memory, and OWASP's agentic AI threat guidance classifies memory poisoning as a distinct attack class.

What to do now

If you're evaluating shared agent memory this quarter, four steps, in order.

1. Today: write down your four answers before you demo anything: read scope, correction process, deletion semantics, conflict rule. Any vendor who can't match them feature by feature is telling you where their roadmap ends.

2. This week: run the M&A test. Create a memory under a confidential project, then ask the same agent a question as a user without that project's access. Asana designed for this explicitly; everyone else should be made to demonstrate it.

3. This month: poison something deliberately, in a sandbox. Write a plausible wrong fact into the shared store, let two agents consume it, then try to retract it. What you learn about propagation and cleanup in an afternoon is worth more than any architecture diagram.

4. Ongoing: assign owners. A memory asset without a named human responsible for its correctness is technical debt with a vector index.

If your memory needs are still single-agent, the calculus is different and lighter; the self-hosted agent piece covers that end of the trade-off.

FAQ

What is shared agent memory, in one sentence?

A persistent store of facts, procedures and context that multiple agents (and their humans) read from and write to, so the team stops re-briefing every agent from scratch, and starts inheriting each other's mistakes instead.

Is Tencent's Team Memory or Asana's AI Teammates more secure?

They answer different questions. Tencent ships the more granular, explicit access model (four tiers, per-agent loadouts, private by default) and you can self-host it, so data location is your choice. Asana's model is coarser but battle-tested, because it inherits workspace permissions that already govern confidential work. "Secure" here mostly means "scoped correctly for your org chart," and only you know that.

What happens when a shared memory is wrong?

Today, mostly nothing automatic. Tencent tracks versions and status but documents no correction or expiry process for consumed facts. Asana corrects behaviour through human feedback loops without documenting memory correction. Graphiti invalidates stale facts with timestamps, which is the best primitive available, but governs one agent's graph. Budget for a manual review process whichever you choose.

Can two agents' contradicting memories be reconciled automatically?

Not in any shipping system I can evidence. Current behaviour is that retrieval ranking picks one, which means the conflict is resolved invisibly, per query, by a similarity score. If your use case has facts that matter (regulatory, financial, safety), treat "whose memory wins" as a policy question you answer yourself, not a feature you wait for.

The bottom line

Shared memory is the right direction and an unfinished product. Tencent and Asana have independently proven the access-control half is buildable, one open and portable, one closed and permission-native, and that alone makes August a real milestone. But the correction, expiry and conflict half of the problem is currently documented by nobody and owned by default by you. Buy the access controls, plan the corrections yourself, and treat every shared memory as a fact the whole team has already acted on, because by the time you notice it, they have.

If you're working out where shared memory fits in your own agent stack, that's a conversation I have with clients regularly. Get in touch.

Sources

• Tencent Cloud, "TencentDB Agent Memory Releases Team Memory": https://www.tencentcloud.com/dynamic/news-details/101465 (published 2026-08-13, retrieved 2026-08-29)

• VentureBeat, "Tencent's Team Memory shares AI agent memory across a team, with no governance yet for when it's wrong": https://venturebeat.com/data/tencents-team-memory-shares-ai-agent-memory-across-a-team-with-no-governance-yet-for-when-its-wrong (published 2026-08-07, retrieved 2026-08-29)

• VentureBeat, "Asana's AI agents share memory across your company, but not your secrets": https://venturebeat.com/orchestration/asanas-ai-agents-share-memory-across-your-company-but-not-your-secrets (published 2026-08-03, retrieved 2026-08-29)

• Asana, Inc., "Asana Announces New AI Teammates": https://investors.asana.com/news-releases/news-release-details/asana-announces-new-ai-teammates-collaborative-agents-deliver/ (published 2025-09-25, retrieved 2026-08-29)

• TencentCloud, TencentDB-Agent-Memory repository: https://github.com/TencentCloud/TencentDB-Agent-Memory (retrieved 2026-08-29)

• Zep, Graphiti repository: https://github.com/getzep/graphiti (retrieved 2026-08-29)

• Mem0 repository: https://github.com/mem0ai/mem0 (retrieved 2026-08-29)

• OWASP, "Agentic AI Threats and Mitigations": https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/ (retrieved 2026-08-29)