Tencent sta ampliando il progetto open source TencentDB Agent Memory con una nuova architettura pensata per consentire a più agenti di intelligenza artificiale di utilizzare un contesto condiviso, superando il modello nel quale ogni agente conserva una memoria separata delle proprie interazioni. La nuova funzione, denominata Team Memory, trasforma la memoria da componente associato a un singolo agente a infrastruttura comune per gruppi di agenti specializzati, con meccanismi che stabiliscono quali informazioni possono essere consultate, da chi e in quale forma devono essere rese disponibili durante l’esecuzione dei task.
Agent Memory era nato per affrontare soprattutto il degrado delle prestazioni durante sessioni molto lunghe. Gli agenti che accumulano conversazioni, chiamate a strumenti, risultati di ricerca, frammenti di codice e altri output possono saturare rapidamente la finestra di contesto, aumentando il consumo di token e rendendo più difficile recuperare le informazioni effettivamente rilevanti. Tencent utilizza quindi una combinazione di memoria a breve termine simbolica e memoria a lungo termine stratificata, spostando parte dei dati fuori dal contesto principale e conservando nel prompt soltanto rappresentazioni più compatte delle informazioni necessarie. Nei benchmark pubblicati dall’azienda, l’integrazione con OpenClaw ha ridotto il consumo di token fino al 61,38% e ha aumentato il tasso di completamento dei task fino al 51,52% in termini relativi, a seconda del benchmark utilizzato.
La componente dedicata alla memoria a lungo termine organizza invece le informazioni in livelli progressivamente più sintetici. La struttura comprende conversazioni originali, fatti atomici estratti dalle interazioni, rappresentazioni di scenari ricorrenti e una memoria di livello superiore che descrive elementi stabili relativi all’utente, alle sue preferenze e alle modalità di lavoro. Ogni sintesi mantiene un collegamento con i livelli sottostanti, rendendo possibile risalire dalla memoria utilizzata dall’agente fino alle informazioni originarie da cui è stata derivata. Tencent presenta questa tracciabilità come uno degli elementi necessari per applicazioni aziendali nelle quali le informazioni memorizzate devono poter essere controllate, corrette o sottoposte ad audit.
La capacità di costruire una rappresentazione stabile dell’utente viene misurata attraverso PersonaMem, benchmark dedicato alla comprensione delle preferenze e delle caratteristiche emerse attraverso interazioni prolungate. Nei test dichiarati da Tencent, l’accuratezza passa da circa il 48% con la memoria nativa dell’agente al 76% utilizzando Agent Memory, con un miglioramento relativo vicino al 59%. La versione più dettagliata dei risultati pubblicati da Tencent Cloud indica un aumento dal 47,85% al 76,10% nell’accuratezza complessiva e dal 29,63% al 79,07% nel recupero dei fatti relativi alla persona. I dati derivano da test interni dell’azienda e descrivono quindi le prestazioni osservate all’interno della configurazione utilizzata da Tencent.
Team Memory estende questa impostazione a un gruppo di agenti. Il sistema non distribuisce semplicemente lo stesso blocco di testo all’interno della finestra di contesto di tutti i componenti, ma mantiene un insieme centrale di risorse che possono essere assegnate selettivamente agli agenti in funzione del loro ruolo e del task da svolgere. Il repository descrive quattro categorie principali di asset condivisibili: Chat Memory, Skill, LLM-Wiki e Code-Graph. In questo modo la memoria diventa una risorsa strutturata e riutilizzabile anziché una semplice raccolta di frammenti recuperati attraverso ricerca vettoriale.
Chat Memory conserva fatti, decisioni, preferenze e informazioni derivate dalle precedenti interazioni, consentendo agli agenti di recuperare il contesto già acquisito senza chiedere nuovamente all’utente gli stessi dettagli. La memoria viene organizzata progressivamente fino a produrre rappresentazioni più stabili, utili nelle interazioni di lunga durata. L’obiettivo è separare gli elementi temporanei presenti in una conversazione dalle informazioni che possono mantenere validità anche nelle sessioni successive, limitando contemporaneamente la quantità di testo che deve essere reinserita nel contesto del modello.
La categoria Skill è invece destinata alle procedure operative apprese durante il completamento dei task. Una sequenza che si è dimostrata efficace può essere trasformata in una risorsa riutilizzabile, sottoposta a revisione e versionata prima di diventare disponibile per altri agenti. La memoria viene quindi utilizzata anche per accumulare esperienza procedurale: un agente non deve soltanto ricordare che cosa è successo in passato, ma può recuperare il modo nel quale un determinato problema è stato precedentemente risolto e applicare la stessa procedura quando incontra condizioni analoghe.
LLM-Wiki organizza documentazione, specifiche e conoscenza aziendale sotto forma di pagine strutturate e collegate. L’obiettivo è rendere grandi raccolte documentali più direttamente navigabili dagli agenti, evitando di affidarsi esclusivamente all’inserimento di frammenti recuperati dinamicamente attraverso una pipeline RAG. Gli agenti possono consultare una struttura che conserva relazioni esplicite tra concetti e documenti, ottenendo un contesto più stabile per attività che richiedono la comprensione continuativa di prodotti, processi o specifiche tecniche.
Code-Graph applica la stessa logica alle codebase. File, funzioni, classi, simboli e relazioni di chiamata vengono indicizzati in un grafo che consente all’agente di esaminare le dipendenze del software e valutare quali componenti potrebbero essere coinvolti da una modifica. Questa rappresentazione è particolarmente utile nei sistemi di coding agent, nei quali una variazione apparentemente locale può influire su numerosi moduli collegati. Il grafo permette quindi di fornire all’agente un contesto strutturale della codebase senza caricare indiscriminatamente grandi quantità di codice nella finestra del modello.
La differenza rispetto a un sistema RAG tradizionale riguarda soprattutto la gestione delle risorse dopo il recupero. Una pipeline RAG permette di determinare quali informazioni risultano rilevanti rispetto a una query, mentre Team Memory aggiunge regole relative alla proprietà della risorsa, alla versione utilizzabile, alla visibilità e al tipo di agente al quale quella conoscenza deve essere assegnata. Il sistema può quindi fornire contesti differenti a componenti differenti dello stesso team: un agente incaricato della ricerca può ricevere documenti di mercato e analisi della concorrenza, mentre un agente dedicato allo sviluppo software può ricevere Code-Graph, specifiche del prodotto e procedure tecniche, senza che entrambi abbiano automaticamente accesso all’intero patrimonio informativo.
Questa selezione costituisce il principio dell’Agent Loadout, attraverso il quale ogni agente viene equipaggiato con le risorse necessarie al proprio compito. L’approccio riduce la quantità di informazioni trasferite a ciascun modello e limita l’esposizione di dati non pertinenti al ruolo svolto. Nei sistemi multi-agente, infatti, l’aumento della memoria disponibile non produce necessariamente risultati migliori: fornire a ogni componente tutto il contesto esistente aumenta i token utilizzati, può peggiorare il recupero delle informazioni realmente importanti e amplia inutilmente il numero di agenti che possono accedere a dati riservati.
Per questo motivo Team Memory integra un modello di controllo dell’accesso applicato alle singole risorse. Gli asset possono rimanere privati, essere condivisi con il team oppure essere assegnati soltanto a determinati utenti, ruoli o agenti. La configurazione predefinita mantiene le nuove risorse private, rendendo la condivisione un’operazione esplicita. Un’informazione prodotta durante il lavoro di un agente non entra quindi automaticamente nel patrimonio di conoscenza accessibile a tutti gli altri componenti del sistema.
L’introduzione di una memoria condivisa rende però più importante un problema differente dal semplice controllo dell’accesso: la qualità delle informazioni che vengono scritte nel sistema. Una memoria errata mantenuta da un singolo agente può compromettere le sue successive risposte; quando la stessa memoria viene resa disponibile a un gruppo, l’errore può essere recuperato da numerosi agenti e influenzare attività che non hanno alcun rapporto con la sessione nella quale l’informazione sbagliata è stata originariamente prodotta. La gestione della scrittura diventa quindi importante quanto quella del recupero.
La documentazione disponibile permette di identificare proprietà, stato e versioni delle risorse e l’architettura stratificata mantiene collegamenti con le informazioni dalle quali vengono ricavate le memorie sintetiche. Rimangono però centrali i meccanismi attraverso i quali un sistema deve stabilire che una conoscenza non è più valida, sostituire una precedente versione, risolvere informazioni incompatibili prodotte da agenti differenti e propagare la correzione a tutti i componenti che hanno già utilizzato il dato. In un ambiente multi-agente il problema non riguarda soltanto la cancellazione fisica di un record, perché copie o sintesi della stessa informazione possono essere già state incorporate in altri livelli della memoria.
Le difficoltà non sono specifiche dell’implementazione di Tencent. Le ricerche recenti sulle architetture di memoria governata per sistemi multi-agente identificano tra i principali rischi strutturali la frammentazione della governance, la propagazione di informazioni obsolete, la persistenza delle contraddizioni e la perdita della provenienza dei dati. Un lavoro del 2026 dedicato alla Governed Memory individua inoltre cinque problemi ricorrenti nelle implementazioni aziendali: silos di memoria tra workflow agentici, regole di governance differenti tra strumenti e team, informazioni non strutturate difficili da riutilizzare, distribuzione ridondante dello stesso contesto e degrado della qualità non rilevato in assenza di cicli di feedback.
Un’altra area critica riguarda la cancellazione. La memoria persistente degli agenti non contiene necessariamente una singola copia di un’informazione: un dato presente nella conversazione originaria può essere successivamente condensato in un fatto, incorporato in un riepilogo o utilizzato per aggiornare una rappresentazione della persona. Ricerche sulla deployment-time memorization hanno mostrato che eliminare soltanto il dato grezzo può lasciare recuperabili informazioni derivate presenti nei livelli successivi della pipeline; per ottenere una cancellazione effettiva è quindi necessario propagare l’eliminazione oppure applicare meccanismi di redazione a tutte le rappresentazioni costruite a partire dalla fonte iniziale.
La memoria multi-agente aggiunge anche il problema delle contraddizioni. Due agenti possono osservare lo stesso elemento in momenti differenti e memorizzare versioni incompatibili: per esempio, un agente può registrare una specifica tecnica successivamente modificata da un altro team, mentre un secondo agente inserisce nella memoria la nuova versione senza eliminare quella precedente. Se entrambe vengono recuperate come informazioni valide, il sistema deve disporre di criteri temporali, di provenienza o di autorità per stabilire quale utilizzare. Le architetture più recenti dedicate alla shared memory stanno quindi introducendo meccanismi espliciti di temporal supersession, provenance tracking e policy-governed propagation proprio per evitare che il semplice aumento della condivisione trasformi la memoria in una fonte crescente di incoerenze.
Team Memory si colloca in un settore nel quale negli ultimi mesi sono comparsi diversi approcci alla memoria persistente. Framework e strumenti precedenti si sono concentrati prevalentemente sulla capacità di un singolo agente di ricordare informazioni tra sessioni successive o di mantenere un contesto sintetico durante task molto lunghi. Un secondo gruppo di soluzioni ha sviluppato context layer aziendali destinati a offrire agli agenti una vista comune dei dati organizzativi. L’architettura di Tencent unisce parte di questi due approcci, perché conserva memoria derivata dalle interazioni e contemporaneamente la trasforma in una risorsa condivisibile e governata tra più agenti.
La conseguenza principale riguarda il funzionamento dei team agentici. In assenza di una memoria condivisa, ogni componente deve ricostruire autonomamente una parte della conoscenza oppure riceverla nuovamente dall’utente, da un altro agente o dall’applicazione che orchestra il workflow. Con Team Memory un risultato prodotto durante un task può diventare un asset persistente assegnabile successivamente ad altri componenti, consentendo al sistema di accumulare conoscenza attraverso attività successive anziché ripartire ogni volta da un contesto sostanzialmente vuoto.
Lo stesso meccanismo richiede però che la memoria venga trattata come un’infrastruttura governata e non come un archivio nel quale conservare automaticamente qualsiasi informazione generata dagli agenti. Provenienza, versionamento, accesso, correzione, scadenza e gestione delle contraddizioni diventano proprietà operative del sistema, perché una memoria condivisa aumenta contemporaneamente il valore delle informazioni corrette e l’impatto di quelle sbagliate. Team Memory porta quindi la memoria degli agenti da una funzione di personalizzazione individuale a un livello infrastrutturale destinato ai sistemi multi-agente, nel quale il problema non consiste più soltanto nel ricordare più informazioni, ma nel determinare quali informazioni possano diventare conoscenza comune e in quali condizioni debbano continuare a essere considerate valide.