Google AX: la nueva capa de orquestación declarativa para agentes autónomos de IA que Kubernetes no estaba preparado para manejar
Por qué Kubernetes se queda corto cuando el workload es un agente de IA
El equipo de Google responsable de proyectos de IA en producción publicó un componente que lleva meses circulando en rumores y que acaba de aparecer como release open source: **AX** (alojado en `agentexecutor.io` y disponible en GitHub como `google/ax`), un **orquestador y runtime declarativo con licencia Apache 2.0** diseñado específicamente para ejecutar y escalar cargas de trabajo de agentes autónomos de IA. AX corre sobre **Agent Substrate**, una capa de infraestructura que Google ha estado madurando en silencio, y expone **cuatro primitivas Kubernetes-style** (Task, Workspace, Gateway, Model) bajo el API group `ax.io/v1alpha1`.
Este artículo explica por qué el lanzamiento importa para cualquier organización que esté construyendo, evaluando o simplemente monitoreando la categoría de "agentes de IA en producción", qué problema técnico resuelve AX que Kubernetes por sí solo no puede abordar, y qué decisiones de adopción y arquitectura tienen que tomar los equipos de plataforma en las próximas semanas.
---
El problema que Kubernetes no resuelve para agentes
Kubernetes es, sin discusión, la mejor abstracción de orquestación del mercado para workloads stateless y batch. Pero los agentes de IA modernos no son ninguna de las dos cosas. Son **stateful, bursty y de larga duración**.
Cuando un agente de IA ejecuta una tarea, atraviesa fases muy distintas:
- **Fases de cómputo intensivo**: mientras razona, ejecuta herramientas, evalúa código, hace llamadas a APIs externas, consume GPU y CPU de forma sostenida. - **Fases de espera prolongada**: esperando respuestas de modelos de lenguaje externos, esperando feedback de APIs que pueden tardar segundos o minutos, esperando intervención humana para aprobaciones, esperando eventos del entorno. - **Transiciones频繁 entre las dos fases**: un solo agente puede alternar entre ráfagas de cómputo y esperas prolongadas decenas de veces durante una sola tarea larga.
Kubernetes, por diseño, mantiene los pods activos durante todo el ciclo de vida. Esto significa que durante las fases de espera, los recursos asignados al sandbox del agente **siguen reservados pero subutilizados**. En un fleet grande de agentes, esta ineficiencia se multiplica hasta convertirse en un problema financiero y operativo serio.
Por el otro lado, si en lugar de mantener el sandbox activo lo destruyes y lo recreas cuando el agente necesita cómputo de nuevo, introduces **cold starts** — el tiempo de inicialización del sandbox — que degradan la experiencia interactiva y rompen el contexto del agente.
AX ataca exactamente este problema: **suspensión y reanudación de tareas en menos de un segundo**, preservando el estado del agente mientras libera los recursos durante las esperas.
---
Las cuatro primitivas: Task, Workspace, Gateway, Model
AX expone cuatro primitivas declarativas bajo el API group `ax.io/v1alpha1`, inspiradas deliberadamente en el modelo mental de Kubernetes pero diseñadas para agentes.
### Task
La primitiva **Task** define el ciclo de vida de ejecución de una tarea del agente. Especifica:
- Las restricciones de recursos del sandbox (CPU, memoria, GPU). - Las referencias a la infraestructura de soporte que la tarea necesita (workspaces, gateways, modelos). - Los criterios de terminación y los hooks de lifecycle.
Es, en cierto sentido, el equivalente declarativo de un `Pod` Kubernetes, pero con semánticas específicas para agentes: suspensión elegante, reanudación desde el último estado conocido, y manejo de dependencias externas que pueden tardar.
### Workspace
La primitiva **Workspace** maneja el ensamblaje del entorno **antes** de que la tarea empiece a ejecutarse. Esto es crítico porque un agente de IA productivo típicamente necesita:
- Repositorios Git montados en el sandbox (para que el agente pueda leer y modificar código). - Servidores **MCP** (Model Context Protocol) configurados para exponer herramientas externas al agente. - **Skill bundles** — paquetes de capacidades predefinidas que el agente puede invocar. - **Objetivos en lenguaje natural** que un agente de inicialización ejecuta para bootstrappear toolchains y dependencias del sistema antes de que la tarea principal arranque.
Lo interesante es que el Workspace permite especificar todo esto de forma declarativa. El operador describe qué necesita el agente; AX se encarga de provisionarlo.
### Gateway
La primitiva **Gateway** maneja las **políticas de seguridad de red de salida** del agente. Esto es donde AX se pone serio desde el punto de vista de seguridad:
- Los agentes solo pueden comunicarse con **hostnames y puertos explícitamente allowlisted**. - La inyección de credenciales en las peticiones salientes se maneja a nivel del Gateway, no en el código del agente.
Esto resuelve uno de los problemas más comunes de los agentes de IA en producción: el riesgo de que un agente con demasiada libertad termine hablando con infraestructura que no debería. Con AX, la política de red es declarativa y centralizada, no implementada como `iptables` custom o proxies en el código del agente.
### Model
La cuarta primitiva gestiona las referencias a los modelos de IA que el agente va a invocar. Esto incluye tanto modelos internos del proveedor (Gemini, modelos abiertos en Vertex AI) como endpoints externos compatibles con OpenAI o Anthropic. La abstracción permite que el agente sea agnóstico al proveedor de modelo, y que las decisiones de routing, fallback y cost tracking se gestionen a nivel de orquestador.
---
Agent Substrate: la capa de aislamiento
AX no ejecuta los sandboxes directamente sobre el kernel del host. Usa **gVisor**, el sandbox de Google que intercepta las syscalls de los contenedores y las ejecuta en espacio de usuario. Esto proporciona una capa de aislamiento adicional entre el agente y el sistema operativo del host.
gVisor añade overhead comparado con la ejecución nativa, pero el beneficio de seguridad es significativo: un agente que intente escapar de su sandbox o ejecutar syscalls peligrosas no puede escapar al kernel del host sin pasar por la capa de gVisor.
La elección de gVisor no es casual. Es la misma tecnología que usa Google Cloud Run y muchos servicios serverless de Google, así que hay experiencia operacional acumulada y battle-testing real.
---
Los problemas conocidos que Google está transparentando
Es raro que un lanzamiento open source venga acompañado de una lista honesta de problemas conocidos. AX lo hace, y eso habla bien del proyecto:
- **Egress proxy dropped connections.** El componente que media las conexiones de salida de los agentes tiene todavía casos edge donde se caen conexiones legítimas. Esto afecta la fiabilidad de tareas que dependen de llamadas externas frecuentes. - **Rudimentary secrets management.** La gestión de secretos (rotación, inyección, scoping) está en una fase inicial. Para organizaciones con requisitos estrictos de cumplimiento, esto es probablemente insuficiente sin una capa adicional encima.
Estos problemas no son dealbreakers para experimentación y para despliegues no críticos, pero sí son bloqueadores para producción en industrias reguladas o para escenarios que manejan secretos sensibles. La transparencia sobre estos puntos sugiere que Google los abordará en releases próximos, pero por ahora cualquier adopción empresarial seria necesita compensarlos con prácticas adicionales.
---
Lo que AX no es (y por qué importa entenderlo)
AX se posiciona deliberadamente **no como framework para hackers individuales**, sino como **primitiva de cómputo para empresas que gestionan fleets de agentes a gran escala y larga duración**.
Esto significa varias cosas:
- **No es un sustituto de LangChain, LlamaIndex, o CrewAI.** Esas son librerías para construir agentes individuales. AX es para ejecutar fleets de esos agentes en producción. - **No compite con Kubernetes directamente.** Corre sobre Kubernetes (o, al menos, sobre infraestructura compatible con el modelo mental de Kubernetes). Lo que hace es añadir una capa específica para agentes encima. - **No es un producto de Google Cloud exclusivo.** Es open source con Apache 2.0. Puede desplegarse on-prem o en cualquier cloud.
Para equipos que están construyendo agentes individuales y experimentando, AX es overkill. Para equipos que están intentando operacionalizar agentes en producción, AX es una respuesta directa a varios problemas reales.
---
Implicaciones para equipos de plataforma
Si tu organización está planeando o ejecutando cargas de agentes de IA en producción, AX tiene varias implicaciones concretas.
### Reevaluar la arquitectura de orquestación
Si actualmente estás ejecutando agentes sobre Kubernetes puro (pods, deployments, services estándar), vale la pena evaluar si las ineficiencias que AX resuelve te están costando dinero real. Para fleets grandes, la respuesta suele ser sí.
### Reevaluar las políticas de seguridad de red
El Gateway primitive de AX centraliza la gestión de políticas de red de salida. Si actualmente tienes políticas dispersas entre NetworkPolicies de Kubernetes, proxies sidecar, y reglas de firewall corporativas, AX ofrece un punto de consolidación.
### Considerar la observabilidad
AX expone estado de los agentes de forma estructurada. Esto habilita observabilidad que es difícil de conseguir con implementaciones ad-hoc: qué agentes están suspendidos, qué tareas están esperando input humano, qué modelos están siendo invocados, qué costos se están acumulando.
### Planificar la integración con el stack existente
AX no es drop-in. Requiere pensar la arquitectura del runtime de agentes desde la perspectiva de primitivas declarativas, no de scripts Python individuales. Para organizaciones con inversiones preexistentes en frameworks como LangChain, hay decisiones que tomar sobre cómo coexisten ambas aproximaciones.
---
La pregunta estratégica: ¿cuándo adoptar?
No todo el mundo necesita AX hoy. La respuesta honesta depende del perfil de la organización:
- **Si estás en fase experimental con agentes** (probando capacidades, evaluando proveedores de modelos, construyendo pruebas de concepto), AX probablemente es demasiado. Usa lo que tengas. - **Si estás operacionalizando el primer agente en producción** y ese agente es razonablemente estable, AX vale la pena evaluarlo como plataforma de despliegue, especialmente si anticipas escalar a múltiples agentes. - **Si ya tienes un fleet de agentes en producción** y estás sufriendo los problemas que AX resuelve (subutilización de recursos durante esperas, cold starts degradando UX, gestión manual de políticas de red por agente), AX es una respuesta directa que vale la pena probar.
Lo que no tiene sentido es esperar un año para ver cómo madura. El espacio de orquestación de agentes se está moviendo rápido, y la decisión de plataforma que tomes en los próximos 6 meses va a ser difícil de revertir más adelante.
---
Conclusión: una primitiva que faltaba en el stack
AX no es un proyecto más en el espacio de IA. Es el reconocimiento explícito de que **los agentes de IA son una categoría de workload distinta** que merece primitivas de orquestación específicas, no adaptaciones forzadas de primitivas pensadas para microservicios o batch jobs.
Google está apostando a que esta categoría va a dominar la próxima década de infraestructura cloud, y está poniendo el código disponible para que la industria pueda construir sobre esa base. Eso es significativo, independientemente de si AX termina siendo el estándar o simplemente uno de los contendientes.
Para los equipos de plataforma, la señal clara es: **empieza a pensar en tus agentes como una categoría propia de workload**. AX es una de las primeras materializaciones serias de esa categoría, y aunque no la adoptes, el modelo mental que propone (task suspension, gateway policy, declarative workspace) va a influir cómo se construyan las alternativas durante los próximos años.
---
*Fuentes: anuncio oficial de Google sobre AX; documentación en `agentexecutor.io`; repositorio GitHub `google/ax`; análisis técnico de Olimpiu Pop publicado en InfoQ; documentación de gVisor sobre sandboxing de contenedores.*