La maggior parte degli agenti AI dimentica: elaborano una richiesta, rispondono e perdono il contesto. Google Cloud ha pubblicato nel repository open source generative-ai un sample che affronta il problema in modo diverso, l’Always-On Memory Agent, una reference implementation che tratta la memoria come un processo sempre attivo invece che come una singola chiamata.
La scelta architetturale piu interessante e l’assenza di vector database ed embeddings. Al loro posto, un LLM legge, ragiona e scrive memoria strutturata dentro SQLite. Il progetto e costruito con Google ADK (Agent Development Kit) e Gemini 3.1 Flash-Lite, modello scelto per bassa latenza e basso costo su un lavoro in background che gira 24 ore su 24.
Ingest, consolidate, query
Un orchestrator instrada ogni richiesta a uno di tre sub-agent specializzati. L’IngestAgent elabora i contenuti in ingresso e, sfruttando le capacita multimodali di Gemini, ne estrae summary, entita, topic e un punteggio di importanza, salvando il tutto nella tabella memories. Il ConsolidateAgent gira su timer, di default ogni 30 minuti: rivede le memorie non consolidate, trova connessioni e scrive un riassunto sintetizzato con nuovi insight, costruendo comprensione mentre il sistema e inattivo. Il QueryAgent risponde alle domande leggendo memorie e insight e, aspetto rilevante, cita gli ID delle memorie usate come fonti.
L’IngestAgent accetta 27 tipi di file su cinque categorie (testo, immagini, audio, video, PDF): basta lasciarli nella cartella ./inbox per il pickup automatico. Una limitazione dichiarata: la query legge fino a 50 memorie recenti.
Perche interessa a chi costruisce agenti
Il confronto con gli approcci classici e esplicito. Vector DB + RAG immagazzina embeddings ma resta passivo: incorpora una volta e recupera dopo. I summary di conversazione perdono dettaglio; i knowledge graph sono costosi da costruire e mantenere. L’Always-On Memory Agent, invece, elabora la memoria in modo attivo con una consolidation continua, non solo al momento del retrieval.
Il setup e minimale: installare le dipendenze, impostare la GOOGLE_API_KEY e avviare il processo, che osserva ./inbox, consolida ogni 30 minuti ed espone una HTTP API sulla porta 8888 con endpoint come /ingest, /query, /status e /consolidate. Piu che un prodotto finito, e un pattern di riferimento utile per casi come research assistant, knowledge base personali o support agent che devono mantenere un contesto durevole ed evolutivo.
- Niente vector DB ne embeddings: un LLM scrive memoria strutturata in SQLite.
- Tre sub-agent (Ingest, Consolidate, Query) sotto un orchestrator, con consolidation ogni 30 minuti.
- E un sample open source su Google ADK e Gemini 3.1 Flash-Lite, da valutare come pattern piu che come soluzione production-ready.
Fonte: Google Cloud’s Always-On Memory Agent Replaces RAG and Embeddings With Continuous LLM Consolidation on Gemini 3.1 Flash-Lite — https://www.marktechpost.com/2026/07/18/google-clouds-always-on-memory-agent-replaces-rag-and-embeddings-with-continuous-llm-consolidation-on-gemini-3-1-flash-lite/
Hai qualcosa da aggiungere? Unisciti alla discussione.