Opal di Google ha appena mostrato in silenzio ai group aziendali il nuovo progetto per la creazione di agenti AI

Nell’ultimo anno, la comunità dell’intelligenza artificiale aziendale è stata impegnata in un dibattito su quanta libertà concedere agli agenti di intelligenza artificiale. Troppo poco e si ottiene una costosa automazione del flusso di lavoro che giustifica a malapena l’etichetta di “agente”. Troppo, e si ottiene il tipo di disastri di cancellazione dei dati che hanno afflitto i primi advert adottare strumenti come OpenClaw. Questa settimana, Google Labs ha rilasciato un aggiornamento a Opaleil suo costruttore di agenti visivi senza codice, che arriva silenziosamente a una risposta e contiene lezioni che ogni chief IT che pianifica una strategia per agenti dovrebbe studiare attentamente.

L’aggiornamento introduce ciò che Google chiama un “passaggio dell’agente” che trasforma i flussi di lavoro drag-and-drop precedentemente statici di Opal in esperienze dinamiche e interattive. Invece di specificare manualmente quale modello o strumento chiamare e in quale ordine, i costruttori possono ora definire un obiettivo e lasciare che sia l’agente a determinare il percorso migliore per raggiungerlo: selezionando strumenti, attivando modelli come Gemini 3 Flash o Veo per la generazione di video e persino avviando conversazioni con gli utenti quando sono necessarie maggiori informazioni.

Sembra un modesto aggiornamento del prodotto. Non lo è. Ciò che Google ha fornito è un’architettura di riferimento funzionante per le tre funzionalità che definiranno gli agenti aziendali nel 2026:

1. Routing adattivo

2. Memoria persistente

3. Orchestrazione human-in-the-loop

…e tutto è reso possibile dalle capacità di ragionamento in rapido miglioramento dei modelli di frontiera come la serie Gemini 3.

Il punto di svolta “fuori dai binari”: perché modelli migliori cambiano tutto nella progettazione degli agenti

Per capire perché l’aggiornamento Opal è importante, è necessario comprendere un cambiamento che si sta sviluppando da mesi nell’ecosistema degli agenti.

La prima ondata di strutture per agenti aziendali – strumenti come le prime versioni di CrewAI e le versioni iniziali di LangGraph – erano particular da una tensione tra autonomia e controllo. I primi modelli semplicemente non erano sufficientemente affidabili da poter essere considerati affidabili nel processo decisionale a tempo indeterminato. Il risultato fu quello che i professionisti iniziarono a chiamare “agenti su rotaie”: flussi di lavoro strettamente vincolati in cui ogni punto decisionale, ogni chiamata allo strumento e ogni percorso di diramazione dovevano essere predefiniti da uno sviluppatore umano.

Questo approccio ha funzionato, ma period limitato. Costruire un agente su rotaie significava anticipare ogni possibile stato che il sistema avrebbe potuto incontrare: un incubo combinatorio per qualsiasi cosa oltre i compiti semplici e lineari. Quel che è peggio, significava che gli agenti non potevano adattarsi a nuove situazioni, proprio la capacità che rende preziosa l’intelligenza artificiale degli agenti.

La serie Gemini 3, insieme alle versioni recenti come Claude Opus 4.6 e Sonnet 4.6 di Anthropic, rappresenta una soglia in cui i modelli sono diventati abbastanza affidabili nella pianificazione, nel ragionamento e nell’autocorrezione da far sì che i binari possano iniziare a staccarsi. L’aggiornamento Opal di Google è un riconoscimento di questo cambiamento. Il passaggio del nuovo agente non richiede ai builder di predefinire ogni percorso attraverso un flusso di lavoro. Si affida invece al modello sottostante per valutare l’obiettivo dell’utente, valutare gli strumenti disponibili e determinare dinamicamente la sequenza ottimale di azioni.

Questo è lo stesso modello che ha reso praticabili i flussi di lavoro degli agenti e le chiamate agli strumenti di Claude Code: i modelli sono abbastanza buoni da decidere il passo successivo dell’agente e spesso anche da autocorreggersi senza che un essere umano richieda manualmente ogni errore. La differenza rispetto a Claude Code è che Google sta ora racchiudendo questa funzionalità in un prodotto di livello client, senza codice: un forte segnale che la tecnologia sottostante è maturata oltre la fase sperimentale.

Per i group aziendali, l’implicazione è diretta: se si stanno ancora progettando architetture di agenti che richiedono percorsi predefiniti per ogni contingenza, probabilmente si sta lavorando in modo eccessivo. La nuova generazione di modelli supporta un modello di progettazione in cui si definiscono obiettivi e vincoli, si forniscono strumenti e si lascia che sia il modello a gestire il routing, ovvero il passaggio dalla programmazione degli agenti alla loro gestione.

Memoria tra sessioni: la funzionalità che separa le demo dagli agenti di produzione

La seconda importante aggiunta all’aggiornamento Opal è la memoria persistente. Google ora consente a Opals di ricordare le informazioni attraverso le sessioni (preferenze dell’utente, interazioni precedenti, contesto accumulato) creando agenti che migliorano con l’uso anziché partire da zero ogni volta.

Google non ha rivelato l’implementazione tecnica dietro il sistema di memoria di Opal. Ma il modello in sé è ben radicato nella comunità degli agenti di costruzione. Strumenti come OpenClaw gestiscono la memoria principalmente tramite markdown e file JSON, un approccio semplice che funziona bene per i sistemi a utente singolo. Le distribuzioni aziendali si trovano advert affrontare un problema più difficile: mantenere la memoria su più utenti, sessioni e limiti di sicurezza senza che tra di essi si diffonda un contesto sensibile.

Questo divario di memoria tra utente singolo e multiutente è una delle sfide meno discusse nell’implementazione degli agenti aziendali. Un assistente di codifica personale che ricorda la struttura del progetto è fondamentalmente diverso da un agente a contatto con il cliente che deve mantenere stati di memoria separati per migliaia di utenti simultanei rispettando le coverage di conservazione dei dati.

Ciò che l’aggiornamento Opal segnala è che Google considera la memoria una caratteristica fondamentale dell’architettura dell’agente, non un componente aggiuntivo opzionale. Per i decisori IT che valutano le piattaforme di agenti, ciò dovrebbe informare i criteri di approvvigionamento. Un framework di agenti senza una chiara strategia di memoria è un framework che produrrà demo impressionanti ma avrà difficoltà nella produzione, dove il valore di un agente aumenta in interazioni ripetute con gli stessi utenti e set di dati.

Human-in-the-loop non è una soluzione alternativa: è un modello di progettazione

Il terzo pilastro dell’aggiornamento Opal è ciò che Google chiama “chat interattiva”: la possibilità per un agente di sospendere l’esecuzione, porre all’utente una domanda di follow-up, raccogliere informazioni mancanti o presentare scelte prima di procedere. Nella terminologia dell’architettura degli agenti, questa è un’orchestrazione human-in-the-loop e la sua inclusione in un prodotto di consumo è significativa.

Gli agenti più efficaci nella produzione odierna non sono completamente autonomi. Sono sistemi che sanno quando hanno raggiunto i limiti della loro fiducia e possono restituire con grazia il controllo a un essere umano. Questo è il modello che separa gli agenti aziendali affidabili dal tipo di sistemi autonomi in fuga che hanno generato storie di avvertimento in tutto il settore.

In framework come LangGraph, l’human-in-the-loop è stato tradizionalmente implementato come un nodo esplicito nel grafico: un checkpoint codificato in cui l’esecuzione si ferma per la revisione umana. L’approccio di Opal è più fluido: è l’agente stesso a decidere quando necessita dell’enter umano in base alla qualità e alla completezza delle informazioni in suo possesso. Questo è un modello di interazione più naturale e scalabile meglio, perché non richiede al costruttore di prevedere in anticipo esattamente dove sarà necessario l’intervento umano.

Per gli architetti aziendali, la lezione è che l’intervento umano non dovrebbe essere trattato semplicemente come una rete di sicurezza imbullonata dopo la creazione dell’agente. Dovrebbe trattarsi di una capacità di prima classe della stessa struttura dell’agente, che il modello può invocare dinamicamente in base alla propria valutazione dell’incertezza.

Routing dinamico: lasciare che sia il modello a decidere il percorso

L’ultima caratteristica significativa è il routing dinamico, in cui i costruttori possono definire più percorsi attraverso un flusso di lavoro e consentire all’agente di selezionare quello appropriato in base a criteri personalizzati. L’esempio di Google è un agente di briefing esecutivo che prende percorsi diversi a seconda che l’utente stia incontrando un cliente nuovo o esistente: cercando sul Internet informazioni di base in un caso, rivedendo gli appunti di una riunione interna nell’altro.

Questo è concettualmente simile alla ramificazione condizionale supportata da tempo da LangGraph e framework simili. Ma l’implementazione di Opal abbassa drasticamente la barriera consentendo ai costruttori di descrivere i criteri di routing in linguaggio naturale anziché in codice. Il modello interpreta i criteri e prende la decisione di routing, invece di richiedere allo sviluppatore di scrivere una logica condizionale esplicita.

L’implicazione aziendale è significativa. Il routing dinamico basato su criteri del linguaggio naturale consente agli analisti aziendali e agli esperti di dominio, non solo agli sviluppatori, di definire comportamenti complessi degli agenti. Ciò sposta lo sviluppo degli agenti da una disciplina puramente ingegneristica a una in cui la conoscenza del dominio diventa il principale collo di bottiglia, un cambiamento che potrebbe accelerare notevolmente l’adozione da parte delle unità aziendali non tecniche.

Ciò che Google sta realmente costruendo: un livello di intelligence degli agenti

Facendo un passo indietro rispetto alle singole funzionalità, lo schema più ampio nell’aggiornamento Opal è che Google sta costruendo un livello di intelligenza che si colloca tra l’intento dell’utente e l’esecuzione di attività complesse in più passaggi. Basandosi sulle lezioni di un SDK dell’agente interno chiamato “Tagliere“, il passaggio dell’agente non è solo un altro nodo in un flusso di lavoro: è un livello di orchestrazione che può reclutare modelli, invocare strumenti, gestire la memoria, instradare dinamicamente e interagire con gli esseri umani, il tutto guidato dalle capacità di ragionamento in costante miglioramento dei modelli Gemini sottostanti.

Questo è lo stesso modello architettonico che emerge in tutto il settore. Claude Code di Anthropic, con la sua capacità di gestire autonomamente le attività di codifica durante la notte, si basa su principi simili: un modello capace, accesso a strumenti, contesto persistente e cicli di suggestions che consentono l’autocorrezione. Il plug-in Ralph Wiggum ha formalizzato l’intuizione secondo cui i modelli possono essere costretti a superare i propri fallimenti per arrivare a soluzioni corrette: una versione di forza bruta dell’autocorrezione che Opal ora racchiude parte di essa in un’esperienza di consumo raffinata.

Per i group aziendali, la conclusione è che l’architettura degli agenti sta convergendo su un insieme comune di primitive: pianificazione mirata agli obiettivi, utilizzo di strumenti, memoria persistente, routing dinamico e orchestrazione human-in-the-loop. L’elemento di differenziazione non sarà quali primitive implementerai, ma quanto bene le integrerai e quanto efficacemente sfrutterai le capacità di miglioramento dei modelli di frontiera per ridurre la quantità di configurazione manuale richiesta.

Il manuale pratico per i creatori di agenti aziendali

Google che offre queste funzionalità in un prodotto gratuito rivolto al consumatore invia un messaggio chiaro: i modelli fondamentali per la creazione di agenti IA efficaci non sono più ricerche all’avanguardia. Sono prodotti. I group aziendali che hanno aspettato che la tecnologia maturasse ora hanno un’implementazione di riferimento da cui possono studiare, testare e imparare, a costo zero.

I passaggi pratici sono semplici. Innanzitutto, valuta se le attuali architetture degli agenti sono eccessivamente vincolate. Se ogni punto decisionale richiede una logica codificata, probabilmente non si sfrutteranno le capacità di pianificazione degli attuali modelli di frontiera. In secondo luogo, dare priorità alla memoria come componente architettonico fondamentale e non come elemento secondario. In terzo luogo, progettare l’intervento umano nel ciclo come una capacità dinamica che l’agente può invocare, piuttosto che un punto di controllo fisso in un flusso di lavoro. E in quarto luogo, esplorare il routing del linguaggio naturale come un modo per coinvolgere esperti di dominio nel processo di progettazione dell’agente.

Opal stesso probabilmente non diventerà la piattaforma adottata dalle aziende. Ma i modelli di progettazione che incarna – agenti adattivi, ricchi di memoria e consapevoli dell’uomo alimentati da modelli di frontiera – sono i modelli che definiranno la prossima generazione di IA aziendale. Google ha mostrato la sua mano. La domanda per i chief IT è se prestano attenzione.