Google Cloud ha rilasciato un «memory agent» open source che sostituisce il classico RAG basato su embedding con un processo di consolidamento continuo affidato a un LLM. Come racconta MarkTechPost, il sistema è costruito su Google ADK e Gemini 3.1 Flash-Lite e conserva memorie strutturate in SQLite anziché in un vector database. L’idea di fondo merita attenzione, ma va inquadrata con qualche cautela.
Come è fatto l’agente
L’architettura ruota attorno a un orchestratore con tre sub-agent. L’IngestAgent processa i contenuti in ingresso (secondo l’articolo 27 tipi di file tra testo, immagini, audio, video e PDF) estraendo riassunti, entità, argomenti e punteggi di importanza. Il ConsolidateAgent gira in background ogni 30 minuti per individuare connessioni tra le memorie e sintetizzare nuovi «insight». Il QueryAgent risponde alle domande leggendo le memorie e citando gli ID di origine. In pratica si lascia cadere un file in una cartella inbox oppure si usano endpoint HTTP.
Il vero argomento: memoria attiva contro retrieval passivo
La tesi centrale è che il RAG sia «passivo: fa l’embedding una volta e recupera più tardi», mentre qui l’elaborazione avviene di continuo durante i cicli di consolidamento. L’articolo contrappone l’approccio anche ai riassunti di conversazione («perdono dettaglio, nessun cross-reference») e ai knowledge graph («costosi da costruire e mantenere»). È un framing interessante, ma è bene ricordare che si tratta di una contrapposizione narrativa: nella pratica RAG, consolidamento e grafi sono spesso complementari, non alternativi.
I caveat che contano
Da segnalare, con onestà, che l’articolo non riporta alcun benchmark né metrica quantitativa: nessun numero su qualità, latenza o costo. Il limite più rilevante è architetturale: il QueryAgent legge «fino a 50 memorie recenti», un vincolo che può degradare le risposte su dataset ampi e che di fatto reintroduce un problema di scalabilità del recupero. Prima di dichiarare superato il RAG, quindi, conviene testare l’approccio sui propri volumi reali.
In sintesi
- L’agente sostituisce embedding e vector DB con consolidamento LLM continuo su Gemini 3.1 Flash-Lite, memorie in SQLite.
- Tre sub-agent (ingest, consolidate ogni 30 minuti, query con citazioni) sotto un orchestratore.
- Nessun benchmark pubblicato e un limite di 50 memorie in lettura: l’idea è promettente ma va verificata su scala reale.
Hai qualcosa da aggiungere? Unisciti alla discussione.