Google Cloud costruisce l’infrastruttura per gli agenti AI sempre attivi

Ad agosto Google Cloud ha aggiunto due tasselli alla propria infrastruttura per gli agenti AI: i Database Operations Agents, integrati con Gemini Cloud Assist, e le Cloud Run instances, runtime dedicati pensati per applicazioni persistenti e generalmente utilizzate da un singolo utente. 78

La strategia è duplice: rendere più semplice la gestione dei database su cui gli agenti fanno affidamento e offrire loro un ambiente di esecuzione più stabile rispetto al modello serverless tradizionale, che può ridurre a zero le risorse quando non sono utilizzate.

Due agenti per il ciclo di vita del database

L’offerta Gemini Cloud Assist comprende due agenti complementari:

• il Database Onboarding Agent, dedicato alle attività di Day 0: scelta del database, provisioning, configurazione e primo deployment;
• il Database Observability Agent, destinato alle operazioni di Day 1 e Day 2: monitoraggio, diagnosi, troubleshooting e manutenzione continuativa. 8

L’obiettivo è ridurre il lavoro manuale normalmente richiesto a DBA, sviluppatori, SRE e team DevOps: pianificazione dell’architettura, scrittura di script, provisioning, configurazione di schemi e indici, ottimizzazione delle query e analisi dei problemi. Le attività vengono guidate attraverso istruzioni in linguaggio naturale. 8

Dal provisioning alla configurazione iniziale

Il Database Onboarding Agent accompagna l’utente nella creazione e nella configurazione iniziale del database direttamente tramite conversazione. Sono supportati i database gestiti di Google Cloud AlloyDB, Bigtable, Cloud SQL e Spanner. 8

Diagnosi basata sulla telemetria

Il Database Observability Agent combina i dati provenienti da Database Insights, Cloud Monitoring, Cloud Logging, Cloud Trace e da altre fonti operative. In questo modo può mettere in relazione segnali diversi e aiutare a risalire alla causa di problemi come:

• aumenti improvvisi della latenza;
• query che consumano risorse in modo anomalo;
• contesa sui lock;
• vincoli di capacità o altre limitazioni delle risorse. 8

L’agente non si limita a indicare il problema. Può proporre modifiche validate, spiegandone la motivazione e l’impatto atteso. Con l’approvazione dell’utente può anche applicare alcune correzioni, per esempio abilitare il connection pooling in Cloud SQL o aggiungere un indice. Alcune funzioni di analisi e remediation erano disponibili in anteprima per clienti selezionati. 8

Gli agenti sono accessibili da più punti: chat di Gemini Cloud Assist, pagine dei database nella console Google Cloud, viste di flotta di Database Center, CLI, IDE e strumenti di terze parti. Le funzioni di Database Insights e Database Center sono inoltre disponibili come strumenti MCP attraverso i server Google Remote MCP, permettendo ad agenti e tool di sviluppo esterni di recuperare metriche di sistema e delle query, inventario della flotta e problemi rilevati. 8

Cloud Run instances: un runtime singleton per agenti persistenti

Il 27 agosto Google Cloud ha presentato in anteprima le Cloud Run instances, runtime di calcolo dedicati e singleton. A differenza dei normali servizi Cloud Run, ogni istanza esegue una sola copia dell’applicazione, non effettua autoscaling e non viene portata automaticamente a zero. 9

Le caratteristiche principali sono:

• esecuzione continua fino a sette giorni, con riavvio automatico configurato per impostazione predefinita;
• possibilità di arrestare e riprendere l’istanza quando necessario;
• URL HTTPS stabile, che non cambia durante aggiornamenti e riavvii. 9

Google le propone come alternativa più gestibile a una macchina virtuale sempre accesa. L’utente può conservare un processo persistente senza occuparsi direttamente della manutenzione del sistema operativo, della configurazione del firewall o della gestione dell’endpoint HTTPS. Al tempo stesso, il modello evita alcuni limiti dei servizi serverless tradizionali basati sullo scale-to-zero.

Il prezzo indicato per un’istanza con 1 vCPU condivisa e 1 GiB di memoria, mantenuta attiva per 30 giorni, è di 5,70 dollari. Il modello utilizza inoltre budget di burst per gestire picchi occasionali, invece di richiedere il dimensionamento e il pagamento continuo di una macchina virtuale più grande. 9

Un processo sempre attivo può anche ridurre l’esposizione ai cold start. Un primo utilizzatore ha riferito una diminuzione dell’88% dei cold start per il proprio agente di lunga durata: si tratta però di una dichiarazione del cliente, non di una garanzia generale sulle prestazioni. 9

Cosa cambia per l’architettura degli agenti AI

Le due novità affrontano lati diversi dello stesso problema. Un agente AI ha bisogno di un ambiente di esecuzione economico e duraturo per orchestrare attività asincrone e gestire interazioni distribuite su più turni; i database che utilizza, invece, devono poter essere configurati, osservati e ottimizzati con meno intervento manuale. 18

Cloud Run instances risponde alla prima esigenza, soprattutto per agenti personali o applicazioni con un singolo utente e un processo di lunga durata. Database Operations Agents interviene sulla seconda, trasformando parte della gestione operativa dei dati in flussi guidati dal linguaggio naturale e in strumenti compatibili con MCP.

Resta una distinzione importante: un runtime persistente non equivale a uno stato durevole. Se l’agente deve sopravvivere a riavvii o conservare il lavoro oltre la vita dell’istanza, è comunque necessario uno storage esterno. Per gli agenti destinati alla produzione, la documentazione di Google indica soluzioni di session storage persistente come Cloud SQL. 5