Google describe Agent Compute Engine (ACE) como una infraestructura de ejecución para agentes de IA: cada sesión dispone de una microVM persistente y aislada por hardware, mientras un componente externo decide qué hacer y otro entorno ejecuta las acciones. Así, la capa que dirige al agente queda separada de la que ejecuta código y herramientas.
El harness dirige y el sandbox ejecuta
El harness es la capa que llama al modelo, elige acciones y envía comandos. El sandbox es el entorno aislado donde se ejecutan esos comandos, el código y las operaciones del navegador. Google describe una microVM dedicada para cada sesión de agente, con control del sistema operativo y aislamiento de hardware.
ACE es infraestructura de ejecución, no el agente Gemini para el trabajo tratado en la cobertura de NeoTeo sobre Gemini y Microsoft 365. La diferencia es entre el agente que realiza una tarea y la plataforma que proporciona su entorno de ejecución.
Del comando al checkpoint: ejecución y acceso
Google describe una identidad de corta duración para identificar el tráfico del sandbox y un gateway externo que comprueba las solicitudes antes de intermediar credenciales.

La identidad de workload del agente, basada en SPIFFE, es temporal y se usa para el tráfico del sandbox. Google distingue cuatro identidades: la del usuario, la del agente delegado para actuar en su nombre, la identidad de workload del agente y la identidad de workforce del agente. El permiso delegado permanece en un servicio de autorización central.
Según Google, el sandbox no almacena credenciales persistentes, claves de API, tokens de actualización OAuth ni claves de cuentas de servicio. Tampoco puede acceder al servidor de metadatos de la instancia. Cuando una solicitud necesita credenciales de un servicio, el Agent Gateway, situado fuera de la microVM, comprueba la delegación del usuario, las identidades del agente y del nodo, y la política de salida antes de añadir la credencial del servicio durante el tránsito.
Google también describe una red mediada: las microVM no tienen una interfaz de red virtual convencional ni acceso directo a una VPC. El tráfico pasa por canales y proxies antes de llegar al gateway.
Qué conserva una sesión mientras el agente espera
Cuando termina una llamada a una herramienta y el agente espera la siguiente instrucción, Google dice que el host crea un checkpoint, una captura del estado de la sesión, y libera recursos activos del host. El estado se conserva para reanudar el trabajo más tarde.
Para reducir la duplicación de memoria, Google describe el uso de DAX y de clones copy-on-write (CoW). Las microVM de un mismo host pueden compartir páginas sin cambios de imágenes, entornos de ejecución, bibliotecas y binarios; las páginas modificadas se mantienen en memoria privada.
Google divide los datos de ACE en tres categorías:
| Categoría | Función y permanencia |
| Datos temporales de trabajo | Espacio temporal para datos de uso efímero. |
| Volúmenes compartidos o de solo lectura | Imágenes, herramientas y cachés de paquetes reutilizables. |
| Espacios de trabajo del usuario | Datos duraderos que persisten entre sesiones. |
Google afirma que Hyperdisk proporciona almacenamiento para estas categorías salvo que se especifique otra opción, y que los datos se cifran en reposo y durante el tránsito.
Cómo distribuye Google las cargas de trabajo
Google describe un conjunto compartido de hardware con planificación global y consciente de las políticas. Las tareas flexibles en el tiempo, como evaluaciones y trabajos de investigación por lotes, pueden aprovechar periodos de menor demanda y ceder capacidad a las tareas interactivas.
La compañía agrupa los usos previstos en cuatro clases: agentes interactivos para consumidores y empresas; espacios de trabajo persistentes para ingeniería de software; evaluación a gran escala y aprendizaje por refuerzo; y entornos aislados para servicios de Google. Google afirma que ACE ya se utiliza internamente con Gemini, Antigravity y sus flujos de evaluación y aprendizaje por refuerzo. La referencia de la compañía a cientos de millones de agentes expresa la escala que motivó el diseño, no una capacidad medida de ACE.
ACE gestionado y Agent Substrate para Kubernetes
La diferencia principal está en el modelo de despliegue. The New Stack describe ACE como un servicio gestionado de Google Cloud, con Google a cargo de los hosts y los clientes al mando de las imágenes de entorno, las identidades, el acceso de red y el ciclo de vida. El mismo medio describe Agent Substrate como un runtime de código abierto para GKE y Kubernetes, construido sobre Agent Sandbox, que admite aislamiento con microVM o gVisor.
Para un equipo que evalúa ambas opciones, esa diferencia separa una flota gestionada por Google de un runtime pensado para ejecutarse en Kubernetes. Las cifras de densidad y rendimiento que The New Stack atribuye a Google corresponden a Agent Substrate, no a ACE.
El plazo que Google dio para la vista previa
El 22 de octubre de 2026, Google dijo que la vista previa de ACE en Google Cloud estaba prevista para los meses siguientes.