Google AX aísla agentes de IA en Kubernetes
Google AXKubernetesИИ-агенты
AX separa al agente del clúster
Lo más relevante de AX no es Kubernetes en sí, sino el intento de convertir la ejecución de código de agente potencialmente no confiable en una entidad de infraestructura independiente. En el repositorio oficial de Google, el proyecto se describe como un runtime declarativo que aísla tareas, conecta espacios de trabajo, restringe la red saliente y escala cargas de agentes en un clúster.
En septiembre de 2026, AX, o Agent Executor, se publicó bajo licencia Apache 2.0. Sus primitivas principales muestran con claridad el modelo de ejecución: Task inicia una tarea de agente, Workspace le proporciona contexto de archivos o un repositorio, Gateway define el acceso externo y Model configura el proveedor del modelo y las credenciales.
No es simplemente un Kubernetes Job con un contenedor. AX está pensado para procesos de agentes persistentes y con estado que necesitan un contexto de trabajo gestionado y un límite de red claro. Son precisamente los detalles que suelen descontrolarse cuando se permite a un agente escribir archivos, ejecutar código y contactar sistemas externos.
Sin embargo, AX no es autosuficiente. La documentación del repositorio incluye entre los requisitos un clúster de Kubernetes, el generador de imágenes ko, un registro de contenedores accesible desde el clúster y la Agent Substrate Control API. Gran parte de la ejecución real reside en Agent Substrate, mientras AX se encarga de la gestión declarativa y la orquestación.
Google presenta AX como un orquestador de alto rendimiento diseñado para miles de millones de cargas de agentes autónomos por clúster. La afirmación es ambiciosa, pero los materiales públicos no incluyen una suite oficial de benchmarks reproducibles. Por ahora es un objetivo arquitectónico, no una cifra en la que confiaría para planificar capacidad.
El aislamiento pasa a formar parte del modelo del agente
AX introduce un cambio útil: la seguridad del agente no se define mediante acuerdos dentro de una aplicación, sino mediante objetos de infraestructura separados. La red, el espacio de trabajo, el modelo y la tarea ejecutable reciben límites explícitos que pueden describirse y controlarse con un proceso similar al de Kubernetes.
Este enfoque beneficia sobre todo a plataformas donde operan simultáneamente agentes distintos, con código no confiable o permisos de acceso diferentes. Para una instalación pequeña, el coste de entrada puede ser elevado: además de Kubernetes, hay que mantener un registro, la construcción de imágenes y una capa independiente de Agent Substrate.
Yo revisaría primero la solidez de los límites, no la escala anunciada: la posibilidad de eludir el Gateway de red, el manejo de credenciales del modelo, la recuperación de tareas largas y el comportamiento ante fallos de la capa de control. La idea de AX es sólida, pero su valor dependerá de que un agente averiado siga siendo un problema únicamente dentro de su propio sandbox.