Google Cloud vuole rendere più autonomi database e agenti IA

Ad agosto 2026 Google Cloud ha delineato un’infrastruttura più adatta agli agenti IA: da un lato, strumenti capaci di ridurre il lavoro umano necessario per configurare e gestire i database; dall’altro, un runtime Cloud Run pensato per gli agenti che devono restare attivi e conservare il proprio stato invece di scalare automaticamente a zero. Le due iniziative si inseriscono nel progetto Agentic Data Cloud e nella più ampia spinta di Google verso un cloud più autonomo e gestibile tramite linguaggio naturale. 211

Database Operations Agents: dalla configurazione alla manutenzione

Google Cloud ha presentato due agenti integrati con Gemini Cloud Assist, destinati a coprire fasi diverse del ciclo di vita di un database.

Database Onboarding Agent

Il Database Onboarding Agent si occupa delle attività di “Day 0”, cioè quelle precedenti all’avvio effettivo del workload. L’agente interpreta i requisiti descritti dall’utente, suggerisce il servizio di database gestito più appropriato e guida le operazioni di configurazione, impostazione e distribuzione.

L’obiettivo è ridurre la necessità di scegliere manualmente tra architetture, parametri e comandi di provisioning. L’agente supporta AlloyDB, Bigtable, Cloud SQL e Spanner. 2

Database Observability Agent

Il Database Observability Agent è invece rivolto alle attività di “Day 1 e Day 2”: monitoraggio dell’intero parco database, individuazione delle anomalie, diagnosi dei problemi, troubleshooting, ottimizzazione e manutenzione ordinaria.

Il supporto comprende Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore e Memorystore. 213

Per individuare le cause dei problemi, l’agente mette in relazione dati provenienti da Database Insights e Database Center, oltre che da Cloud Monitoring, Cloud Logging e Cloud Trace. Può quindi combinare metriche, informazioni sulle query, inventario delle risorse e dati relativi agli incidenti per produrre un’analisi della causa principale. 2

Il sistema non si limita a proporre suggerimenti. Per un gruppo selezionato di clienti, le funzioni di indagine e correzione erano disponibili in anteprima e potevano applicare rimedi già validati dopo l’approvazione di una persona. Tra gli esempi citati figurano l’attivazione del connection pooling in Cloud SQL e l’aggiunta di indici. 2

Le funzionalità sono accessibili dalla chat di Gemini e dalle pagine dedicate ai database nella Cloud Console. Google ha inoltre previsto l’accesso tramite strumenti da riga di comando, server e tool MCP, strumenti di terze parti e ambienti di sviluppo integrati. 2

Cloud Run: un’istanza persistente per gli agenti IA

Il 28 agosto Google Cloud ha presentato in anteprima una nuova modalità di esecuzione di Cloud Run: un runtime singleton, ossia un ambiente con esattamente una sola istanza e senza autoscaling. È pensato per workload con stato e disponibilità continua, non per i servizi stateless che devono aumentare o ridurre rapidamente il numero di istanze in base al traffico. 4

Una singola istanza può restare attiva fino a sette giorni e dispone di una policy di riavvio automatico configurata per impostazione predefinita. L’URL HTTPS rimane invariato anche dopo aggiornamenti e riavvii; inoltre, l’utente può arrestare l’istanza e riprenderla in un secondo momento. 4

Google ha indicato un prezzo di 5,70 dollari per 30 giorni di funzionamento continuo con 1 vCPU e 1 GiB di RAM, utilizzando una vCPU condivisa e budget di burst. Il vantaggio rispetto a una macchina virtuale dedicata non sarebbe quindi soltanto economico: chi usa il servizio non deve occuparsi della manutenzione della VM e del sistema operativo, della gestione del firewall o della pubblicazione autonoma di endpoint HTTPS, evitando anche di pagare la capacità completa di una VM sempre accesa. 4

Il primo scenario d’uso indicato è quello degli agenti IA personali a esecuzione prolungata, come OpenClaw o Hermes, che devono restare disponibili per un singolo utente anche quando il suo computer portatile è spento. Google ha inoltre riportato una dichiarazione di un cliente OffDeal secondo cui i cold start si sarebbero ridotti dell’88%. Si tratta di un risultato riferito dal cliente, non di una garanzia generale sulle prestazioni né di un benchmark valido per ogni workload. 4

Una piattaforma pensata per agenti più “persistenti”

Le due novità affrontano problemi diversi ma collegati. I Database Operations Agents rendono più “agentic” il livello dei dati: l’utente può descrivere ciò che gli serve in linguaggio naturale e ricevere assistenza per il provisioning, l’osservabilità, l’analisi degli incidenti e, previa approvazione, l’applicazione di correzioni.

Le istanze singleton di Cloud Run intervengono invece sul livello di calcolo, offrendo una base gestita per processi che hanno bisogno di identità persistente, endpoint stabile, memoria o stato e attività in background di lunga durata. Insieme, le due iniziative riflettono la differenza tra gli agenti IA emergenti e le applicazioni web tradizionali: gli agenti devono spesso accedere continuamente a strumenti e dati, mantenere il contesto e funzionare con un intervento operativo ridotto.

La direzione scelta da Google combina quindi agenti capaci di automatizzare parte della gestione con primitive infrastrutturali gestite per ospitare processi persistenti. Per le modifiche più delicate ai database, tuttavia, resta previsto un passaggio di approvazione umana. 24