Responsabile prodotto senior AI di Google Shubham Saboo ha trasformato uno dei problemi più spinosi nella progettazione degli agenti in un esercizio di ingegneria open supply: la memoria persistente.
Questa settimana ha pubblicato un open supply “Always On Memory Agent” sul Github ufficiale della piattaforma Google Cloud pagina sotto una licenza MIT permissiva, che ne consente l’uso commerciale.
È stato costruito con l’Agent Growth Package di Google, o ADK, introdotto la scorsa primavera nel 2025, e Gemini 3.1 Flash-Lite, un modello a basso costo che Google ha introdotto il 3 marzo 2026 come il modello della serie Gemini 3 più veloce ed economico.
Il progetto funge da implementazione di riferimento pratica per qualcosa che molti workforce di intelligenza artificiale desiderano ma che pochi hanno prodotto in modo pulito: un sistema di agenti in grado di acquisire informazioni in modo continuo, consolidarle in background e recuperarle in seguito senza fare affidamento su un database vettoriale convenzionale.
Per gli sviluppatori aziendali, il rilascio conta meno come lancio di un prodotto che come segnale sulla direzione in cui è diretta l’infrastruttura degli agenti.
Il repository racchiude una visione di autonomia a lungo termine che è sempre più attraente per i sistemi di supporto, gli assistenti di ricerca, i copiloti interni e l’automazione del flusso di lavoro. Inoltre, mette a fuoco le questioni di governance non appena la memoria smette di essere vincolata alla sessione.
Cosa sembra fare il pronti contro termine e cosa non afferma chiaramente
Il repository sembra inoltre utilizzare un’architettura interna multi-agente, con componenti specializzati che gestiscono l’acquisizione, il consolidamento e l’interrogazione.
Ma i materiali forniti non stabiliscono chiaramente un’affermazione più ampia secondo cui si tratta di una struttura di memoria condivisa per più agenti indipendenti.
Questa distinzione è importante. ADK come framework supporta i sistemi multi-agente, ma questo repository specifico è meglio descritto come un agente di memoria sempre attivo, o livello di memoria, creato con subagenti specializzati e archiviazione persistente.
Anche a questo livello più ristretto, affronta un problema infrastrutturale fondamentale su cui molti workforce stanno lavorando attivamente.
L’architettura privilegia la semplicità rispetto allo stack di recupero tradizionale
Secondo il repository, l’agente funziona continuamente, inserisce file o enter API, archivia memorie strutturate in SQLite ed esegue il consolidamento programmato della memoria ogni 30 minuti per impostazione predefinita.
Sono incluse un’API HTTP locale e una dashboard Streamlit e il sistema supporta l’inserimento di testo, immagini, audio, video e PDF. Il repository incornicia il progetto con un’affermazione intenzionalmente provocatoria: “Nessun database vettoriale. Nessun incorporamento. Solo un LLM che legge, pensa e scrive memoria strutturata”.
È probabile che questa scelta progettuale attiri l’attenzione degli sviluppatori che gestiscono i costi e la complessità operativa. Gli stack di recupero tradizionali spesso richiedono pipeline di incorporamento, archiviazione di vettori, logica di indicizzazione e lavoro di sincronizzazione separati.
L’esempio di Saboo si appoggia invece al modello per organizzare e aggiornare direttamente la memoria. In pratica, ciò può semplificare i prototipi e ridurre l’espansione dell’infrastruttura, soprattutto per agenti di memoria di piccole o medie dimensioni. Inoltre, sposta la questione delle prestazioni dall’overhead della ricerca vettoriale alla latenza del modello, alla logica di compattazione della memoria e alla stabilità comportamentale a lungo termine.
Flash-Lite conferisce al modello sempre attivo una logica economica
È qui che entra in gioco Gemini 3.1 Flash-Lite.
Google afferma che il modello è progettato per carichi di lavoro di sviluppatori advert alto quantity su larga scala e ha un prezzo di 0,25 dollari per 1 milione di token di enter e 1,50 dollari per 1 milione di token di output.
L’azienda afferma inoltre che Flash-Lite è 2,5 volte più veloce di Gemini 2.5 Flash in termini di tempo per il primo token e offre un aumento del 45% nella velocità di output mantenendo una qualità simile o migliore.
Sui benchmark pubblicati da Google, il modello registra un punteggio Elo di 1432 su Enviornment.ai, 86,9% su GPQA Diamond e 76,8% su MMMU Professional. Google posiziona queste caratteristiche come adatte per attività advert alta frequenza come traduzione, moderazione, generazione di interfacce utente e simulazione.
Questi numeri aiutano a spiegare perché Flash-Lite è abbinato a un agente di memoria in background. Un servizio 24 ore su 24, 7 giorni su 7, che rilegge, consolida e serve periodicamente la memoria, necessita di una latenza prevedibile e di costi di inferenza sufficientemente bassi da evitare di rendere “sempre attivo” un costo proibitivo.
La documentazione ADK di Google rafforza la storia più ampia. Il framework viene presentato come indipendente dal modello e dall’implementazione, con supporto per agenti del flusso di lavoro, sistemi multi-agente, strumenti, obiettivi di valutazione e implementazione tra cui Cloud Run e Vertex AI Agent Engine. Questa combinazione fa sì che l’agente di memoria sembri meno una demo una tantum e più un punto di riferimento per una strategia di runtime dell’agente più ampia.
Il dibattito aziendale riguarda la governance, non solo le capacità
La reazione del pubblico mostra perché l’adozione da parte delle aziende della memoria persistente non dipenderà solo dalla velocità o dal prezzo dei token.
Numerous risposte su X hanno evidenziato esattamente le preoccupazioni che gli architetti aziendali potrebbero sollevare. Franck Abe ha definito Google ADK e il consolidamento della memoria 24 ore su 24, 7 giorni su 7 “passi brillanti per l’autonomia continua degli agenti”, ma ha avvertito che un agente che “sogna” e impollina ricordi in background senza confini deterministici diventa “un incubo di conformità”.
ELED ha sottolineato un punto correlato, sostenendo che il costo principale degli agenti sempre attivi non sono i token ma “deriva e loop”.
Queste critiche si rivolgono direttamente al carico operativo dei sistemi persistenti: chi può scrivere la memoria, cosa viene unito, come funziona la conservazione, quando i ricordi vengono cancellati e come i workforce controllano ciò che l’agente ha imparato nel tempo?
Un’altra reazione, da Incertoha contestato il framing “no embedding” del repository, sostenendo che il sistema deve ancora suddividere, indicizzare e recuperare la memoria strutturata e che potrebbe funzionare bene per agenti di piccolo contesto ma rompersi una volta che gli archivi di memoria diventano molto più grandi.
Questa critica è tecnicamente importante. La rimozione di un database vettoriale non rimuove la progettazione di recupero; cambia dove vive la complessità.
Per gli sviluppatori, il compromesso non riguarda tanto l’ideologia quanto l’idoneità. Uno stack più leggero può essere interessante per agenti a memoria limitata a basso costo, mentre le implementazioni su scala più ampia possono comunque richiedere controlli di recupero più severi, strategie di indicizzazione più esplicite e strumenti più efficaci per il ciclo di vita.
ADK amplia la storia oltre una singola demo
Altri commentatori si sono concentrati sul flusso di lavoro degli sviluppatori. Uno ha chiesto il repository e la documentazione dell’ADK e voleva sapere se il runtime è serverless o di lunga esecuzione e se gli hook di valutazione e di chiamata degli strumenti sono disponibili immediatamente.
In base ai materiali forniti, la risposta è effettivamente entrambe le cose: l’esempio del memory-agent stesso è strutturato come un servizio a lunga esecuzione, mentre ADK supporta più ampiamente modelli di distribuzione multipli e embody strumenti e funzionalità di valutazione.
L’agente di memoria sempre attivo è interessante di per sé, ma il messaggio più ampio è che Saboo sta cercando di far sembrare gli agenti come sistemi software program distribuibili piuttosto che come immediate isolati. In questo contesto, la memoria diventa parte del livello runtime, non solo una funzionalità aggiuntiva.
Ciò che Saboo ha mostrato e ciò che non ha mostrato
Ciò che Saboo non ha ancora mostrato è importante tanto quanto ciò che ha pubblicato.
I materiali forniti non includono un benchmark diretto tra Flash-Lite e Anthropic Claude Haiku per i loop degli agenti nell’uso di produzione.
Inoltre, non prevedono controlli di conformità di livello aziendale specifici per questo agente di memoria, come: limiti di coverage deterministici, garanzie di conservazione, regole di segregazione o flussi di lavoro di audit formali.
E mentre il repository sembra utilizzare più agenti specializzati internamente, i materiali non dimostrano chiaramente un’affermazione più ampia sulla memoria persistente condivisa tra più agenti indipendenti.
Per ora, il repository si presenta come un modello ingegneristico avvincente piuttosto che come una piattaforma di memoria aziendale completa.
Perché questo è importante adesso
Tuttavia, il rilascio arriva al momento giusto. I workforce di intelligenza artificiale aziendale stanno andando oltre gli assistenti a turno singolo e verso sistemi in grado di ricordare le preferenze, preservare il contesto del progetto e operare su orizzonti più lunghi.
L’agente di memoria open supply di Saboo offre un punto di partenza concreto per il livello successivo di infrastruttura, e Flash-Lite dà una certa credibilità agli aspetti economici.
Ma la conclusione più evidente dalla reazione al lancio è che la memoria continua sarà giudicata tanto in termini di governance quanto di capacità.
Questa è la vera domanda aziendale dietro la demo di Saboo: non se un agente possa ricordare, ma se possa ricordare in modi che rimangano limitati, ispezionabili e sufficientemente sicuri da poter avere fiducia nella produzione.
