Google Cloud punta sugli agenti AI: database autonomi e Cloud Run sempre disponibili

Le applicazioni basate su agenti AI stanno mettendo in discussione il modello cloud tradizionale. Non basta più avviare un endpoint quando arriva una richiesta: un agente può avere bisogno di memoria, identità, un indirizzo stabile, attività in background e accesso continuo a dati e strumenti.

Ad agosto 2026 Google Cloud ha risposto a due di questi problemi con prodotti distinti ma complementari: i Database Operations Agents, integrati con Gemini Cloud Assist, e l’anteprima di Cloud Run instances, un runtime persistente per carichi di lavoro con stato. Insieme, mostrano come Google stia adattando sia il livello dei dati sia quello dell’elaborazione alle applicazioni agentiche. 2411

Due agenti per seguire il database dall’inizio alla gestione quotidiana

I Database Operations Agents rientrano nella strategia Agentic Data Cloud di Google Cloud. La loro divisione dei compiti è semplice: il primo segue il Day 0, cioè la fase di progettazione e avvio; il secondo copre le attività di Day 1 e Day 2, dalla supervisione alla manutenzione. 2

Database Onboarding Agent: dalla descrizione del progetto al deployment

Il Database Onboarding Agent interpreta i requisiti di un’applicazione, suggerisce il database gestito più adatto e guida il team nella configurazione e nel deployment. L’obiettivo è ridurre le decisioni manuali di architettura e provisioning che normalmente precedono la messa online di un servizio.

L’agente supporta AlloyDB, Bigtable, Cloud SQL e Spanner. 2

In pratica, può essere utile quando sviluppatori e team di piattaforma sanno già descrivere il carico di lavoro e i requisiti operativi dell’applicazione, ma non hanno ancora stabilito quale servizio database Google Cloud risponda meglio a quei vincoli.

Database Observability Agent: monitoraggio, diagnosi e correzioni

Il Database Observability Agent entra in gioco dopo il deployment. Google gli attribuisce funzioni di monitoraggio dell’intero parco database, rilevamento delle anomalie, diagnosi, troubleshooting, ottimizzazione e manutenzione.

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

L’agente non si limita a leggere un singolo avviso. Mette in relazione dati provenienti da Database Insights e dalla telemetria di Database Center, Cloud Monitoring, Cloud Logging e Cloud Trace, includendo metriche, informazioni sulle query, inventario delle risorse e dati relativi ai problemi. 2

Il risultato atteso è un’analisi delle possibili cause alla radice, accompagnata da una spiegazione e da una procedura di intervento. Tra gli esempi indicati da Google ci sono l’abilitazione del connection pooling in Cloud SQL e l’aggiunta di indici.

Per le modifiche potenzialmente rilevanti in produzione, l’agente mantiene una barriera di sicurezza: prima di eseguire una correzione validata serve l’approvazione di una persona. Le funzioni di analisi e remediation erano disponibili in anteprima per clienti selezionati. 224

Dove si utilizzano i Database Operations Agents

I due agenti sono integrati in Gemini Cloud Assist e possono essere utilizzati attraverso la chat di Gemini e le pagine dedicate ai database nella Cloud Console. Google indica inoltre l’accesso tramite strumenti da riga di comando, server e tool MCP, strumenti di terze parti e ambienti di sviluppo integrati (IDE). 2

Questo sposta l’assistenza sui database al di fuori della singola dashboard operativa. Lo stesso flusso in linguaggio naturale può accompagnare chi sviluppa o amministra l’infrastruttura durante l’indagine di un problema, il provisioning di una risorsa o il lavoro quotidiano nell’ambiente di sviluppo.

Cloud Run instances: un runtime persistente per gli agenti

Il 28 agosto Google Cloud ha presentato in anteprima Cloud Run instances, una risorsa diversa dal normale servizio Cloud Run con autoscaling. Ogni istanza funziona come un singleton, cioè viene mantenuta una sola istanza senza scalabilità automatica.

Google la propone per carichi di lavoro lunghi e con stato, come gli agenti AI personali. 4

Le caratteristiche principali sono:

• esecuzione continua fino a sette giorni;
• riavvio automatico configurato per impostazione predefinita;
• URL HTTPS stabile, che non cambia dopo aggiornamenti o riavvii;
• possibilità di arrestare l’istanza e riprenderla in seguito;
• un singolo runtime dedicato, invece di una flotta che cresce o si riduce in base al traffico. 4

È un modello adatto a un agente che deve conservare stato o identità e restare disponibile per un singolo utente. Si adatta meno naturalmente a un endpoint web stateless, progettato soprattutto per gestire picchi di richieste simultanee.

Il prezzo indicato da Google

Per una configurazione con 1 vCPU e 1 GiB di RAM, basata su vCPU condivisa e budget burst, Google ha indicato un costo di 5,70 dollari per 30 giorni di funzionamento continuo. 4

Il vantaggio rispetto a una macchina virtuale dedicata non sarebbe soltanto economico. Secondo Google, gli utenti possono evitare la manutenzione della VM e del sistema operativo, la gestione del firewall e la configurazione autonoma di un endpoint HTTPS.

Il prezzo resta però un riferimento della presentazione in anteprima, non un confronto universale. Il costo effettivo dipende da configurazione, utilizzo, area geografica e dettagli di fatturazione. 43031

Google ha inoltre citato una dichiarazione di un cliente di 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 indipendente. 4

Perché il cambiamento riguarda l’infrastruttura degli agenti

Le applicazioni cloud tradizionali separano spesso l’elaborazione stateless delle richieste dai servizi di dati persistenti. Gli agenti AI rendono questa separazione meno netta: possono dover mantenere una sessione, eseguire attività a lungo termine, ricordare informazioni e chiamare strumenti anche quando non stanno rispondendo a una richiesta web convenzionale.

Le novità di Google Cloud affrontano il problema da due direzioni:

1. Il livello dei dati diventa più autonomo. Il Database Onboarding Agent aiuta a scegliere e predisporre il database; il Database Observability Agent monitora l’ambiente, analizza i problemi e può applicare correzioni approvate. 2
2. Il livello di calcolo offre un’opzione orientata alla persistenza. Cloud Run instances fornisce un runtime singleton con indirizzo stabile per gli agenti che devono rimanere disponibili, invece di partire solo in risposta al traffico o ridursi a zero. 4

La direzione si inserisce nel progetto Agentic Data Cloud, con cui Google Cloud vuole riunire dati, modelli e database operativi in un sistema capace di trasformare il contesto in azioni eseguite dagli agenti. 11

L’aspetto più significativo è il compromesso scelto: Google automatizza una parte crescente delle operazioni, ma conserva l’approvazione umana quando una modifica al database può avere conseguenze sulla produzione. 2

Il punto pratico

Questi annunci non costituiscono un’unica piattaforma universale per ogni agente AI. Sono piuttosto due strumenti mirati:

• i Database Operations Agents sono pensati per chi deve scegliere, configurare, monitorare o risolvere problemi in un parco database;
• le Cloud Run instances sono rivolte agli agenti che hanno bisogno di un runtime unico, persistente e raggiungibile, e che non si adattano al modello scale-to-zero di un normale servizio serverless.

Poiché le funzionalità sono presentate in termini di anteprima, prima di impiegarle in produzione è necessario verificare disponibilità, configurazioni supportate, permessi, prezzi e limiti delle remediation automatiche. La direzione, tuttavia, è chiara: Google Cloud sta trattando gli agenti AI come carichi di lavoro che richiedono sia operazioni più autonome sia infrastrutture più durevoli.