Google publica AX, un orquestador tipo Kubernetes para agentes de IA
El proyecto, con licencia Apache 2.0, trata a los agentes como actores con estado y promete suspenderlos y reanudarlos en menos de un segundo sin arranque en frío.
Google ha publicado AX, un orquestador open source bajo licencia Apache 2.0 pensado para ejecutar y escalar cargas de agentes de IA autónomos. Va sobre Agent Substrate, un runtime de ejecución construido para multiplexar actores de forma densa, y trata a los agentes como actores con estado en lugar de microservicios o trabajos por lotes.
El problema que ataca es concreto. Un microservicio sin estado vive en ciclos cortos de petición y respuesta; un trabajo por lotes acaba cuando acaba. Un agente autónomo no hace ninguna de las dos cosas: consume CPU a saco mientras razona, ejecuta herramientas o evalúa código, y después se queda parado durante minutos esperando a un proveedor de inferencia, a una API externa o a que alguien apruebe algo. En Kubernetes, mantener esos sandboxes vivos durante los huecos es dinero quemado, y arrancarlos de cero cada vez añade latencia que rompe el bucle interactivo.
AX lo ataca por checkpoint: cuando un actor entra en reposo, guarda su estado y lo suspende; al reanudarlo, el proyecto promete intervalos por debajo del segundo sin arranque en frío. Cada sesión corre en un sandbox aislado con límites estrictos de CPU y memoria, y varios actores comparten los mismos workers de host.
Cuatro primitivas y una CLI en Go
El plano de control expone cuatro primitivas declarativas al estilo de Kubernetes, bajo el grupo de API ax.io/v1alpha1. Task define el ciclo de vida, los límites de recursos del sandbox y las referencias a la infraestructura de apoyo. Workspace monta el entorno antes de arrancar: repositorios Git, servidores MCP, paquetes de skills o un objetivo en lenguaje natural que un agente de inicialización ejecuta para preparar el toolchain. Gateway controla las políticas de salida a red, limitando a los agentes a listas explícitas de hostnames y puertos, e inyecta credenciales en esas peticiones. Model centraliza los parámetros del proveedor de LLM, la configuración de runtime y los secretos guardados en Kubernetes.
La interacción va por ax, una CLI escrita en Go. El operador despliega el plano de control en Kubernetes con ko y Redis, en el namespace ax-system, y trabaja con sus contextos habituales vía kubectx. Luego están ax apply para registrar manifiestos, ax watch para seguir fases y condiciones en tiempo real, ax ssh para entrar en un sandbox a depurar, y ax suspend y ax resume para controlar el estado de ejecución a mano.
Dónde se rompe el entusiasmo
En Hacker News la recepción está partida. Los ingenieros de infraestructura celebran que ataque el gasto de tener agentes parados esperando a un modelo o a una persona; los desarrolladores critican el flujo de trabajo "ergonómico" del marketing, porque mantener clústeres de Kubernetes, registros de contenedores y CRDs propias no es ergonomía precisamente. En Reddit se insiste en que AX es un runtime de ejecución de base, no un orquestador de aplicaciones como LangGraph o CrewAI, y en los canales de sistemas y seguridad se señala el aislamiento con gVisor como la parte que de verdad contiene el radio de daño, junto a problemas tempranos: conexiones caídas en el proxy de salida y una gestión de secretos todavía básica.
Todo eso lo coloca en un sitio concreto: no es un framework para montar un agente en una tarde, sino una pieza de cómputo para quien ya opera flotas grandes de agentes de larga duración y quiere dejar de pagar por lo que duerme.
