La memoria condivisa degli agenti ha un problema di access control, e nessuno l'ha risolto

Ecco una tesi a cui un anno fa avrei resistito: la parte difficile della memoria degli agenti non è mai stata far ricordare qualcosa a un agente. È decidere cosa succede quando cinquanta agenti ricordano la stessa cosa sbagliata. La memoria single-agent è un problema di convenience. Nel momento in cui la memoria viene condivisa da un team, diventa un problema organizzativo di access control, con semantics di correction, deletion e conflict, e sono precisamente le feature in cui i prodotti attuali sono più deboli.

Due vendor hanno consegnato risposte nel giro di poche settimane. Il release Team Memory di Tencent Cloud, che ho trattato in un articolo separato al lancio, ha reso open source un governed memory hub il 13 agosto. Asana esegue silenziosamente dalla fine dell'anno scorso la versione chiusa e platform-bound, Agentic Work Management, con i suoi AI Teammates. Questo pezzo non è un altro announcement recap. È il confronto che gli annunci saltano: cosa fa davvero ogni sistema quando una memoria deve essere corretta, cancellata o adjudicated, e chi dentro l'organizzazione decide.

Punti chiave - Shared memory trasforma un fact sbagliato dalla seccatura di un user nell'eredità di ogni agente. La governance layer, non la retrieval quality, è ora la feature portante. - Team Memory di Tencent offre l'access model più esplicito, quattro visibility tier, per-agent loadout, private by default, ma nessun processo documentato di correction o expiry per un fact già consumato da altri agenti. - Agentic Work Management di Asana risolve correttamente il caso confidential leak ereditando i permission esistenti del Work Graph, ma la memoria vive nella piattaforma Asana e le correction semantics sono opache. - Graphiti di Zep è l'unica implementation mainstream con una risposta principled agli stale facts: invalida invece di cancellare e mantiene la history. Ma governa la memoria di un agente, non di un team. - Nessuno ship ancora conflict resolution per il caso in cui due agenti abbiano scritto facts contraddittori sulla stessa cosa. Oggi la domanda viene risolta dal "retrieval ranking", che non è una risposta.

Cosa è successo

Nelle prime due settimane di agosto, shared agent memory è passata da research topic a shipping category. Due eventi sono gli anchor utili:

• Il 13 agosto Tencent Cloud ha annunciato Team Memory, estensione a scala di team del progetto open source TencentDB Agent Memory. Conversations, documents, code graphs e distilled skills diventano governed team assets con owner, version e un visibility model a quattro livelli, assemblati per agent role.

• Una settimana prima, il fireside chat di VentureBeat con Arnab Bose, CPO di Asana, ha dato i primi veri dettagli tecnici su Agentic Work Management, AWM, il sistema shared-memory dietro gli AI Teammates di Asana, che Asana dice essere già in production con clienti tra cui FedEx.

Attorno c'è il layer open source single-agent memory, Mem0, Graphiti di Zep, Letta, dove vive ancora la maggior parte dell'infrastruttura di memoria reale dei team. Il cambiamento interessante è che tutti questi sistemi vengono ora valutati sulle stesse quattro domande. Chi può leggere una memoria? Cosa succede quando è sbagliata? Cosa succede quando viene cancellata? E cosa succede quando due memorie sono in conflitto?

Tencent Cloud ha ship Team Memory, un governed shared-memory hub per team di agenti, il 13 agosto 2026, secondo l'annuncio. Pochi giorni prima il CPO di Asana aveva dettagliato Agentic Work Management, il sistema shared-memory dietro AI Teammates, in un'intervista VentureBeat pubblicata il 3 agosto 2026.

Le quattro domande, confrontate

Il framing pigro di questa categoria è "Tencent versus Asana", open source cinese contro SaaS americano. Non coglie la forma reale. La vera divisione è tra sistemi che governano la memoria come documenti con permission e sistemi che la governano come facts con lifecycle, e nessuno dei due gruppi ha ancora entrambe le metà.

Leggete le righe correction e conflict e il pattern è scomodo: le due cell che contano di più sono esattamente le due che nessuno ha riempito.

La documentazione di Team Memory distingue "who can use it, which version is valid, and which Agent should receive it", secondo la documentazione Tencent riportata da VentureBeat. Graphiti di Zep invalida gli stale facts invece di cancellarli, secondo il repository. Né Tencent né Asana documentano pubblicamente un processo di correction o conflict resolution per shared memory già consumate da altri agenti.

Cosa fa bene ogni sistema

Il contributo di Tencent è l'access model, e merita credito per essere esplicito dove tutti gli altri sono vaghi. Ogni memory asset porta owner, version e visibility tier, private, team, restricted, agent; i nuovi asset defaultano a private; e gli agenti ricevono un "Agent Loadout" adatto al proprio role invece di accesso libero all'hub. Un Scout agent che fa research riceve i market-analysis asset; un Builder agent riceve il code graph. È memoria trattata come infrastruttura organizzativa con lock policy e, come ha osservato VentureBeat, la documentazione stessa traccia il confine con plain RAG: retrieval risponde cosa può essere trovato, Team Memory risponde anche chi può usarlo.

Il contributo di Asana è la leak boundary, e il suo esempio dovrebbe stare in ogni governance deck. Se l'AI Teammate di un executive costruisce memoria su un progetto M&A confidential, un collega che parla dopo con lo stesso Teammate non deve ereditare quel context. La risposta di Bose, secondo l'intervista VentureBeat, è che AWM si appoggia al Work Graph di Asana, vecchio di 18 anni, così memory access eredita gli stessi permission del lavoro sottostante: se non potete vedere il progetto, neppure la memoria dell'agente sul progetto è vostra. È un problema realmente difficile risolto rifiutando di costruire un nuovo permission system, e funziona solo perché Asana sa già chi può vedere cosa. Asana parla di team-wide memory ed enterprise controls dall'annuncio AI Teammates dello scorso settembre, ma la M&A boundary è il primo meccanismo concreto.

Il contributo di Graphiti è il lifecycle. La maggior parte dei sistemi tratta un fact sbagliato come problema di deletion. Graphiti lo tratta come problema temporale: quando un fact smette di essere vero, l'edge viene invalidato e timestamped, non cancellato, così l'agente può rispondere sia "cosa è vero ora" sia "cosa era vero a marzo". Per tutto ciò che implica audit è la primitive giusta, ed è notevole che venga dal mondo single-agent anziché dai nuovi team system.

Tencent ship gli access tier più espliciti con sharing private-by-default; Asana scope agent memory agli existing Work Graph permissions così la memoria di un confidential project non leak verso colleghi senza accesso, secondo Asana CPO Arnab Bose in VentureBeat; Graphiti di Zep invalida gli stale facts con timestamp invece di cancellarli, secondo il repository.

Il centro irrisolto: correction, conflict, propagation

Ora la parte che entrambe le launch narrative saltano. Un fact sbagliato nella memoria single-agent costa a un user una correction ripetuta. Un fact sbagliato in uno shared store si propaga a ogni agente che lo ha letto prima che qualcuno se ne accorga, e nessuno dei sistemi shipping documenta un processo per questo. La coverage di VentureBeat sul launch ha raccolto practitioner che segnalavano il gap entro poche ore: correction ed expiry per facts consumati, decisione su cosa non dovrebbe mai essere scritto, e il caso in cui agenti di due teammate hanno scritto facts contraddittori sullo stesso module e lo shared store deve scegliere un vincitore. Single-agent memory drift lentamente. Shared memory drift rapidamente, perché uno stale write raggiunge persone che non hanno mai visto la session che lo ha prodotto.

Non è un implementation nitpick risolvibile con point release. Un paper di marzo 2026, "Governed Memory: A Production Architecture for Multi-Agent Workflows", identifica governance fragmentation e silent quality degradation senza feedback loop come rischi strutturali della shared multi-agent memory, modo accademico educato di dire che il failure mode è baked into the architecture, non nel vendor. E il framing security lo amplifica: la guidance agentic di OWASP nomina memory poisoning come attack class distinta, e uno shared store è uno shared blast radius. Permission inheritance di Asana e tier private-by-default di Tencent limitano chi può leggere una memoria poisoned o stale. Nessuno affronta cosa succede dopo che una memoria cattiva è stata letta.

La mia lettura: correction e conflict resolution finiranno per funzionare come in ogni altro shared information system, socialmente. Un owner nominato per asset, un'abitudine di review, una norma di expiry. Le tool che vinceranno questa categoria saranno quelle che rendono facile il processo sociale, non quelle che promettono di automatizzarlo via. Ho visto questo film con wiki, CRM e feature flag. Le governance feature sono il prodotto, stessa conclusione del pezzo agent governance, e stesso motivo per cui "just add memory" non è un piano nel lavoro di agentic architecture.

I practitioner che hanno risposto al launch Team Memory hanno segnalato correction, expiry e conflict resolution come gap non documentati, secondo VentureBeat. Il paper "Governed Memory" di marzo 2026 identifica gli stessi rischi come strutturali alla shared multi-agent memory, e la guidance OWASP sulle agentic AI threat classifica memory poisoning come attack class distinta.

Cosa fare adesso

Se state valutando shared agent memory questo trimestre, quattro step, in ordine.

1. Oggi: scrivete le vostre quattro risposte prima di qualsiasi demo: read scope, correction process, deletion semantics, conflict rule. Qualsiasi vendor che non sappia matcharle feature per feature vi dice dove finisce la roadmap.

2. Questa settimana: eseguite il test M&A. Create una memoria sotto un progetto confidential, poi fate una domanda allo stesso agente come user senza accesso a quel progetto. Asana è designed esplicitamente per questo; tutti gli altri devono dimostrarlo.

3. Questo mese: poison qualcosa deliberatamente, in sandbox. Scrivete un fact plausibile ma falso nello shared store, lasciate che due agenti lo consumino, poi provate a ritirarlo. Ciò che imparate in un pomeriggio su propagation e cleanup vale più di ogni architecture diagram.

4. Continuamente: assegnate owner. Un memory asset senza un human nominato responsabile della correttezza è technical debt con vector index.

Se i bisogni di memory restano single-agent, il calcolo è diverso e più leggero; il pezzo self-hosted agent copre quel lato del trade-off.

FAQ

Cos'è shared agent memory, in una frase?

Uno store persistente di facts, procedure e context che più agenti, e i loro human, leggono e scrivono, così il team smette di re-briefare ogni agente da zero e inizia a ereditare gli errori degli altri.

Team Memory di Tencent o AI Teammates di Asana è più secure?

Rispondono a domande diverse. Tencent ship l'access model più granulare ed esplicito, quattro tier, per-agent loadout, private by default, e potete self-hostarlo, quindi data location è scelta vostra. Il model di Asana è più grossolano ma battle-tested, perché eredita workspace permissions che governano già il lavoro confidential. "Secure" qui significa soprattutto "scoped correttamente per il vostro org chart", e solo voi lo sapete.

Cosa succede quando una shared memory è sbagliata?

Oggi, quasi niente in automatico. Tencent track versions e status ma non documenta correction o expiry per facts consumati. Asana corregge behaviour tramite human feedback loop senza documentare memory correction. Graphiti invalida stale facts con timestamp, la migliore primitive disponibile, ma governa il graph di un singolo agente. Mettete a budget un processo manuale di review qualunque cosa scegliate.

Le memorie contraddittorie di due agenti possono essere reconciled automaticamente?

Non in nessun shipping system per cui riesca a trovare evidence. Il behaviour attuale è che retrieval ranking ne sceglie una, quindi il conflict viene risolto invisibilmente, per query, da un similarity score. Se il vostro use case contiene facts che contano, regulatory, financial, safety, trattate "quale memory vince" come policy question a cui rispondete voi, non feature da aspettare.

In sintesi

Shared memory è la direzione giusta e un prodotto incompleto. Tencent e Asana hanno dimostrato indipendentemente che la metà access-control è buildable, una open e portable, l'altra chiusa e permission-native, e già questo rende agosto un milestone reale. Ma la metà correction, expiry e conflict non è documentata da nessuno e per default è vostra. Comprate gli access control, pianificate da soli le correction e trattate ogni shared memory come un fact su cui tutto il team ha già agito, perché quando ve ne accorgerete, probabilmente sarà così.

Se state decidendo dove shared memory entra nel vostro agent stack, è una conversazione che faccio regolarmente con i clienti. Contattatemi.

Fonti

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

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

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

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

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