Agenti AI Gemini: il lavoro continua dopo la disconnessione

Gli agenti AI Gemini possono ora ricevere un’attività articolata in più passaggi: ci si può disconnettere e lasciare che il lavoro prosegua sui server di Google, senza perdere codice, file, pacchetti installati e connessioni agli strumenti remoti. L’aggiornamento di luglio 2026 dei Managed Agents introduce i quattro elementi che rendono questo approccio davvero praticabile: esecuzione in background, connessioni dirette a server MCP remoti, chiamate a funzioni personalizzate e rinnovo delle credenziali senza dover ricreare il workspace.

Cambia così anche il modo più utile di concepire questi agenti. Non si tratta più di tenere aperta la scheda di un chatbot, ma di consegnare una richiesta di lavoro a un operatore cloud e tornare a verificarne il risultato quando è pronto.

Cosa sono davvero gli agenti AI gestiti di Gemini

I Gemini Managed Agents sono operatori cloud temporanei, ciascuno con un proprio workspace Linux. Una singola chiamata tramite l’Interactions API di Google può predisporre l’ambiente, permettere all’agente di ragionare sull’attività, eseguire Bash, Python o Node.js, installare pacchetti, gestire file, cercare sul web e ripetere questi passaggi fino a ottenere un risultato.

L’operatore predefinito è l’agente Antigravity di Google, attualmente identificato come antigravity-preview-05-2026 e basato su Gemini 3.5 Flash. L’Interactions API ha raggiunto la disponibilità generale nel giugno 2026, mentre i Managed Agents e i relativi ambienti sono ancora in anteprima pubblica.

Due ID conservano due tipi diversi di memoria:

• previous_interaction_id è la cartella del lavoro: mantiene la conversazione, il percorso di ragionamento e la cronologia degli strumenti.
• environment_id è la chiave dell’officina: riapre lo stesso filesystem, i pacchetti installati e lo stato del repository.

È possibile conservare l’uno senza l’altro. Riutilizzando soltanto l’ID dell’ambiente si avvia una nuova conversazione nello stesso workspace; passando entrambi gli ID, invece, si riprende lo stesso lavoro nello stesso ambiente. La compattazione automatica del contesto inizia intorno a 135,000 token, così una sessione lunga può alleggerire i dettagli meno recenti senza raggiungere subito il limite di contesto.

Il risultato si colloca a metà strada tra gli agenti AI consumer già noti a molti team e un’infrastruttura che, altrimenti, bisognerebbe costruire in proprio. Google gestisce il ciclo del modello e la sandbox. Logica del prodotto, autorizzazioni, regole di approvazione, monitoraggio ed esperienza utente restano invece sotto la responsabilità di chi sviluppa.

Come funziona il workflow, senza gergo

Il nuovo flusso comprende sei elementi:

1. Avviare o riaprire un workspace. Si usa environment: "remote" per creare una nuova sandbox, si passa l’ID di un ambiente per riutilizzarlo oppure si fornisce una configurazione completa con repository sorgente e regole di rete.
2. Fornire solo gli strumenti necessari. Nel proprio ambiente, l’agente dispone di esecuzione del codice, Google Search, lettura degli URL e accesso al filesystem. Un server MCP remoto è un connettore standard che espone strumenti esterni. Richiede un nome in minuscolo, un URL e il trasporto Streamable HTTP. È anche possibile limitare gli strumenti di quel server che l’agente può usare.
3. Spostare il lavoro in background. Impostando background: true, l’API restituisce subito un ID di interazione: non è più necessario mantenere un’unica e fragile connessione HTTP per tutta la durata dell’attività. I processi in background richiedono store: true, che è l’impostazione predefinita.
4. Seguire l’avanzamento senza tenere aperta la connessione. È possibile interrogare periodicamente l’interazione o riceverne gli eventi in streaming. Se lo stream si interrompe, ci si riconnette indicando l’ultimo event_id e si riparte da lì. Un lavoro può essere in corso, in attesa di un’azione, completato, non riuscito oppure annullato.
5. Gestire nell’applicazione le azioni aziendali sensibili. Gli strumenti integrati della sandbox vengono eseguiti sul lato di Google. Una funzione personalizzata mette in pausa l’interazione nello stato requires_action, consentendo all’applicazione di convalidare la richiesta, chiedere l’approvazione di una persona, eseguire la logica aziendale locale e restituire il risultato.
6. Proseguire dopo il completamento. Un’attività successiva può riutilizzare l’ID dell’interazione conclusa insieme al relativo ID ambiente. Se un token di accesso scade, si invia lo stesso ID ambiente con una nuova configurazione di rete. Le nuove regole sostituiscono quelle precedenti, mentre file, pacchetti e repository clonati rimangono al loro posto.

Il workspace è persistente, ma non permanente. Dopo 15 minuti di inattività viene arrestato e salvato come snapshot; resta ripristinabile per sette giorni dall’ultima attività, poi viene eliminato. Ogni ambiente mette attualmente a disposizione quattro core CPU e 16 GB di memoria.

I sette casi d’uso con il ritorno più evidente

La classifica segue un criterio preciso: quanto direttamente le nuove funzioni eliminano un costoso collo di bottiglia operativo.

1. Team software che verificano pull request generate dall’AI

Un team di prodotto che riceve continuamente codice scritto da macchine potrebbe avviare un processo in background per ogni pull request. L’agente potrebbe aprire il repository, esaminare il diff, installare il progetto, eseguire i test, risalire a un errore attraversando più file e preparare una revisione corredata da log e da una patch proposta. Il collegamento a GitHub o GitLab può passare da un server MCP remoto, mentre il commento finale o la modifica al codice possono rimanere subordinati a una funzione di approvazione personalizzata.

Il vantaggio non è l’ennesimo commento generico sulla revisione. È una prima analisi sostenuta da prove di esecuzione, pronta prima ancora che un senior engineer apra la pull request. È un aspetto sempre più importante man mano che la programmazione asincrona diventa una modalità di lavoro abituale, un cambiamento già visibile negli agenti di coding da mobile e in background.

2. Team finanziari e dati che producono report operativi ricorrenti

Un analista operativo potrebbe avviare un agente non appena arrivano le ultime esportazioni CSV, collegarlo a un data warehouse tramite MCP e lasciargli pulire i dati, svolgere analisi in Python, creare grafici e salvare i file di lavoro in un unico ambiente. Se scade un token temporaneo del warehouse, l’applicazione può fornirne uno nuovo senza costringere l’agente a reinstallare il proprio stack o ricreare i file intermedi.

Il beneficio è la continuità. L’analista controlla un unico report completo e i relativi file di supporto, invece di spostare ripetutamente i dati tra notebook, foglio di calcolo, strumento per i grafici e finestra di chat.

3. Team di affidabilità impegnati nell’analisi degli incidenti

Un tecnico reperibile potrebbe dare all’agente accesso a un server MCP di osservabilità e a un connettore per il controllo del codice sorgente, chiedendogli poi di mettere in relazione un picco di latenza con deployment, log e commit recenti. L’analisi può proseguire in background mentre il tecnico gestisce l’incidente in corso. Nel proprio workspace, l’agente può produrre una timeline, individuare possibili cause e preparare script diagnostici.

Il vantaggio è raccogliere più rapidamente le prove quando la pressione è alta. Gli interventi correttivi in produzione devono comunque restare dietro un esplicito controllo umano. Durante un incidente è utile avere un operatore capace di chiamare strumenti; un operatore senza supervisione e con ampie credenziali di produzione, invece, è un nuovo incidente in attesa di accadere.

4. Team di sicurezza che raccolgono le prove per gli audit

Un responsabile della conformità che prepara una revisione degli accessi potrebbe limitare la sandbox ai domini approvati, inserire credenziali di sola lettura tramite il proxy di uscita di Google e affidare a un agente la raccolta di policy, impostazioni dei repository e cronologie delle modifiche. Poiché le credenziali vengono aggiunte al confine di rete, non finiscono nei file della sandbox né nelle variabili d’ambiente.

Il risultato è un dossier di prove ripetibile, al posto di una settimana trascorsa tra screenshot e copia-incolla. L’applicazione deve comunque mantenere una propria traccia di audit e un processo di approvazione, perché i Managed Agents non costituiscono un prodotto di conformità completo.

5. Investitori e team acquisti che svolgono due diligence

Un piccolo team di investimento potrebbe assegnare a un agente in background un mandato di ricerca ben delimitato: mappare un mercato, confrontare le affermazioni dei fornitori, esaminare un repository, svolgere calcoli e preparare un memorandum con le fonti. File e script restano disponibili per le domande successive, quindi la seconda analisi può mettere alla prova le ipotesi anziché ricostruire da zero l’intero ambiente di ricerca.

Il vantaggio è poter approfondire senza bloccare la sessione del browser di un analista. Va però considerato un limite: al momento Antigravity accetta input di testo e immagini, ma non audio, video o documenti; i processi incentrati sui documenti richiedono quindi una fase esterna di estrazione.

6. Agenzie che eseguono audit ripetibili per i clienti

Un’agenzia di analytics o sviluppo potrebbe creare un ambiente distinto per l’audit di ogni cliente, collegare soltanto i sistemi autorizzati per quel cliente e mettere in coda controlli lunghi in modo indipendente. Un workspace potrebbe contenere un sito clonato e script per misurarne le prestazioni; un altro, l’esportazione di una campagna e il codice per i report.

Il beneficio è duplice: isolamento e ripetibilità. Durante la finestra di sette giorni, i team possono mantenere esattamente lo stato di lavoro necessario a un approfondimento senza mescolare file o credenziali di clienti diversi.

7. Team di back office che risolvono casi complessi

Un’azienda assicurativa, logistica o di assistenza potrebbe usare un agente gestito per ricostruire da più sistemi la cronologia di una pratica, verificare le regole applicabili, calcolare le opzioni e preparare l’azione successiva. Gli strumenti MCP remoti forniscono l’accesso in lettura, mentre le funzioni personalizzate riservano rimborsi, modifiche agli account o decisioni sui sinistri alla logica applicativa convalidata e all’approvazione umana.

Il vantaggio è un unico workspace continuo per gestire la pratica attraverso molti sistemi. È particolarmente utile quando servono minuti per ricostruire un caso e il processo non può essere ridotto a una semplice automazione basata su trigger e azione.

Tre prodotti che vale la pena costruire

La capacità di base è ampia. I prodotti vendibili, invece, sono circoscritti, misurabili e protetti da controlli che generano fiducia.

1. La scommessa migliore: un custode del repository che dimostra ogni rilievo

Si può creare un’app per GitHub o GitLab pensata per i team a cui i semplici commenti sul diff non bastano. Per ogni pull request, l’app esegue il progetto in un workspace isolato, riproduce i problemi sospetti, allega i log, prepara una correzione e attende l’intervento di una persona prima di modificare il codice.

La domanda è concreta. DataForSEO stima circa 1,300 ricerche al mese negli Stati Uniti per “AI code review”, con un CPC di $46.65. “AI code review tools” aggiunge circa 590 ricerche mensili e, nel dataset attuale delle keyword, registra una crescita annua dell’85%. I clienti già pagano: CodeRabbit propone piani da $24 a $48 per utente al mese con fatturazione annuale, mentre Greptile indica un prezzo di $30 per postazione al mese.

La versione minima vendibile richiede un’integrazione con un solo sistema di controllo del codice sorgente, un file di istruzioni per il repository, un test runner in background, una pagina dei risultati con le prove grezze e un’azione di approvazione per pubblicare una revisione o aprire una patch. Non conviene partire supportando ogni linguaggio: meglio scegliere un ecosistema in cui i test sono comuni e la configurazione del runtime è prevedibile.

L’ostacolo è un mercato affollato, oltre al problema della fiducia. Tra le domande rilevate nelle ricerche compaiono “How does AI code review work?” e “Is the AI code safe?”. Il vero vantaggio difendibile non sarà l’accesso a Gemini, ma un dataset di valutazione sempre più ampio, regole specifiche per repository, un basso tasso di falsi positivi e prove che rendano verificabile ogni rilievo.

2. Un agente per la chiusura periodica dei dati di un singolo team operativo

Si può creare un operatore che trasformi i dati sorgente settimanali o mensili di un’azienda in un report riconciliato, mantenendo accanto al risultato il codice dell’analisi e i file intermedi. I team operativi, commerciali e finanziari pagano perché il lavoro si ripete e gli errori sono visibili.

DataForSEO stima 3,600 ricerche al mese negli Stati Uniti per “AI for data analysis”, una query commerciale con un CPC di $41.92. La più specifica “AI agent for data analysis” raccoglie circa 320 ricerche mensili e ha una difficoltà keyword pari a 2 nel dataset attuale: un segnale di possibile spazio per acquisire traffico, anche se il mercato più ampio è competitivo.

L’MVP comprende un sistema esterno di pianificazione o un trigger basato sull’arrivo dei file, un connettore per il warehouse, una destinazione su foglio di calcolo, un modello di report fisso, un registro delle esecuzioni e una schermata di riconciliazione. Il limite reale è l’affidabilità dell’output. Antigravity non supporta output strutturati, quindi tabelle e totali importanti devono essere sottoposti a convalida deterministica prima della consegna.

3. Un orchestratore verticale con vere approvazioni

Si può costruire un prodotto per una sola tipologia di pratica, come l’onboarding dei fornitori, il triage dei sinistri o la raccolta di prove di sicurezza. Il sistema recupera il contesto attraverso due o tre connessioni MCP, svolge in background l’analisi più lunga e ricorre a funzioni personalizzate per le poche azioni che devono essere convalidate o approvate.

DataForSEO stima 1,000 ricerche al mese negli Stati Uniti per “AI workflow automation”, una query con intento commerciale e un CPC di $49.51. “AI workflow automation platform” aggiunge circa 260 ricerche mensili e nel dataset attuale mostra una crescita annua del 320%. Gli utenti chiedono esplicitamente: “How can I automate my workflows using AI?”.

L’MVP richiede una coda, un solo workflow ben definito, due integrazioni, una casella per le approvazioni e un registro completo di ogni esecuzione. Il rischio è cadere nella trappola della piattaforma orizzontale. Se la prima versione promette di automatizzare qualsiasi workflow, il lavoro sui connettori e i casi limite finirà per inghiottire il prodotto. Prima bisogna imporsi in un singolo processo costoso.

Cosa non risolvono i Managed Agents

L’esecuzione gestita riduce il lavoro sull’infrastruttura, ma non elimina i rischi operativi o di prodotto.

Anche il rinnovo delle credenziali va interpretato con precisione. Google conserva l’ambiente quando l’applicazione fornisce nuove regole di rete e un nuovo token. Non è l’agente a generare o ruotare quel token.

La mia valutazione: questa soluzione è adatta ad attività circoscritte, con criteri di completamento chiari, artefatti verificabili, autorizzazioni ristrette e passaggi di approvazione. Un agente in anteprima non dovrebbe diventare un amministratore di produzione senza limiti. Le stesse indicazioni di Google invitano a verificare codice generato, trasformazioni dei dati, modifiche alla configurazione e azioni esterne prima di farvi affidamento.

Che cos’è l’automazione dei workflow basata sull’AI?

È un workflow in cui un modello interpreta il contesto e sceglie tra diversi strumenti, anziché seguire soltanto una sequenza fissa di trigger. I Gemini Managed Agents aggiungono un workspace ospitato e un runtime in background, ma autorizzazioni, trigger, convalide e approvazioni restano definiti dall’applicazione.

Come si automatizza un workflow con l’AI?

Si parte da un’attività circoscritta, con un input chiaro, un output verificabile e non più di poche connessioni agli strumenti. L’analisi viene eseguita in background, gli accessi in lettura restano limitati e ogni azione irreversibile passa attraverso una funzione personalizzata o l’approvazione di una persona.

Qual è un esempio di workflow automatizzato con l’AI?

Un custode delle pull request è un buon esempio: riceve una nuova pull request, apre il repository in una sandbox, installa le dipendenze, esegue i test, analizza gli errori, prepara una revisione e infine attende l’approvazione prima di pubblicare o modificare il codice.

Come funziona la revisione del codice con l’AI?

Il revisore legge una modifica insieme al contesto del repository, cerca difetti o violazioni delle policy e formula i propri rilievi. Un agente gestito può andare oltre, eseguendo il progetto e allegando log o risultati dei test; spetta comunque a una persona valutare se il rilievo rispecchia il reale intento del prodotto.

Il codice generato dall’AI è sicuro?

Non per impostazione predefinita. Una sandbox limita l’ambiente in cui viene eseguito il codice, ma la sicurezza dipende anche dal codice stesso, dalle autorizzazioni degli strumenti, dalle regole di rete, dalle credenziali, dai test e dalla revisione umana. L’output di un agente va considerato un contributo non attendibile finché non supera i controlli ordinari.

Per progettare uno di questi operatori intorno ai propri sistemi, alle proprie autorizzazioni e alle proprie regole di approvazione, è possibile consultare il servizio di sviluppo di agenti AI.