Google AX

Google AX (Agent Executor) es el runtime open source de Google para ejecutar agentes de IA a escala, y a octubre de 2026 su tesis central es clara: separar el ciclo de vida lógico de un agente del ciclo de vida de los recursos de computación que lo sostienen.

Lo más interesante de AX no es que ofrezca una API más para crear agentes de IA, sino que intenta responder a una pregunta mucho más profunda: si una plataforma necesita ejecutar cientos de miles de agentes persistentes al mismo tiempo, ¿seguirán siendo suficientes Kubernetes y los frameworks de agentes actuales?

AX se acerca al concepto de Agent Runtime o plataforma de ejecución distribuida. Trata un agente como una carga de trabajo que puede ejecutarse durante mucho tiempo, fallar, pausarse, reanudarse y volver a obtener recursos, en lugar de tratarlo como un programa convencional que termina cuando completa su tarea. El diseño actual está orientado a grandes volúmenes de Tasks de corta duración y utiliza Redis junto con Controllers escalables horizontalmente, evitando almacenar todo el estado en el etcd de Kubernetes.

¿Qué es Google AX y por qué existe?

Las aplicaciones tradicionales suelen encajar en tres categorías: Service, Job o Batch. Un Service permanece activo; un Job termina cuando completa su ejecución. En ambos casos, el ciclo de vida del contenedor va pegado al de la tarea.

Un agente autónomo es diferente. Un Coding Agent puede modificar código de forma continua, ejecutar pruebas, llamar a servidores MCP, esperar la respuesta del modelo y seguir trabajando. Un Research Agent puede pasar horas buscando, analizando y organizando información. Cuando miles de usuarios ejecutan agentes a la vez, buena parte del tiempo esos sistemas están, en realidad, esperando.

Si cada agente mantiene ocupado un Pod completo durante todo ese rato, la CPU apenas trabaja pero el recurso de computación sigue reservado y facturado. Ahí nace el problema que AX quiere resolver: el coste del agente inactivo.

Por eso la idea central de AX no es simplemente «desplegar agentes en Kubernetes», sino desacoplar el ciclo de vida del agente del ciclo de vida de la infraestructura. Un agente puede pausarse, liberar su entorno para otras tareas y recuperar los recursos cuando necesite continuar. En eso consiste buena parte de su valor arquitectónico.

La arquitectura de AX: Task, Workspace, Gateway y Model

AX divide el entorno de ejecución de un agente en cuatro primitivas declarativas:

• Task: la unidad básica de ejecución aislada. Define la imagen, los comandos, CPU y memoria, las variables de entorno, el Workspace y el Gateway. Se puede crear, pausar, reanudar y destruir, y un agente puede combinar varias Tasks para construir un árbol de trabajo.
• Workspace: resuelve cómo preparar el entorno antes de iniciar el agente. Repositorios Git, servidores MCP, Skills y dependencias se declaran una vez y se montan en múltiples Tasks, de modo que el framework no repite la lógica de inicialización.
• Gateway: establece el perímetro de red. Define a qué hosts y puertos externos puede acceder el agente. Para un agente capaz de ejecutar código y usar herramientas es crucial: el Sandbox determina qué puede hacer localmente, mientras que el Gateway controla a qué puede conectarse hacia fuera.
• Model: separa el proveedor, el identificador del modelo, los parámetros y la credencial del resto de la configuración. Cambiar de modelo, rotar una API Key o ajustar parámetros no obliga a reescribir la configuración de ejecución de cada agente.

AX Server se encarga de la API y de la persistencia del estado; el Controller obtiene las tareas desde Redis Streams y realiza la programación, mientras la ejecución efectiva se delega en Agent Substrate. El diseño explica que almacenar enormes cantidades de Tasks de corta duración como CRDs de Kubernetes presionaría la capacidad y el throughput de escritura de etcd, de ahí que AX apoye su estado y sus streams en Redis y permita escalar los Controllers horizontalmente.

Suspend / Resume y Agent Substrate: el diseño más diferenciador

Lo más atractivo de AX no es su YAML, sino Suspend / Resume. En el modelo ideal, un agente sigue un ciclo de Checkpoint → Suspend → liberar Worker → Resume → continuar la ejecución, en lugar de mantener una máquina ocupada permanentemente.

La documentación del Runner explica que, durante el Suspend, Agent Substrate guarda el contenido de /workspace. Cuando el agente se reanuda, se vuelve a crear el contenedor y se recupera el estado de los archivos: el proceso que continúa es nuevo, pero accede al estado de trabajo guardado.

Esto encaja especialmente bien con Coding Agents, Research Agents asíncronos y escenarios de alta concurrencia. Por ejemplo, 10.000 agentes no tienen por qué implicar 10.000 entornos de ejecución completos: si una gran parte espera la entrada de un usuario, una respuesta del modelo o una herramienta externa, los Workers subyacentes pueden reutilizarse para otras tareas.

Agent Substrate está diseñado alrededor de justo ese concepto: muchos Actors se mapean sobre un número menor de Workers, usando el ciclo de vida de los Actors y la reutilización de Workers para aumentar la densidad.

El modelo también introduce costes y problemas nuevos: el coste de los Snapshots, la latencia de recuperación, la consistencia del estado y la complejidad de la programación pasan a formar parte del problema. Incluso en los Issues actuales del proyecto se debate si conviene pausar el agente tras cada interacción o tras un periodo de inactividad, señal de que la estrategia operativa óptima todavía no está cerrada.

¿Sustituye AX a Kubernetes? Diferencias clave

No. AX no pretende reemplazar a Kubernetes, sino ocupar el hueco que queda entre la orquestación de contenedores y los agentes como carga de trabajo.

Kubernetes	Google AX
Pod	Agent Task
Service / Job	Ciclo de vida del agente
Programación de contenedores	Ejecución orientada a agentes
Aislamiento del Pod	Sandbox del agente
Reinicio de Jobs	Recuperación del estado del agente
Estado en etcd	Redis, Event Log y mecanismos de estado del agente
Recursos vinculados durante periodos prolongados	Desacoplamiento entre Worker y ciclo de vida del agente

Kubernetes destaca gestionando workloads de contenedores; AX se centra en el ciclo de vida de los agent workloads. Por eso AX todavía puede construirse sobre Kubernetes: Agent Substrate utiliza la infraestructura de Workers del clúster, pero extrae del modelo tradicional de Pods la gestión de grandes cantidades de agentes, el aislamiento, el Suspend/Resume y la reutilización de Workers.

También explica por qué AX emplea operaciones declarativas familiares para quien ya usa Kubernetes —apply, get, watch, suspend, resume—: el desarrollador mantiene un modelo de recursos conocido, mientras el ciclo de vida que hay detrás está diseñado específicamente para agentes.

AX frente a LangGraph, CrewAI y OpenAI Agent SDK

No resuelven el mismo problema. LangGraph, AutoGen, CrewAI, OpenAI Agent SDK y otros frameworks se centran en cómo piensa el agente, cómo usa herramientas, cómo mantiene el estado y cómo coordina varios agentes.

AX se centra en dónde se ejecuta el agente, cómo se aísla, cómo se conecta a servicios externos, cómo se pausa, cómo se recupera y cómo miles o millones de agentes comparten recursos limitados.

Si dividimos un sistema de agentes por capas, AX se sitúa entre el framework y el hardware: Model → Agent Framework → Agent Runtime → Sandbox / Compute. Con los Coding Agents ocurre igual: Claude Code o Codex se ocupan de cómo un agente realiza trabajo de programación; AX intenta resolver cómo ejecutar grandes cantidades de Coding Agents de forma segura, persistente y recuperable. La condición para que AX tenga sentido no es ser más inteligente que un framework concreto, sino convertirse en una capa de infraestructura para agentes.

Madurez real: v0.2.2, breaking changes y fase experimental

El objetivo de diseño es ambicioso: el README oficial presenta AX para cargas de agentes autónomos a gran escala, y Agent Substrate pone el acento en la reutilización de Actors y Workers para conseguir mayor densidad. Pero hay que distinguir dos cosas: objetivo arquitectónico ≠ escala de producción demostrada.

A octubre de 2026, el repositorio público sigue declarándose en fase de desarrollo temprano y advierte de que el protocolo central y la Runtime Specification pueden sufrir Breaking Changes importantes. La versión pública más reciente es la v0.2.2, mientras que v0.3.0 aún arrastra varias cuestiones abiertas relacionadas con la arquitectura, los Proto y el modelo de ejecución. Además, el propio directorio de despliegue de Kubernetes está marcado como experimental e incompleto.

No sería correcto concluir que AX ya tiene capacidad de producción a gran escala solo porque esté diseñado para ello. La descripción precisa es que ha planteado una dirección de infraestructura bastante completa para agent workloads, pero todavía hay pocas pruebas públicas de producción a gran escala.

¿Para quién es Google AX?

Para un desarrollador que solo necesita ejecutar un Coding Agent, un Research Agent o un bot interno, Kubernetes más un framework de agentes y un Sandbox probablemente sean suficientes. Introducir AX, Agent Substrate, Redis, Controllers y un plano de control adicional para un único agente puede no compensar la complejidad añadida.

AX empieza a resultar mucho más interesante cuando una plataforma necesita ejecutar grandes cantidades de agentes independientes de forma simultánea: plataformas empresariales de Coding Agents, clústeres de Research Agents, plataformas internas de agentes multi-tenant o sistemas de agentes autónomos que requieren aislamiento de red estricto y recuperación eficiente de recursos. En esos escenarios, el agente deja de parecerse a un proceso de aplicación y empieza a comportarse como un nuevo tipo de recurso de infraestructura.

Ventajas, limitaciones y valoración

Estas son las puntuaciones que le damos a cada dimensión, con la valoración global del proyecto:

Criterio	Puntuación
Valor arquitectónico como Agent Runtime	4,5 / 5
Ejecución de agentes a gran escala	4,2 / 5
Aislamiento y seguridad	4,5 / 5
Suspend / Resume y fiabilidad	4,3 / 5
Valor para Kubernetes y despliegues empresariales	4,0 / 5
Experiencia de desarrollo	3,4 / 5
Apertura y extensibilidad	4,5 / 5

Con esos pesos, la puntuación global es de 4,3 sobre 5,0. Una valoración basada sobre todo en el valor arquitectónico del proyecto, no en su nivel actual de madurez.

Sus fortalezas son evidentes: separa con claridad el ciclo de vida del agente del del contenedor, combina Sandbox, Gateway, políticas de egress y Workspaces independientes en un perímetro de seguridad bastante completo, y mantiene un modelo declarativo familiar. Sus limitaciones también: faltan benchmarks públicos y datos de producción, el número de componentes adicionales es considerable para un desarrollador convencional, y el despliegue sobre Kubernetes sigue en fase experimental.

Conclusión: un embrión de infraestructura para Agent Computing

El problema que Google AX intenta resolver vive entre Kubernetes y los frameworks de agentes: Kubernetes gestiona los recursos de computación, los frameworks gestionan la lógica del agente y AX empieza a gestionar el propio ciclo de vida de ejecución de los agentes.

Suspend / Resume, Sandbox, Gateway, Workspace y la reutilización de Workers no son funciones sueltas: en conjunto apuntan a un modelo de ejecución en el que un agente puede existir durante mucho tiempo sin ocupar recursos durante todo ese tiempo.

Todavía no sería correcto definir AX como un «Kubernetes para agentes IA» maduro: el proyecto está en fase temprana, su protocolo central puede sufrir Breaking Changes y los benchmarks a gran escala brillan por su ausencia. La descripción más precisa hoy es que AX es una exploración arquitectónica muy interesante de AI Agent Runtime, más adecuada para que equipos de infraestructura que necesitan ejecutar grandes cantidades de agentes la evalúen técnicamente que para que los desarrolladores convencionales la adopten directamente.

Si los agentes pasan de ser «unos pocos bots de IA» a cargas de trabajo persistentes de plataforma funcionando a gran escala, conceptos como Agent Substrate, Sandbox, Suspend/Resume y Runtime declarativo podrían acabar siendo parte importante de la infraestructura de este tipo de sistemas.

¿Es Google AX gratuito?

Sí. A octubre de 2026 AX es un proyecto open source publicado en el repositorio público google/ax de GitHub: el software no tiene coste de licencia. El gasto real aparece al desplegarlo, porque ejecutar agentes consume recursos de computación propios —Workers, Redis, snapshots y almacenamiento— según la infraestructura que montes.

¿Puedo usar AX con LangGraph o CrewAI?

La lógica de capas lo permite: los frameworks deciden cómo piensa y actúa el agente, y AX se ocupa de dónde se ejecuta, cómo se aísla y cómo se pausa o reanuda. Son piezas complementarias, no sustitutas.

¿Debería adoptarlo ya en producción?

Con cautela. Mientras la versión pública sea la v0.2.2, el protocolo central admita Breaking Changes y el despliegue en Kubernetes esté marcado como experimental, lo sensato es evaluarlo en entornos de prueba o de investigación y reservar la adopción en producción para plataformas con equipos de infraestructura capaces de seguir el ritmo del proyecto.