Il modello Gemini 2.5 Computer Use di Google gestisce un loop screenshot-azione per agenti browser

Il loop: screenshot in entrata, azione UI in uscita

Il modello è esposto tramite un nuovo tool `computer_use` nella Gemini API, e Google chiarisce esplicitamente che è pensato per funzionare all'interno di un loop, non come singola chiamata. Ogni turno fornisce al modello tre elementi: la richiesta dell'utente, uno screenshot dell'ambiente corrente e la cronologia delle azioni recenti.

Il modello risponde con una function call che rappresenta una singola azione sulla UI — cliccare, digitare, scorrere. Il codice client-side esegue quell'azione, poi acquisisce un nuovo screenshot e l'URL corrente e li rimanda come function response, facendo ripartire il loop. Il processo continua finché il task non si conclude, si verifica un errore, oppure interviene una risposta di sicurezza o l'utente lo interrompe.

È un aspetto da notare per i team frontend: il modello non legge il DOM né si collega agli interni dell'app. Lavora a partire da pixel e un URL, la stessa superficie che vede un essere umano. Le implementazioni di riferimento lo confermano — Google indica agli sviluppatori di costruire il loop dell'agente in locale con Playwright oppure in una VM cloud tramite Browserbase.

Limitato al browser, non al desktop

Google è preciso su dove il modello funziona. È ottimizzato principalmente per i browser web e mostra risultati promettenti nel controllo delle UI mobile, ma dichiara esplicitamente di non essere ancora ottimizzato per il controllo a livello di sistema operativo desktop.

Le demo restano dentro questo confine: estrarre schede di animali domestici da un form web e inserirle in un CRM per fissare un appuntamento, oppure spostare post-it in categorie diverse su una web app. Sono entrambi task browser ordinari — compilare form, gestire menu a tendina e filtri, operare dietro login — che Google presenta come la capacità concreta che mancava quando gli agenti potevano parlare solo con API strutturate.

La sicurezza a ogni step gira fuori dal modello

Google individua tre rischi specifici per gli agenti che controllano i computer: uso improprio intenzionale da parte degli utenti, comportamenti inaspettati del modello, e prompt injection e truffe nell'ambiente web. Le funzioni di sicurezza sono addestrate direttamente nel modello, ma l'aspetto più interessante per chi costruisce è il controllo esterno al modello.

Servizio di sicurezza per ogni step: un servizio di sicurezza esterno al modello, eseguito in fase di inferenza, che valuta ogni azione proposta dal modello prima che venga eseguita.Montana Labs

Oltre a questo, gli sviluppatori possono usare istruzioni di sistema per far sì che l'agente rifiuti o chieda conferma all'utente prima di azioni ad alto rischio. Il modello stesso può anche segnalare che è necessaria una conferma dell'utente finale — ad esempio, prima di effettuare un acquisto. Google elenca azioni concrete che considera ad alto rischio: compromettere l'integrità del sistema, violare la sicurezza, bypassare i CAPTCHA e controllare dispositivi medici.

Il testing UI è il caso d'uso lanciato per primo da Google

Tra i primi utilizzi, Google evidenzia il testing UI nei propri team di produzione, affermando che può rendere lo sviluppo software significativamente più rapido. Alcune versioni del modello alimentano già Project Mariner, il Firebase Testing Agent e alcune funzionalità agentiche di AI Mode in Search.

Questa impostazione conta. Un agente che guida un browser reale a partire da screenshot è naturalmente adatto al testing end-to-end del frontend — percorrere flussi con i click, inviare form, verificare che gli elementi interattivi si comportino correttamente — senza selettori scritti a mano che si rompono quando la UI cambia. Il percorso di riferimento con Playwright si allinea direttamente al modo in cui molti team scrivono già i test sul browser.

Cosa cambia per il lavoro frontend un agente guidato dai pixel

Poiché il modello opera su screenshot e URL invece che sugli interni dell'app, tratta qualsiasi frontend web come una superficie testabile e automatizzabile così com'è. Non c'è alcun livello di integrazione da costruire contro i tuoi componenti; l'agente usa l'interfaccia come farebbe un utente.

L'implicazione pratica è che la stessa UI renderizzata serve ora due destinatari — gli utenti umani e un agente che la naviga visivamente. Vale ancora l'avvertenza di Google: le protezioni riducono il rischio ma non lo eliminano, e Google esorta gli sviluppatori a testare a fondo i propri sistemi prima del lancio. Per i team che valutano questa tecnologia, il vantaggio a breve termine riguarda meno gli agenti autonomi per l'utente finale e più la trasformazione dei flussi web esistenti in test rapidi e auto-eseguiti sull'interfaccia reale.