AnswersPublished18 sources
Google Cloud punta sugli agenti AI: database più semplici e Cloud Run sempre attivo
Ad agosto 2026 Google Cloud ha presentato i Database Operations Agents, basati su Gemini Cloud Assist, e le istanze Cloud Run in anteprima: i primi automatizzano configurazione e gestione dei database, le seconde eseg... Il Database Onboarding Agent gestisce le attività iniziali; il Database Observability Agent corr...
Pubblicato daModificato con GPT-5.6 LunaImmagini generate con GPT Image 1.5
Research answer
Key takeaways
- Ad agosto 2026 Google Cloud ha presentato i Database Operations Agents, basati su Gemini Cloud Assist, e le istanze Cloud Run in anteprima: i primi automatizzano configurazione e gestione dei database, le seconde eseg...
- Il Database Onboarding Agent gestisce le attività iniziali; il Database Observability Agent correla i dati di telemetria per individuare problemi, proporre correzioni e, con l’approvazione dell’utente, applicare alcun...
- Le istanze Cloud Run non fanno autoscaling e non si riducono a zero: possono restare attive fino a sette giorni, offrire un indirizzo HTTPS stabile e costare 5,70 dollari ogni 30 giorni nella configurazione indicata d...
- Le due novità coprono livelli diversi della stessa architettura: Cloud Run mantiene in esecuzione l’agente, mentre i Database Operations Agents semplificano la gestione dei dati su cui l’agente si basa.
AI Prompt
openai.comCreate a landscape editorial hero image for this Studio Global article: What did Google Cloud introduce in August to support AI-agent infrastructure—specifically, how do its Gemini Cloud Assist–integrated Databas. Article summary: In August, Google Cloud introduced two complementary building blocks for always-on AI agents: Database Operations Agents to automate database setup and operations, and Cloud Run instances for low-cost, persistent single-. Topic tags: general, general web, documentation. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fak
Google Cloud sta affrontando due ostacoli ricorrenti nella realizzazione degli agenti AI: i database richiedono ancora competenze specialistiche per configurazione e diagnosi, mentre gli agenti che lavorano a lungo hanno bisogno di un ambiente che non venga spento subito quando il traffico diminuisce. Ad agosto 2026 l’azienda ha presentato i Database Operations Agents e, in anteprima, le istanze Cloud Run dedicate ai carichi di lavoro persistenti. 23
1
Le due proposte sono complementari, non intercambiabili. I Database Operations Agents intervengono sul livello dati; le istanze Cloud Run forniscono invece un ambiente di esecuzione continuo per agenti personali e applicazioni con interazioni di lunga durata.
Due novità per due problemi diversi
I Database Operations Agents usano Gemini Cloud Assist per guidare, tramite linguaggio naturale, la scelta del database, il provisioning, il monitoraggio, la diagnosi e la manutenzione. 23
Le istanze Cloud Run agiscono sul livello computazionale: offrono un runtime singleton, cioè un ambiente con una sola copia dell’applicazione, pensato per agenti che devono rimanere disponibili, mantenere un processo attivo o usare un endpoint stabile. 1
La distinzione è importante: un processo persistente non rende automaticamente durevoli i dati conservati in memoria, così come l’automazione del database non crea da sola un ambiente sempre attivo in cui eseguire l’agente.
Cosa fanno i Database Operations Agents
Google ha introdotto due agenti nell’ambito della strategia Agentic Data Cloud:
- Database Onboarding Agent: gestisce le attività di “Day 0”, tra cui scelta del database, configurazione, preparazione e primo deployment.
- Database Observability Agent: copre le operazioni di “Day 1” e “Day 2”, come monitoraggio, troubleshooting e manutenzione continuativa.
23
L’obiettivo è ridurre la necessità di assemblare manualmente script di provisioning, configurazioni, query di monitoraggio e procedure diagnostiche. Per amministratori di database, sviluppatori, team SRE e DevOps, questo può tradursi in meno attività ripetitive e in flussi guidati in linguaggio naturale, senza eliminare il controllo umano sulle modifiche più delicate.
I database supportati
Il Database Onboarding Agent è descritto come compatibile con servizi di database gestiti da Google Cloud, tra cui AlloyDB, Bigtable, Cloud SQL e Spanner. 29
La disponibilità non è però universale: le funzionalità di onboarding e osservabilità sono presentate come anteprime e, in alcuni casi, l’accesso all’osservabilità è limitato a clienti e servizi database selezionati. 29
34
Dalla telemetria alla diagnosi
Il Database Observability Agent non si limita a leggere una singola metrica. Può correlare segnali provenienti da Database Insights, Cloud Monitoring, Cloud Logging e Cloud Trace per cercare le cause probabili di problemi come picchi di latenza, query che concentrano il carico, contesa sui lock e pressione sulle risorse. 23
Dopo l’analisi, l’agente può spiegare la causa sospetta, proporre una modifica e indicarne motivazione e impatto previsto. Per le azioni supportate, l’esecuzione richiede l’approvazione dell’utente. Tra gli esempi indicati da Google figurano l’attivazione del connection pooling in Cloud SQL e l’aggiunta di un indice. 23
44
Questo limite di sicurezza è essenziale in produzione. Una modifica al database che appare circoscritta può influire su costi, latenza, blocchi e comportamento dell’applicazione: il passaggio dalla raccomandazione all’esecuzione non dovrebbe quindi essere completamente automatico.
Console, riga di comando e MCP
Google sta distribuendo queste funzioni nei principali ambienti usati per le operazioni cloud: chat di Gemini Cloud Assist, pagine dei database nella console Google Cloud, viste del parco database in Database Center, interfaccia a riga di comando, IDE e strumenti di terze parti. 23
Le funzionalità di Database Insights e Database Center possono inoltre essere esposte tramite interfacce compatibili con MCP, il Model Context Protocol. I server MCP gestiti da Google Cloud permettono a Gemini e ad altri client MCP di accedere a capacità legate a database e infrastruttura senza dover implementare e gestire autonomamente il server MCP. 36
Per gli sviluppatori, questo significa poter collegare a un flusso agentico inventario dei database, metriche operative e problemi rilevati attraverso un’interfaccia standard, invece di dipendere soltanto dalla console grafica.
Cosa aggiungono le istanze Cloud Run
Le Cloud Run instances sono runtime Cloud Run dedicati e singleton. A differenza di un normale servizio Cloud Run, un’istanza esegue una sola copia dell’applicazione, non effettua autoscaling e non scala a zero. Google le ha presentate in anteprima per casi d’uso come gli agenti AI personali e altri carichi di lavoro longevi, in genere destinati a un singolo utente. 1
Ogni istanza può rimanere attiva in modo continuativo fino a sette giorni, con una politica di riavvio automatico configurata per impostazione predefinita. È inoltre possibile arrestarla quando non serve e riprenderla in seguito. A ogni istanza viene assegnato un URL HTTPS che resta invariato durante aggiornamenti e riavvii. 1
Per gli agenti AI, queste caratteristiche affrontano alcuni limiti dei deployment serverless basati sulle richieste:
- Nessuna interruzione dovuta allo scale-to-zero: il processo resta disponibile tra una richiesta e l’altra.
- Esecuzione singleton: il carico gira come copia dedicata, senza moltiplicazione automatica delle istanze.
- Indirizzo stabile: l’endpoint HTTPS non cambia dopo un riavvio o un aggiornamento.
- Infrastruttura gestita: lo sviluppatore ottiene un processo persistente senza dover amministrare il sistema operativo di una macchina virtuale, le regole firewall o la configurazione dell’endpoint HTTPS.
Google presenta il modello come un’alternativa alle VM mantenute continuamente in esecuzione per alcuni scenari, non come un sostituto universale delle macchine virtuali o dei servizi Cloud Run con autoscaling.
Prezzo e cold start
Google indica un costo di 5,70 dollari ogni 30 giorni per un’istanza Cloud Run mantenuta continuamente attiva con 1 vCPU condivisa e 1 GiB di memoria. Il servizio prevede inoltre budget di burst per gestire picchi occasionali senza dover dimensionare il runtime sulla base del carico massimo. 1
L’esecuzione persistente può ridurre l’esposizione ai cosiddetti cold start, cioè il ritardo necessario per avviare un ambiente che era stato spento. Un primo cliente ha riferito una riduzione dell’88% dei cold start per un agente di lunga durata, ma si tratta di un risultato riportato da un cliente, non di una garanzia generale sulle prestazioni. 1
Il prezzo di 5,70 dollari va quindi letto come esempio per la configurazione dichiarata, non come stima completa per ogni deployment: possono aggiungersi costi per risorse, rete, storage o servizi collegati.
“Persistente” non significa memoria permanente
Un’istanza Cloud Run può mantenere attivo un processo, ma non garantisce che i dati conservati esclusivamente nella memoria dell’applicazione sopravvivano a ogni riavvio, arresto o scadenza del runtime. La documentazione architetturale di Google distingue infatti lo stato in memoria da quello esterno: se l’applicazione viene riavviata, la cronologia della conversazione conservata in memoria va persa; per sistemi di produzione affidabili è raccomandata una gestione esterna dello stato. 19
Un agente destinato alla produzione dovrebbe quindi salvare sessioni, avanzamento dei flussi di lavoro e altri dati durevoli in un database o in un sistema di persistenza. Le indicazioni di Google per gli agenti di lunga durata citano, negli scenari di produzione, anche lo storage delle sessioni basato su database, come Cloud SQL. 21
Il termine “stateful” va dunque interpretato con precisione: le istanze Cloud Run offrono un modello di esecuzione persistente per un periodo limitato, ma non eliminano la necessità di uno storage durevole quando l’agente deve recuperare un’attività interrotta o conservare il contesto oltre la vita dell’istanza.
La strategia di Google Cloud per gli agenti
Considerate insieme, le due novità coprono entrambi i lati di un sistema agentico:
- Eseguire l’agente: le istanze Cloud Run offrono un’opzione gestita e relativamente leggera per processi dedicati, longevi e dotati di endpoint stabile.
- Gestire i dati: i Database Operations Agents automatizzano parte del provisioning, dell’osservabilità, della diagnosi e della remediation approvata.
- Collegare strumenti e ambienti: le integrazioni MCP portano le capacità dei database in IDE, CLI, strumenti esterni e altri agenti.
- Mantenere il controllo umano: l’Observability Agent può proporre interventi, ma le azioni di remediation supportate richiedono l’approvazione dell’utente.
Il risultato non è un’infrastruttura completamente autonoma che rende superfluo il giudizio degli ingegneri. È piuttosto un insieme di primitive gestite che riduce il lavoro operativo ripetitivo, lasciando a chi progetta il sistema le decisioni su architettura, permessi, stato durevole e governance delle modifiche in produzione.
Per chi sviluppa assistenti personali, flussi asincroni o agenti conversazionali, Cloud Run risolve soprattutto il problema della continuità di esecuzione. Per chi gestisce i database da cui questi agenti dipendono, i Database Operations Agents mirano invece a semplificare configurazione, controllo dello stato e risposta agli incidenti. La direzione indicata da Google Cloud è chiara: rendere sia il calcolo sia le operazioni sui dati più accessibili agli agenti attraverso linguaggio naturale, telemetria e interfacce standardizzate.
Studio Global AI
Continue your research
This page includes a source-backed answer you can continue inside Studio Global.
People also ask
What is the short answer to "Google Cloud punta sugli agenti AI: database più semplici e Cloud Run sempre attivo"?
Ad agosto 2026 Google Cloud ha presentato i Database Operations Agents, basati su Gemini Cloud Assist, e le istanze Cloud Run in anteprima: i primi automatizzano configurazione e gestione dei database, le seconde eseg...
What are the key points to validate first?
Ad agosto 2026 Google Cloud ha presentato i Database Operations Agents, basati su Gemini Cloud Assist, e le istanze Cloud Run in anteprima: i primi automatizzano configurazione e gestione dei database, le seconde eseg... Il Database Onboarding Agent gestisce le attività iniziali; il Database Observability Agent correla i dati di telemetria per individuare problemi, proporre correzioni e, con l’approvazione dell’utente, applicare alcun...
What should I do next in practice?
Le istanze Cloud Run non fanno autoscaling e non si riducono a zero: possono restare attive fino a sette giorni, offrire un indirizzo HTTPS stabile e costare 5,70 dollari ogni 30 giorni nella configurazione indicata d...