Google descrive Agent Compute Engine (ACE) come un’infrastruttura in cui ogni sessione di un agente IA gira in una microVM persistente e isolata a livello hardware. Un componente separato decide le azioni, mentre l’ambiente isolato esegue codice e comandi: così l’orchestrazione e il lavoro operativo hanno ruoli distinti.
La separazione aiuta a capire come Google progetta l’esecuzione, l’accesso alle risorse e la gestione delle sessioni inattive. Sono caratteristiche descritte dall’azienda per ACE, che Google dice di usare già internamente.
Dall’harness al sandbox: chi dirige e chi esegue
L’harness è il componente che chiama il modello, sceglie le azioni e invia le richieste; il sandbox è l’ambiente che le esegue. In ACE, secondo Google, ogni sessione agente usa una microVM dedicata, cioè una macchina virtuale leggera con un confine di isolamento basato sull’hardware.
In pratica, l’harness può chiedere di eseguire codice, impartire un comando o svolgere un’operazione nel browser. Il sandbox esegue il compito e restituisce il risultato. Non è quindi il modello a girare dentro l’ambiente operativo: la direzione del lavoro e la sua esecuzione sono separate.
Identità, rete e credenziali fuori dal sandbox
Google afferma che il sandbox non conserva credenziali utente persistenti, chiavi API, token di aggiornamento OAuth o chiavi di account di servizio. Per il traffico usa invece una Agent Workload Identity di breve durata, basata su SPIFFE.
Prima che una richiesta raggiunga una destinazione, un Agent Gateway esterno controlla l’identità dell’utente, la delega all’agente, l’identità del nodo e le regole di uscita. Se i controlli passano, il gateway intermedia la credenziale necessaria per il servizio di destinazione. Google descrive inoltre il traffico come mediato: le microVM non usano una normale interfaccia di rete virtuale né accedono direttamente alla rete VPC.
Google distingue quattro identità nel sistema: quella dell’utente, quella dell’agente delegato ad agire per suo conto, quella del workload dell’agente e quella della workforce dell’agente. L’identità di workload a breve durata identifica il traffico proveniente dal sandbox.
Che cosa accade quando una sessione resta inattiva
Quando l’agente termina una chiamata a uno strumento e attende il passaggio successivo, Google dice che il runtime segnala l’inattività, il sistema salva un checkpoint della sessione e l’host libera le risorse attive, mantenendo lo stato per la ripresa. L’azienda afferma che, durante l’attesa, la sessione non consuma risorse attive dell’host.
Per ridurre la duplicazione dei dati in memoria, Google descrive pagine di memoria condivise tra microVM sullo stesso host. Le pagine non modificate possono essere riutilizzate da immagini, runtime e librerie già caricati; le modifiche restano private grazie alla tecnica copy-on-write, che crea una copia quando una pagina viene cambiata.
Google suddivide i dati in tre categorie. Dice inoltre che Hyperdisk viene usato per queste categorie salvo diversa indicazione e che i dati sono cifrati a riposo e durante il trasferimento.
| Categoria | Funzione ed esempi | Persistenza |
| Dati temporanei di lavoro | Area scratch per file e dati di passaggio | Effimeri |
| Dati condivisi o di sola lettura | Immagini, toolchain e cache dei pacchetti | Condivisi o di sola lettura |
| Workspace dell’utente | Spazio di lavoro conservato tra le attività | Persistenti |
Un pool condiviso per diversi carichi di lavoro
Google descrive un pool comune di host hardware con collocamento delle attività basato su policy. I lavori flessibili nei tempi, come valutazioni, ricerca e altri processi batch, possono essere eseguiti nei periodi di minore domanda e cedere capacità alle richieste interattive.
L’azienda indica quattro gruppi di carichi: agenti interattivi per utenti e imprese, workspace persistenti per l’ingegneria del software, valutazione e reinforcement learning, e sandbox usati come backend per servizi Google. La scala di centinaia di milioni di agenti citata da Google è la motivazione dichiarata per il progetto.
ACE gestito e Agent Substrate per Kubernetes
The New Stack descrive ACE come un servizio gestito di Google Cloud: Google gestisce l’infrastruttura, mentre i clienti controllano immagini dell’ambiente, identità, accesso alla rete e ciclo di vita. La stessa testata descrive Agent Substrate come un runtime open source per GKE e Kubernetes, basato su Agent Sandbox, con opzioni di isolamento tramite microVM o gVisor.
La differenza riguarda il modello di distribuzione: ACE affida a Google la gestione della flotta hardware, mentre Agent Substrate è orientato a un runtime per ambienti Kubernetes. Google cita ACE per i carichi interni di Gemini, Antigravity e delle proprie pipeline di valutazione e reinforcement learning.
La finestra di anteprima indicata da Google
Il 22 ottobre 2026 Google ha detto che l’anteprima di ACE su Google Cloud era prevista nei mesi successivi.
