Gemini 3.5 porta gli agenti dall’idea all’azione: servono processi migliori

Google ha presentato Gemini 3.5 il 19 maggio 2026, iniziando da Gemini 3.5 Flash. L’azienda lo descrive come un modello che combina intelligenza di frontiera e capacità d’azione, pensato per coding e attività agentiche di lunga durata. È disponibile attraverso Antigravity, Gemini API, AI Studio e piattaforme enterprise indicate da Google. Il lancio rende ancora più sottile il confine tra un assistente che consiglia e un sistema che esegue passaggi reali.

Per un’impresa, agire può significare interrogare dati, aggiornare un documento, compilare una scheda o coordinare strumenti diversi. La promessa è interessante proprio nei processi frammentati, dove le persone perdono tempo passando da una piattaforma all’altra. Ma un modello veloce non corregge un flusso confuso. Se regole, eccezioni e responsabilità vivono solo nella testa di un collega, l’automazione moltiplicherà l’ambiguità.

Il primo lavoro da fare è descrivere lo stato iniziale e quello finale in termini osservabili. Non chiedete di migliorare la campagna: chiedete di analizzare un periodo definito, classificare le creatività secondo criteri condivisi e preparare tre ipotesi con dati di supporto. Poi distinguete azioni reversibili, come creare una bozza, da azioni con impatto, come pubblicare o spendere budget. Le seconde devono avere un’approvazione esplicita.

Anche la gestione degli errori va progettata prima. Cosa deve fare l’agente se una fonte manca, un campo non coincide o un servizio non risponde? Fermarsi e chiedere aiuto è spesso meglio che indovinare. Registrare strumenti usati, decisioni e output intermedi permette di fare debug e crea fiducia nel team. L’autonomia utile non è assenza di supervisione: è capacità di completare il percorso concordato rendendo visibili le eccezioni.

Scegliete un’attività frequente, noiosa e poco rischiosa, come preparare il riepilogo settimanale delle performance contenuto. Fornite un dataset di prova, un report considerato buono e una checklist. Fate eseguire il flusso in sola lettura, confrontate il risultato con quello umano e annotate ogni intervento necessario. Solo dopo più cicli stabili consentite la scrittura in un ambiente controllato, mai direttamente sul sistema principale.

Misurate tempo risparmiato al netto della revisione, percentuale di output accettati e numero di eccezioni. Se la verifica costa quanto il lavoro originale, il processo non è ancora maturo o non è il caso d’uso giusto. Gemini 3.5 amplia le possibilità tecniche, ma il vantaggio dipenderà dalla disciplina operativa. Le aziende che documentano il lavoro, assegnano responsabilità e costruiscono feedback brevi saranno anche quelle che adotteranno gli agenti con meno attrito.

La parola agente può nascondere funzioni molto diverse: comprendere una richiesta, pianificare, recuperare informazioni, usare uno strumento, verificare il risultato e decidere se continuare. Un test serio osserva questi passaggi separatamente. Se l’output è errato, bisogna sapere se il modello ha interpretato male l’obiettivo, recuperato la fonte sbagliata o chiamato lo strumento con parametri non corretti. Senza questa distinzione, ogni miglioramento si riduce a modificare il prompt e sperare.

Per una PMI il processo può essere rappresentato con una scheda semplice: evento iniziale, risultato atteso, dati disponibili, azioni consentite, eccezioni e responsabile. L’agente riceve soltanto le capacità necessarie. Un flusso che prepara una bozza di aggiornamento CRM non ha bisogno di cancellare record o cambiare budget pubblicitari. La modularità riduce il rischio e rende più chiaro dove intervenire.

Ogni strumento deve applicare autorizzazioni anche al di fuori del modello. Non basta scrivere nel prompt che un’azione è vietata. Le operazioni sensibili richiedono conferma con destinatario, contenuto e conseguenza visibili. I dati recuperati devono rispettare il ruolo dell’utente e la finalità del processo. Quando l’agente lavora su più sistemi, identità e permessi devono propagarsi in modo coerente.

La memoria viene limitata a ciò che migliora davvero il lavoro. Preferenze operative e stato della pratica possono essere utili; conversazioni complete conservate indefinitamente aumentano rischio e confusione. È opportuno distinguere contesto della sessione, memoria temporanea e dati registrati nei sistemi ufficiali. Ogni livello ha fonte, durata, modalità di correzione e proprietario.

Nel primo livello l’agente osserva e propone: legge casi storici o dati di prova e produce un risultato senza conseguenze. Nel secondo assiste il team su richieste reali, ma una persona approva ogni azione. Nel terzo automatizza soltanto operazioni a basso rischio che hanno superato soglie di qualità. Le eccezioni, gli importi elevati e i dati mancanti continuano a essere inoltrati a un responsabile.

Ogni livello richiede criteri di promozione. Si misurano output approvati, errori rilevanti, latenza, costo, escalation e risultato di business. Se il tempo risparmiato viene assorbito dalla revisione, il progetto non è ancora pronto a scalare. Anche una decisione di fermarsi può essere utile: mostra che dati o processo devono essere ordinati prima dell’automazione.

Il pilot inizia da un inventario degli strumenti disponibili e delle azioni che ciascuno espone. Per ogni connettore si indicano proprietario, dati letti, modifiche possibili, autenticazione e procedura di revoca. L’ambiente di prova usa record sintetici o copie minimizzate e separa chiaramente sviluppo e produzione. Il team prepara casi normali, richieste incomplete, istruzioni in conflitto e tentativi di ottenere azioni non autorizzate. La qualità dell’agente dipende tanto da questi confini quanto dalla capacità del modello.

Durante il test ogni esecuzione conserva una traccia comprensibile: obiettivo ricevuto, piano, strumenti chiamati, fonti, conferme e risultato. La traccia non serve a sorvegliare le persone, ma a individuare dove il flusso perde affidabilità. Una revisione a campione valuta correttezza e utilità; tutti i casi ad alto impatto vengono invece controllati. Se una metrica migliora ma aumentano azioni fuori perimetro o dati esposti, il pilot non supera la fase.

Prima del rilascio si prepara un interruttore di arresto, si prova la revoca dei permessi e si definisce chi interviene durante un incidente. Le istruzioni operative includono esempi di escalation e un messaggio chiaro per l’utente quando l’agente non può procedere. Il rollout parte da un gruppo ristretto e da orari coperti dal supporto. Solo dopo un periodo stabile si ampliano utenti, dati o autonomia, modificando una dimensione alla volta.