La mémoire partagée des agents a un problème d’access control, et personne ne l’a résolu

Voici une affirmation que j’aurais rejetée il y a un an : la difficulté de l’agent memory n’a jamais été de faire en sorte qu’un agent se souvienne. C’est de décider ce qui se passe lorsque cinquante agents se souviennent de la même chose fausse. La mémoire single-agent est un problème de convenience. Dès que la mémoire est partagée à travers une équipe, elle devient un problème organisationnel d’access control, avec des semantics de correction, deletion et conflict, et ce sont précisément les features où les produits actuels sont les plus minces.

Deux vendors ont livré des réponses à quelques semaines d’intervalle. Le release Team Memory de Tencent Cloud, que j’ai couvert dans un article séparé au lancement, a open-sourcé un governed memory hub le 13 août. Asana exploite discrètement depuis la fin de l’année dernière la version fermée et platform-bound, Agentic Work Management, avec ses AI Teammates. Ce texte n’est pas un nouvel announcement recap. C’est la comparaison que les annonces omettent : ce que fait réellement chaque système quand une mémoire doit être corrigée, supprimée ou adjudicated, et qui dans une organisation décide.

Points clés - Shared memory transforme un fact faux d’une gêne pour un user en héritage de tous les agents. La governance layer, pas la retrieval quality, devient la feature structurante. - Team Memory de Tencent livre le modèle d’accès le plus explicite, quatre visibility tiers, per-agent loadouts, private by default, mais aucun processus documenté de correction ou d’expiry pour un fact déjà consommé par d’autres agents. - Agentic Work Management d’Asana résout correctement le cas du confidential leak en héritant des permissions existantes du Work Graph, mais la mémoire vit dans la plateforme Asana et ses correction semantics restent opaques. - Graphiti de Zep est la seule implementation mainstream avec une réponse de principe aux stale facts : il invalide au lieu de supprimer et conserve l’historique. Mais il gouverne la mémoire d’un agent, pas d’une équipe. - Personne ne ship encore de conflict resolution pour le cas où deux agents ont écrit des facts contradictoires sur la même chose. La question est actuellement résolue par "retrieval ranking", ce qui n’est pas une réponse.

Ce qui s’est passé

Dans les deux premières semaines d’août, shared agent memory est passé de research topic à shipping category. Deux événements servent d’ancrage :

• Le 13 août, Tencent Cloud a annoncé Team Memory, l’extension à l’échelle équipe de son projet open source TencentDB Agent Memory. Conversations, documents, code graphs et distilled skills deviennent des governed team assets avec owners, versions et un visibility model à quatre niveaux, assemblés selon le role de chaque agent.

• Une semaine plus tôt, le fireside chat VentureBeat avec Arnab Bose, CPO d’Asana, a donné les premiers vrais détails techniques sur Agentic Work Management, AWM, le système shared-memory derrière les AI Teammates d’Asana, qu’Asana dit déjà en production chez des clients dont FedEx.

Autour d’eux se trouve la couche open source single-agent memory, Mem0, Graphiti de Zep, Letta, où vit encore la majeure partie de l’infrastructure mémoire réelle des équipes. Le shift intéressant est que tous ces systèmes sont maintenant évalués avec les mêmes quatre questions. Qui peut lire une mémoire ? Que se passe-t-il quand elle est fausse ? Que se passe-t-il lorsqu’elle est supprimée ? Et que se passe-t-il quand deux mémoires sont en désaccord ?

Tencent Cloud a livré Team Memory, un governed shared-memory hub pour équipes d’agents, le 13 août 2026, selon l’annonce. Quelques jours plus tôt, le CPO d’Asana détaillait Agentic Work Management, le système shared-memory derrière AI Teammates, dans une interview VentureBeat publiée le 3 août 2026.

Les quatre questions, comparées

Le framing paresseux de cette catégorie est "Tencent versus Asana", open source chinois contre SaaS américain. Cela rate la vraie structure. La vraie séparation est entre les systèmes qui gouvernent la mémoire comme des documents avec permissions et ceux qui la gouvernent comme des facts avec lifecycles, et aucun camp ne possède encore les deux moitiés.

Lisez les lignes correction et conflict et le pattern est inconfortable : les deux cells qui comptent le plus sont les deux que personne n’a remplies.

La documentation de Team Memory distingue "who can use it, which version is valid, and which Agent should receive it", selon la documentation Tencent rapportée par VentureBeat. Graphiti de Zep invalide les stale facts plutôt que de les supprimer, selon le repository. Ni Tencent ni Asana ne documentent publiquement un processus de correction ou de conflict resolution pour des shared memories déjà consommées par d’autres agents.

Ce que chaque système fait bien

La contribution de Tencent est l’access model, et il mérite du crédit pour être explicite là où les autres restent vagues. Chaque memory asset porte un owner, une version et un visibility tier, private, team, restricted, agent ; les nouveaux assets defaultent sur private ; et les agents reçoivent un "Agent Loadout" correspondant à leur role plutôt qu’un accès libre au hub. Un Scout agent de research reçoit les market-analysis assets ; un Builder agent reçoit le code graph. C’est de la mémoire traitée comme infrastructure organisationnelle avec lock policy, et comme VentureBeat l’a noté, la documentation trace elle-même la frontière avec plain RAG : retrieval répond à ce qui peut être trouvé, Team Memory répond aussi à qui peut l’utiliser.

La contribution d’Asana est la leak boundary, et son exemple devrait figurer dans chaque governance deck. Si l’AI Teammate d’un executive construit une mémoire sur un projet M&A confidential, un collègue qui parle ensuite au même Teammate ne doit pas hériter ce context. La réponse de Bose, selon l’interview VentureBeat, est qu’AWM repose sur le Work Graph d’Asana vieux de 18 ans, donc memory access hérite des mêmes permissions que le travail sous-jacent : si vous ne pouvez pas voir le projet, la mémoire de l’agent sur le projet ne vous appartient pas non plus. C’est un problème vraiment difficile résolu en refusant de construire un nouveau permission system, et cela ne fonctionne que parce qu’Asana sait déjà qui peut voir quoi. Asana parle de team-wide memory et enterprise controls depuis l’annonce AI Teammates de septembre dernier, mais la M&A boundary est le premier mécanisme concret.

La contribution de Graphiti est le lifecycle. La plupart des systèmes traitent un mauvais fact comme un problème de deletion. Graphiti le traite comme un problème temporel : lorsqu’un fact cesse d’être vrai, l’edge est invalidé et timestamped, pas effacé, ce qui permet à l’agent de répondre à la fois "qu’est-ce qui est vrai maintenant" et "qu’est-ce qui était vrai en mars". Pour tout ce qui implique audit, c’est la bonne primitive, et il est notable qu’elle vienne du monde single-agent plutôt que des nouveaux team systems.

Tencent ship les access tiers les plus explicites avec sharing private-by-default ; Asana scope agent memory aux existing Work Graph permissions pour qu’une mémoire confidential-project ne leak pas vers des collègues non autorisés, selon Asana CPO Arnab Bose dans VentureBeat ; Graphiti de Zep invalide les stale facts avec timestamps au lieu de les supprimer, selon son repository.

Le milieu non résolu : correction, conflict, propagation

Voici maintenant la partie que les deux launch narratives omettent. Un mauvais fact dans une mémoire single-agent coûte à un user une correction répétée. Un mauvais fact dans un shared store se propage à tous les agents qui l’ont lu avant que quelqu’un ne le remarque, et aucun système shipping ne documente un processus pour cela. La launch coverage de VentureBeat a recueilli des practitioners signalant le gap en quelques heures : correction et expiry des facts consommés, décision sur ce qui ne devrait jamais être écrit du tout, et cas où deux agents de teammates ont écrit des facts contradictoires sur le même module et où le shared store doit choisir un gagnant. Single-agent memory drift lentement. Shared memory drift vite, parce qu’un stale write atteint des personnes qui n’ont jamais vu la session qui l’a produit.

Ce n’est pas un implementation nitpick qu’un point release corrige. Un paper de mars 2026, "Governed Memory: A Production Architecture for Multi-Agent Workflows", identifie governance fragmentation et silent quality degradation sans feedback loops comme risques structurels de la shared multi-agent memory en général, une façon académique polie de dire que le failure mode est baked into the architecture, pas le vendor. Et le framing security l’amplifie : la guidance agentic d’OWASP nomme memory poisoning comme attack class distincte, et un shared store est un shared blast radius. L’inheritance de permissions d’Asana et les tiers private-by-default de Tencent limitent tous deux qui peut lire une mémoire poisoned ou stale. Aucun ne traite ce qui se passe après qu’une mauvaise mémoire a été lue.

Ma lecture : correction et conflict resolution finiront par fonctionner comme dans tous les autres shared information systems, socialement. Un owner nommé par asset, une habitude de review, une norme d’expiry. Les tools qui gagneront cette catégorie seront celles qui rendent ce processus social facile plutôt que celles qui promettent de l’automatiser. J’ai vu ce film avec les wikis, les CRMs, les feature flags. Les governance features sont le produit, même conclusion que dans l’article agent governance, et même raison pour laquelle "just add memory" n’est pas un plan dans agentic architecture.

Les practitioners réagissant au launch Team Memory ont signalé correction, expiry et conflict resolution comme gaps non documentés, selon VentureBeat. Le paper "Governed Memory" de mars 2026 identifie les mêmes risques comme structurels pour la shared multi-agent memory, et la guidance OWASP sur les agentic AI threats classe memory poisoning comme attack class distincte.

Que faire maintenant

Si vous évaluez shared agent memory ce trimestre, quatre étapes, dans l’ordre.

1. Aujourd’hui : écrivez vos quatre réponses avant toute demo : read scope, correction process, deletion semantics, conflict rule. Tout vendor incapable de les faire correspondre feature par feature vous indique où finit sa roadmap.

2. Cette semaine : faites le test M&A. Créez une mémoire dans un projet confidential, puis posez une question au même agent en tant que user sans access au projet. Asana a été conçu explicitement pour cela ; tous les autres doivent le démontrer.

3. Ce mois-ci : poison quelque chose volontairement, dans une sandbox. Écrivez un fact faux mais plausible dans le shared store, laissez deux agents le consommer, puis essayez de le retirer. Ce que vous apprenez en un après-midi sur propagation et cleanup vaut plus que n’importe quel architecture diagram.

4. En continu : assignez des owners. Un memory asset sans humain nommé responsable de sa correction est une technical debt avec vector index.

Si vos besoins mémoire restent single-agent, le calcul est différent et plus léger ; l’article self-hosted agent couvre ce côté du trade-off.

FAQ

Qu’est-ce que shared agent memory, en une phrase ?

Un store persistant de facts, procedures et context que plusieurs agents, et leurs humains, lisent et écrivent, afin que l’équipe cesse de re-briefer chaque agent depuis zéro et commence à hériter des erreurs des autres.

Team Memory de Tencent ou AI Teammates d’Asana est-il plus secure ?

Ils répondent à des questions différentes. Tencent ship le modèle d’accès plus granulaire et explicite, quatre tiers, per-agent loadouts, private by default, et vous pouvez self-host, donc data location est votre choix. Le modèle d’Asana est plus grossier mais battle-tested, car il hérite des workspace permissions qui gouvernent déjà le travail confidential. "Secure" signifie ici surtout "scoped correctement pour votre org chart", et vous seul connaissez cela.

Que se passe-t-il lorsqu’une shared memory est fausse ?

Aujourd’hui, presque rien d’automatique. Tencent track versions et status mais ne documente aucun processus de correction ou expiry pour des facts consommés. Asana corrige le behaviour via human feedback loops sans documenter la memory correction. Graphiti invalide les stale facts avec timestamps, la meilleure primitive disponible, mais gouverne le graph d’un seul agent. Prévoyez un manual review process quel que soit votre choix.

Deux mémoires contradictoires d’agents peuvent-elles être reconciled automatiquement ?

Pas dans un shipping system pour lequel je peux apporter de l’evidence. Le behaviour actuel est que retrieval ranking en choisit une, ce qui signifie que le conflict est résolu invisiblement, par query, par un similarity score. Si votre use case contient des facts qui comptent, regulatory, financial, safety, traitez "quelle mémoire gagne" comme une policy question à laquelle vous répondez vous-même, pas une feature que vous attendez.

En bref

Shared memory est la bonne direction et un produit inachevé. Tencent et Asana ont indépendamment prouvé que la moitié access-control est buildable, l’une ouverte et portable, l’autre fermée et permission-native, et cela suffit à faire d’août un vrai milestone. Mais la moitié correction, expiry et conflict n’est documentée par personne et vous appartient par défaut. Achetez les access controls, planifiez vous-même les corrections et traitez chaque shared memory comme un fact sur lequel toute l’équipe a déjà agi, car lorsque vous le remarquerez, ce sera probablement le cas.

Si vous cherchez où shared memory s’insère dans votre agent stack, c’est une conversation que j’ai régulièrement avec mes clients. Contactez-moi.

Sources

• Tencent Cloud, "TencentDB Agent Memory Releases Team Memory": https://www.tencentcloud.com/dynamic/news-details/101465 (publié 2026-08-13, consulté 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 (publié 2026-08-07, consulté 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 (publié 2026-08-03, consulté 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/ (publié 2025-09-25, consulté 2026-08-29)

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

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

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

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