Principales destacados
- Una máquina para cada agente: Agent Compute Engine ofrece entornos aislados por hardware para ejecutar tareas autónomas con mayor seguridad.
- Infraestructura probada internamente: la tecnología ya se utiliza en sistemas de Google, incluidos los agentes de Gemini y Antigravity.
- Competencia con AWS y startups: la novedad intensifica la competencia por una infraestructura capaz de ejecutar miles de agentes de IA sin comprometer la seguridad.
Google quiere resolver uno de los desafíos más importantes de la próxima etapa de la inteligencia artificial: ¿cómo permitir que los agentes autónomos ejecuten tareas complejas, escriban código y controlen navegadores sin poner en riesgo otros sistemas?
La respuesta de la compañía consiste en transformar parte de la infraestructura que sustenta sus propios agentes en un servicio de computación en la nube. Anunciado este jueves 22 de octubre durante AGNTCon + MCPCon, un evento de la Linux Foundation celebrado en San José, Agent Compute Engine proporciona entornos computacionales aislados para agentes de inteligencia artificial.
La propuesta va más allá de ofrecer potencia de procesamiento. Cada agente recibe su propia máquina virtual aislada, con recursos para ejecutar tareas de forma persistente, mientras que los mecanismos de seguridad limitan el impacto de posibles ataques.
El servicio tiene previsto entrar en fase de vista previa en Google Cloud durante los próximos meses. Según The New Stack, el lanzamiento inicial debería producirse todavía en 2026.
🤖 Un ordenador propio para cada agente
Hasta ahora, buena parte de la infraestructura de IA se ha diseñado para responder preguntas, generar textos o producir código. Los agentes autónomos necesitan algo diferente: deben ejecutar acciones, acceder a herramientas y mantener el estado de tareas que pueden durar mucho más que una simple interacción con un chatbot.
Agent Compute Engine se ha desarrollado para responder a este escenario.
Cada agente recibe una microVM, una máquina virtual ligera con sus propios recursos de aislamiento. En ese entorno, puede ejecutar comandos de shell, controlar un navegador headless, escribir código y realizar operaciones con privilegios de administrador dentro de la máquina virtual.
Esto permite que el agente trabaje de forma relativamente independiente, incluso en tareas que se prolongan durante días o semanas.
🔐 El detalle que marca la diferencia: cada entorno dispone de su propio kernel invitado, credenciales de corta duración, una identidad verificable criptográficamente y almacenamiento persistente basado en Hyperdisk.
En la práctica, el objetivo es impedir que un agente comprometido acceda directamente a los recursos de otros agentes o a la infraestructura que los ejecuta.
🛡️ La seguridad comienza con una premisa poco optimista
Google ha adoptado un enfoque que parte de una hipótesis deliberadamente conservadora: un agente puede ejecutar código potencialmente peligroso, por lo que todo lo que sucede dentro de su entorno debe tratarse como una posible amenaza.
La compañía describe su filosofía de seguridad en los siguientes términos:
Supón que un atacante controla todo lo que hay dentro del sandbox y garantiza que no encuentre allí nada que pueda utilizar.
Esta lógica es especialmente importante porque los agentes de IA pueden recibir instrucciones de fuentes externas, procesar archivos no confiables e interactuar con páginas web. Una vulnerabilidad o una instrucción maliciosa puede convertir una herramienta útil en un vector de ataque.
El aislamiento por hardware busca reducir ese riesgo mediante la separación de los entornos de ejecución.
🔑 ¿Y qué ocurre con las credenciales? El sistema utiliza un proxy externo al sandbox para incorporarlas cuando es necesario. No se almacenan directamente dentro del entorno controlado por el agente, lo que reduce la posibilidad de que queden expuestas si este resulta comprometido.
El diseño también utiliza Cloud Hypervisor y el procesador de descarga de tareas Titanium de Google para ejecutar las microVM.
⚙️ Cómo ejecutar miles de agentes sin desperdiciar recursos
Crear una máquina virtual para cada agente plantea una cuestión inevitable: el coste de mantener tantos entornos funcionando, incluso cuando están esperando una respuesta de un modelo de IA o una acción humana.
Google ha desarrollado mecanismos para reducir ese desperdicio.
Cuando un agente permanece inactivo, su microVM puede pausarse mediante un proceso de checkpoint y restauración. Se conserva el estado de la ejecución para que el trabajo pueda continuar posteriormente, sin necesidad de mantener todos los recursos activos durante la espera.
La compañía también utiliza el intercambio de memoria con copy-on-write. Con esta técnica, varios agentes pueden partir de una misma imagen del sistema operativo sin necesidad de duplicar inmediatamente todas las páginas de memoria.
El resultado que se busca es combinar tres características que no siempre conviven fácilmente:
• Aislamiento: cada agente opera en su propio entorno.
• Persistencia: las tareas pueden continuar después de periodos de inactividad.
• Densidad: muchos entornos pueden compartir recursos físicos de forma eficiente.
💡 El desafío no consiste únicamente en colocar cada agente dentro de una caja separada. También hay que hacerlo sin que ejecutar miles de agentes resulte demasiado caro o lento.
🧩 Google también quiere controlar el ecosistema de agentes
Agent Compute Engine forma parte de una estrategia más amplia para administrar agentes de IA, sus herramientas y sus permisos.
Google presentó un conjunto de recursos complementarios:
| Herramienta | Función |
|---|---|
| Agent Gateway | Gestiona el tráfico y aplica políticas a las interacciones de los agentes. |
| Agent Registry | Cataloga agentes, herramientas y servidores MCP aprobados. |
| Agent Identity | Asigna identidades exclusivas a los agentes mediante SPIFFE. |
| Agent Compute Engine | Proporciona entornos aislados para ejecutar tareas. |
La integración de estos componentes pretende permitir que las empresas supervisen qué agentes están operativos, qué herramientas pueden utilizar y cómo se controlan sus actividades.
Un detalle importante es que la gobernanza no se limita a los agentes alojados en Google Cloud. La compañía también está ampliando la compatibilidad con entornos multicloud y agentes de programación, incluido Claude Code en dispositivos gestionados.
Esto apunta a una estrategia que va más allá de vender capacidad computacional: Google también quiere participar en la capa de control y seguridad que utilizan las empresas para administrar agentes de diferentes proveedores.
☸️ Para quienes utilizan Kubernetes, existe otra opción
No todos los equipos quieren adoptar un nuevo servicio gestionado para ejecutar sus agentes. Algunos prefieren utilizar la infraestructura que ya operan con Kubernetes.
Para este público, Google ofrece Agent Substrate, un runtime de código abierto para Google Kubernetes Engine (GKE).
Según la compañía, la solución puede alcanzar hasta 10 veces la densidad de la computación tradicional. En una prueba de rendimiento divulgada por Google, la infraestructura soportó 500 activaciones por segundo en un escenario con 200.000 agentes.
Estas cifras corresponden a resultados presentados por la propia empresa y deben interpretarse dentro de las condiciones específicas de la prueba, no como una garantía de rendimiento para cualquier aplicación.
Aun así, la oferta demuestra que Google pretende atender tanto a los equipos que buscan una infraestructura gestionada como a aquellos que prefieren un mayor control sobre la implementación.
🥊 AWS, E2B y Daytona participan en la misma disputa
Agent Compute Engine entra en un mercado que ya cuenta con competidores establecidos.
Amazon Web Services ofrece microVM para sesiones de agentes a través de Bedrock AgentCore. Por su parte, las startups E2B y Daytona comercializan entornos aislados para ejecutar código y tareas de agentes.
La diferencia que Google pretende destacar es su experiencia operativa. La infraestructura se desarrolló y se utilizó internamente en sistemas como Gemini, Antigravity y los pipelines de entrenamiento de modelos.
Gautham Thambidorai, vicepresidente y Google Fellow de Gemini, afirmó que las microVM proporcionan la capacidad de respuesta, el aislamiento por hardware y la densidad necesarios para ofrecer sandboxes interactivos a usuarios de todo el mundo.
La experiencia interna puede representar una ventaja, pero no pone fin a la competencia. El precio, la latencia, la facilidad de integración, los controles administrativos y la compatibilidad con diferentes modelos serán factores importantes para la adopción empresarial.
🚀 El siguiente paso es llevar los agentes del laboratorio al trabajo real
El lanzamiento refleja un cambio en el papel de la infraestructura en la nube. En lugar de limitarse a alojar aplicaciones tradicionales o proporcionar modelos que responden a solicitudes, los proveedores están construyendo entornos en los que los sistemas de IA pueden ejecutar tareas por su cuenta.
Esto aumenta las exigencias de seguridad y gobernanza. Un agente que únicamente genera una respuesta presenta riesgos diferentes a los de otro que ejecuta código, accede a archivos e interactúa con sistemas corporativos.
Google afirma que ya utiliza Agent Compute Engine para ejecutar Gemini como agente en tareas de trabajo. Sin embargo, la expansión a los clientes de Google Cloud todavía depende de la llegada de la versión preliminar anunciada.
La cuestión ahora es cuánto de esta infraestructura podrá ofrecerse a un coste competitivo y con suficiente integración para que las empresas ejecuten agentes a gran escala.
Si Google consigue equilibrar aislamiento, rendimiento y coste, las microVM podrían convertirse en una pieza importante de la infraestructura empresarial de IA. La siguiente etapa será demostrar que la experiencia acumulada dentro de la propia compañía también funciona para clientes con aplicaciones, modelos y requisitos de seguridad muy diferentes.
