Sin tarjeta de red, sin una sola credencial y en pausa mientras el modelo piensa: así ejecuta Google a cada agente de Gemini dentro de Agent Compute Engine, el servicio que presentó el 22 de octubre de 2026 en AGNTCon + MCPCon. Llegará en preview "en los próximos meses", pero Google ya ha contado cómo está construido, y la arquitectura da más lecciones que el anuncio.
El problema: un agente no es un microservicio
Un agente útil necesita lo que nunca le daríamos a un servicio web: root, instalar paquetes, ejecutar código que acaba de escribir y llamar a APIs con la identidad de un usuario. Y a la vez pasa la mayor parte del tiempo esperando: a que responda el modelo, a que termine una herramienta o a que un humano apruebe algo. Meterlo en un contenedor compartido da poco aislamiento para lo primero y desperdicia recursos con lo segundo.
Google dice que Agent Compute Engine ya es la base de Gemini como agente para tareas de trabajo, así que no es un prototipo: es la pieza que usa internamente, convertida en producto.
Las decisiones clave
| Problema | Decisión de Google |
|---|---|
| El agente ejecuta código arbitrario como root | Una micro-VM por agente con su propio kernel invitado, tras una frontera de Cloud Hypervisor aislada por hardware |
| El host puede quedar comprometido | Host sin estado e inmutable: raíz de solo lectura con dm-verity, verificada en el arranque por el chip Titan |
| Exfiltración por red | La micro-VM arranca sin interfaz de red; todo sale por virtio-vsock a un proxy local sin privilegios y de ahí al Agent Gateway |
| Robo de credenciales | Dentro no hay claves de API, tokens OAuth ni acceso al servidor de metadatos; el gateway cambia el token en vuelo |
| Agentes ociosos | Checkpoint y restauración: un sandbox inactivo no consume recursos activos del host |
La pieza que más me interesa es la de las credenciales. Google define cuatro identidades: la del usuario, que solo autentica la tarea; una delegación de larga duración que vive en un servicio de autorización central y nunca en el nodo; una identidad de carga de trabajo efímera basada en SPIFFE, que solo sirve para el tráfico del sandbox y no puede llamar a APIs de backend; y la cuenta propia del agente cuando actúa por su cuenta. El Agent Gateway comprueba las tres primeras e inserta la credencial real del backend al salir. Si el agente sufre una inyección de prompt, no hay nada dentro que robar.
Dormir sin ocupar la máquina
El runtime del sandbox está diseñado junto al ejecutor del host, de modo que este sabe cuándo ha terminado una herramienta y el agente está "pensando". En ese momento lo congela. Para que despertarlo sea barato, las imágenes base se precalientan y se mapean en memoria con DAX y copia en escritura: todas las micro-VM de un host comparten una sola copia del sistema operativo, las librerías y los binarios, y cada agente solo ocupa las páginas que modifica.
Las mismas primitivas permiten clonar, hacer fork, rebobinar y deshacer. Para evaluaciones y aprendizaje por refuerzo, Google habla de tomar una instantánea de un entorno y abrir miles de copias en paralelo con la memoria deduplicada.
Agent Substrate: la versión open source para GKE
Junto al servicio gestionado, Google ha liberado Agent Substrate, un runtime para GKE con el mismo diseño, que funciona en cualquier clúster de Kubernetes y con cualquier harness, Claude Code incluido. Permite elegir entre micro-VM y gVisor, y estas son sus cifras:
| Agent Compute Engine | Agent Substrate | |
|---|---|---|
| Modelo | Servicio gestionado | Open source, sobre GKE o cualquier Kubernetes |
| Aislamiento | Micro-VM con Cloud Hypervisor y Titanium | Micro-VM o gVisor |
| Estado | Preview "en los próximos meses" | Disponible |
| Rendimiento publicado | Sin cifras de arranque | 200.000 agentes, 500 activaciones por segundo, menos de 500 ms en suspender y reanudar |
| Densidad | "Órdenes de magnitud" más que VMs convencionales | Hasta 10 veces más que la computación tradicional |
Qué se puede aprender
Lo trasladable no son las micro-VM, sino tres ideas. La primera: tratar al agente como un inquilino hostil, no como un servicio de confianza. Ni la clave del modelo ni el token de GitHub tienen que vivir dentro del sandbox; un proxy de salida que inyecta credenciales solo hacia destinos aprobados se puede montar con Envoy o un egress gateway.
La segunda: el coste de un agente está en el tiempo ocioso. Si tu plataforma mantiene un pod vivo durante toda la conversación, pagas por esperar. Diseñar para suspender y reanudar, con el estado en disco y no en memoria del proceso, abarata más que cualquier ajuste de requests.
La tercera: una identidad por agente, efímera y auditable, es lo que hace posible el resto. Sin ella, la política de red y la trazabilidad (Google promete métricas, logs y trazas compatibles con OpenTelemetry por cada salto) no tienen a quién atribuir nada.
Qué no es trasladable
La defensa en profundidad de Google se apoya en hardware propio, Titanium y Titan, que no tienes en tu centro de datos ni en otra nube. Y del servicio gestionado faltan los datos que deciden una adopción: precio, regiones, tiempos de arranque y límites de CPU y memoria. Hasta que la preview los publique, lo que ya se puede usar es Agent Substrate, y sus 500 ms son la cifra de un benchmark de la propia Google.
Fuentes
- Introducing Agent Compute Engine and expanded agent governance, Google Cloud Blog, 22 de octubre de 2026.
- Inside Agent Compute Engine, Google Cloud Blog, 22 de octubre de 2026.