Google décrit Agent Compute Engine (ACE) comme une infrastructure où chaque session d’agent s’exécute dans une microVM persistante et isolée matériellement. Un harness distinct choisit les actions, tandis que le sandbox les exécute. Dans son article technique publié le 22 octobre 2026, Google présente cette séparation comme la base de sa conception pour les agents d’IA.
Le harness choisit, le sandbox exécute
Le harness est le composant qui appelle le modèle et décide des actions à lancer. Le sandbox, ici une microVM, exécute le code, les commandes et les opérations dans un navigateur, puis renvoie le résultat au harness. Google décrit une microVM dédiée à chaque session d’agent, avec une isolation matérielle.
La distinction permet de situer les rôles : le harness pilote le travail, le sandbox fournit l’environnement d’exécution. Google présente ACE comme une infrastructure conçue pour associer le contrôle d’une machine virtuelle à la rapidité et à la densité recherchées pour les conteneurs.
Du harness au checkpoint : identité et exécution
Google décrit un système où l’identité et les identifiants nécessaires aux requêtes restent gérés hors du sandbox. Chaque session utilise une Agent Workload Identity éphémère, fondée sur SPIFFE, pour identifier son trafic. Google distingue aussi l’identité de l’utilisateur, celle de l’agent délégué agissant pour son compte et l’Agent Workforce Identity.
La passerelle externe Agent Gateway vérifie la délégation de l’utilisateur, l’identité de l’agent et du nœud, ainsi que la politique de sortie réseau. Elle ajoute ensuite l’identifiant du service destinataire pendant le transit. Selon Google, le sandbox ne conserve pas de clés API, de jetons OAuth de renouvellement ou de clés de comptes de service dans sa mémoire ou sur son disque. Le trafic réseau est médié : les microVM n’ont pas d’interface réseau virtuelle standard ni d’accès direct au VPC.
Ce qui arrive à une session inactive
Quand l’agent termine un appel à un outil et attend la suite, Google dit que l’hôte crée un checkpoint, c’est-à-dire une sauvegarde de l’état de la session, puis libère les ressources actives de l’hôte. L’état reste disponible pour reprendre le travail. Google décrit également le partage des pages mémoire inchangées entre microVM d’un même hôte, tandis que les pages modifiées restent privées.
Les données sont réparties en trois catégories selon leur rôle :
| Catégorie | Rôle | Stockage décrit par Google |
| Données temporaires de travail | Espace de travail éphémère | Overlay temporaire |
| Volumes partagés | Images, chaînes d’outils et caches de paquets en lecture seule | Données partagées |
| Espaces de travail utilisateur | Données durables de l’utilisateur | Espace persistant |
Google indique qu’Hyperdisk sert ces catégories sauf indication contraire et que les données sont chiffrées au repos et en transit.
Un pool matériel pour plusieurs charges d’agents
Google répartit les usages visés entre les agents interactifs grand public ou d’entreprise, les espaces de travail de développement logiciel, les tâches d’évaluation et d’apprentissage par renforcement, et les environnements sandbox de ses propres services. L’entreprise décrit un pool matériel partagé et une planification tenant compte des politiques. Les tâches flexibles dans le temps, comme les évaluations par lots, peuvent utiliser les périodes de moindre demande et céder la place aux travaux interactifs.
Google invoque la perspective de faire tourner des centaines de millions d’agents à l’échelle planétaire pour expliquer pourquoi les infrastructures classiques ne suffisent pas à ses besoins. Ce chiffre motive la conception d’ACE ; il ne décrit pas un volume mesuré d’agents exécutés par la plateforme.
ACE géré et Agent Substrate pour Kubernetes
The New Stack décrit ACE comme un service géré dans Google Cloud, tandis qu’Agent Substrate est un runtime open source pour GKE et Kubernetes, construit sur Agent Sandbox. Selon cette publication, Substrate peut isoler les charges avec des microVM ou gVisor. La différence porte donc sur le modèle de déploiement : ACE est présenté comme un service dont Google exploite l’infrastructure, alors que Substrate s’inscrit dans un environnement Kubernetes.
Le calendrier de préversion annoncé par Google
Le 22 octobre 2026, Google a indiqué viser une préversion d’ACE sur Google Cloud dans les mois à venir.
