Google ha annunciato il 12 novembre 2026 l’introduzione di Orchestrator in Antigravity, un sistema di coordinamento dei modelli di intelligenza artificiale che permette di alternare dinamicamente Gemini 4 Carbon e Gemini 4 Hydrogen all’interno di una stessa sessione di sviluppo software. La funzionalità viene distribuita progressivamente agli abbonati Google AI Ultra attraverso un’opzione disponibile nel menu di selezione dei modelli. Secondo i risultati comunicati da Google sul benchmark Terminal-Bench 4.1, Orchestrator raggiunge un tasso di completamento delle attività vicino a quello di Gemini 4 Carbon utilizzato autonomamente, riducendo mediamente del 24% il consumo della quota disponibile e del 19% il tempo necessario per completare le operazioni. Gemini 4 Hydrogen viene distribuito separatamente agli utenti a pagamento Google AI Pro e Ultra, mentre le organizzazioni possono accedere a entrambi i modelli attraverso Gemini per le aziende. Google prevede di estendere successivamente Orchestrator ad altri modelli e ulteriori piani di abbonamento. L’architettura distingue il ruolo di Hydrogen, ottimizzato per l’esecuzione rapida delle operazioni, da quello di Carbon e Argon, destinati a compiti di ragionamento più approfonditi e processi di pianificazione di lunga durata.
Orchestrator è stato sviluppato per affrontare una limitazione dei sistemi tradizionali di instradamento delle richieste verso modelli differenti. Nei router statici, il livello di difficoltà viene generalmente stimato a partire dalla richiesta iniziale e l’intera attività viene assegnata al modello considerato sufficientemente capace e meno costoso. Questa decisione anticipata non tiene conto del fatto che, durante lo sviluppo di una funzionalità o la risoluzione di un problema software, la complessità può cambiare sensibilmente. Un’attività apparentemente semplice può richiedere un’analisi approfondita delle dipendenze oppure incontrare errori imprevisti durante l’esecuzione dei test, mentre un problema inizialmente complesso può diventare una sequenza di modifiche relativamente ordinarie dopo la definizione di un piano corretto. L’utilizzo continuativo di un modello di ragionamento avanzato può quindi aumentare tempi di risposta e consumo delle risorse anche durante operazioni che non richiedono capacità particolarmente elevate. Orchestrator interviene direttamente su questo processo, consentendo di modificare il modello responsabile dell’esecuzione mentre la sessione procede, in entrambe le direzioni e senza imporre una scelta definitiva all’inizio del lavoro.
Nel flusso operativo illustrato da Google, Gemini 4 Carbon viene inizialmente utilizzato per esaminare il codice in modalità di sola lettura, analizzare le dipendenze del progetto, chiarire gli aspetti ambigui della richiesta e costruire un piano di intervento. Il piano comprende condizioni esplicite che permettono di riconoscere quando le operazioni devono essere rivalutate o ripianificate. Una volta definita la strategia, il controllo passa a Gemini 4 Hydrogen, incaricato di realizzare le modifiche ai file, aggiornare i pacchetti software ed eseguire i test. Se durante l’implementazione emergono problemi che richiedono un ragionamento più approfondito, il sistema trasferisce nuovamente la sessione a Carbon, che esamina lo stato raggiunto, identifica le cause delle difficoltà e modifica il piano prima della prosecuzione. Il processo permette di utilizzare la capacità di ragionamento più elevata nelle fasi di analisi iniziale, recupero dagli errori e revisione della strategia, assegnando invece le attività esecutive ordinarie al modello più rapido. L’alternanza avviene all’interno dello stesso percorso operativo e non richiede che ogni fase venga gestita attraverso agenti indipendenti.
Per gli sviluppatori che preferiscono stabilire esplicitamente le responsabilità dei modelli, Google mette a disposizione anche l’Antigravity SDK, attraverso il quale Carbon e Hydrogen possono essere collegati con assegnazioni programmatiche dei rispettivi ruoli. In una dimostrazione open source dedicata alla gestione delle segnalazioni di problemi software, gli agenti Hydrogen si occupano del volume ordinario delle richieste, classificano le issue, cercano informazioni nel codice, formulano domande di chiarimento, realizzano modifiche e aggiornano le interfacce sulla base dei commenti ricevuti nelle pull request. Un agente Carbon viene invece impiegato per interventi di refactoring più estesi, sviluppo di nuove funzionalità e verifiche di sicurezza. Questa configurazione utilizza la stessa distinzione funzionale tra esecuzione rapida e ragionamento approfondito, ma lascia allo sviluppatore la definizione dei confini operativi anziché affidarli al meccanismo automatico di Orchestrator.
La nuova funzionalità si affianca alle capacità multiagente introdotte con l’anteprima di Gemini 4 Carbon e del comando /swarm del 10 novembre 2026. Quest’ultimo è destinato a progetti di ingegneria software che coinvolgono numerosi file, pacchetti e suite di test e permette a un coordinatore di suddividere l’attività tra diversi agenti con incarichi specifici. Gli agenti possono lavorare su parti separate del codice, esaminare problemi differenti e utilizzare copie isolate dei repository, mentre altri componenti verificano le modifiche e ne controllano i risultati attraverso l’esecuzione dei test. Orchestrator opera invece su un livello differente: non suddivide necessariamente il lavoro tra più agenti paralleli, ma modifica il modello utilizzato durante l’evoluzione di una singola sessione. Le due funzionalità possono quindi rispondere a necessità complementari, con /swarm dedicato alla distribuzione delle attività e Orchestrator alla selezione dinamica della capacità di elaborazione richiesta nelle diverse fasi di uno stesso processo.
I dati pubblicati da Google su Terminal-Bench 4.1 rappresentano il riferimento iniziale per valutare questa architettura, indicando che l’alternanza automatica tra Carbon e Hydrogen può contenere il consumo di quota e ridurre i tempi medi di completamento mantenendo risultati vicini a quelli ottenuti con il modello di ragionamento più avanzato. La scelta del modello non viene più effettuata necessariamente una sola volta a partire dal prompt iniziale, ma diventa un elemento modificabile durante l’esecuzione, sulla base dell’avanzamento dell’attività, delle difficoltà incontrate e delle condizioni definite dal piano. Gli sviluppatori possono adottare questo comportamento adattivo attraverso Orchestrator oppure implementare una distribuzione esplicita dei compiti tramite SDK, mantenendo il controllo sull’organizzazione dei flussi di sviluppo e sulle responsabilità assegnate ai singoli modelli.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)