Agent Substrate de Google está pensado para flotas de agentes. Eso cambia lo que asume el equipo de plataforma

Hasta ahora, casi todo el trabajo con agentes en las empresas ha consistido en construir bien un agente: el prompt, las herramientas, la evaluación. El siguiente problema es menos vistoso. ¿Qué ocurre cuando una empresa ejecuta miles de agentes, cada uno ejecutando código, la mayoría inactivos casi todo el tiempo, y todos necesitan estar aislados del resto de la infraestructura?

La respuesta de Google para Kubernetes es GKE Agent Substrate, destacado en su resumen de infraestructura de IA de septiembre. Es una buena señal de hacia dónde se mueve el cuello de botella: de la inteligencia del modelo a la ejecución segura y económica.

Qué hace Agent Substrate

Google describe Agent Substrate como un runtime de código abierto para cargas de trabajo agénticas en GKE. El diseño parte de cómo se comportan realmente los agentes. El anuncio anterior de Google lo resumía así: los agentes trabajan en ráfagas cortas, pasan largos periodos inactivos y necesitan un aislamiento fuerte de kernel y de red, porque ejecutan código que nadie ha revisado línea a línea.

En lugar de mantener un contenedor vivo por agente, Agent Substrate separa el estado del agente de los pods. Los agentes suspendidos se guardan como snapshots y se reanudan bajo demanda en un pool compartido de workers ya preparados. La memoria de trabajo y los archivos se conservan, y el agente sigue donde lo dejó.

Las cifras de Google son ambiciosas: según la compañía, Agent Substrate ejecuta millones de sandboxes con una densidad 10 veces mayor que la de los runtimes de contenedores habituales, con reanudaciones por debajo de 500 milisegundos a más de 500 activaciones de suspensión y reanudación por segundo. El aislamiento usa gVisor, con Cloud Hypervisor como alternativa.

1. Solicitud a un agente
2. Snapshot restaurado en un worker preparado
3. El trabajo corre en un sandbox aislado
4. Agente suspendido en un snapshot
5. El worker vuelve al pool

Frontera de aislamiento para el código generado por IAMemoria y archivos del agente en reposo: datos que clasificar y proteger

Lea el estado con atención

La documentación es más precisa que el titular. Agent Substrate está disponible para todos los clientes de Google Cloud para evaluación y uso fuera de producción; el soporte en producción se ofrece a una lista de clientes aprobados, dentro de un programa de GA privado. Solo funciona en clústeres GKE Standard, no en Autopilot, y requiere Workload Identity Federation.

También enumera limitaciones que importan en un diseño empresarial: no admite GPU passthrough, las conexiones de red abiertas no se conservan al suspender y reanudar, y no admite políticas de egress. Google indica que no tiene coste adicional en GKE.

Su proyecto hermano, GKE Agent Sandbox, está en disponibilidad general, y en septiembre Google añadió una versión optimizada para aprendizaje por refuerzo.

Qué cambia para el equipo de plataforma

Un runtime gestionado por el proveedor del modelo, como la Agents API de OpenAI, oculta la ejecución detrás de una API. Agent Substrate es la opción contraria: la ejecución se queda en sus clústeres y su equipo de plataforma es el responsable. Eso aporta control, y una lista de decisiones.

El aislamiento es el punto de partida, no el diseño. Un sandbox gVisor protege al host del código generado por IA. No decide a qué puede llegar ese código. Como hoy no se admiten políticas de egress, los controles de red tienen que venir de otra capa de la arquitectura antes de ejecutar ahí nada sensible.

Los snapshots son datos. Si la memoria y los archivos del agente se conservan entre ejecuciones, el almacenamiento de snapshots guarda todo aquello con lo que trabajaba el agente: datos de clientes, credenciales, resultados intermedios. Clasificación, cifrado, retención y acceso necesitan un responsable, como cualquier base de datos.

La identidad por agente sigue siendo cosa suya. La documentación exige Workload Identity Federation para el sistema, pero no describe un modelo de identidad por agente. Si miles de agentes comparten una cuenta de servicio, el registro de auditoría no puede distinguirlos.

La inactividad es el nuevo factor de coste. La economía de una flota de agentes depende de cuánto se paga por agentes que esperan. Suspender y reanudar es una palanca de coste, y la planificación de capacidad pasa a ser una conversación conjunta entre plataforma y FinOps.

España y Latinoamérica: el estado tiene jurisdicción

El punto más concreto para empresas sujetas al RGPD en España, o a las leyes de datos de México, Colombia o Chile, es el almacenamiento de snapshots. Guarda el estado de los agentes, y ese estado puede incluir datos personales. Si evalúa Agent Substrate, compruebe el soporte por región y mantenga el bucket de snapshots en la misma jurisdicción que los datos que tratan los agentes, por ejemplo en la región de Madrid para datos europeos. Así se evita que un detalle de infraestructura se convierta en una transferencia internacional de datos.

Para la mayoría de las empresas de la región, las flotas de miles de agentes aún no son una realidad. Pero las preguntas ya valen para cualquier agente que ejecute código: dónde vive el estado, a qué puede llegar el código y quién responde por cada agente.

Qué hacer ahora

1. Evalúe en un proyecto fuera de producción, como prevé la documentación, con datos sintéticos.
2. Diseñe primero los controles de egress de red, ya que el runtime no aplica esas políticas.
3. Trate el bucket de snapshots como un almacén sensible: claves de cifrado, retención y revisión de accesos.
4. Defina el modelo de identidad antes de que crezca el número de agentes: una identidad por agente o por tipo de agente, nunca una para todos.
5. Mida la inactividad de sus agentes actuales para estimar cuánto ahorraría realmente la densidad.

En resumen

Agent Substrate es infraestructura para una etapa a la que la mayoría de las empresas aún no ha llegado: flotas de agentes, no pilotos. Pero las preguntas que plantea ya son actuales. Son los mismos controles que recogemos en nuestra guía del stack de 2026. Los equipos de plataforma que las respondan pronto serán los que puedan escalar.