AX de Google a examen: 9.045 estrellas, una reescritura de hace tres días y un soporte MCP que termina en un mkdir

El 20 de septiembre de 2026, un envío a Hacker News titulado “AX – Google’s Open Agentic Orchestrator” alcanzó 661 puntos y 299 comentarios. No enlazaba a GitHub. Enlazaba a agentexecutor.io, una web de producto con una terminal animada y una frase: “Scales up to billions of tasks”. El repositorio que hay detrás, google/ax, acumula hoy 9.045 estrellas, 434 forks y 39 issues abiertas, y el 24 de septiembre fue el segundo repositorio de mayor crecimiento en GitHub Trending con 1.543 estrellas ganadas en un solo día, la velocidad diaria más alta de todo el ranking.

Conviene ser preciso sobre qué es AX, porque la confusión forma parte del asunto. AX no es un framework de agentes. Es un plano de control declarativo que convierte “ejecuta este agente en un sandbox” en un flujo con forma de kubectl: escribes YAML ax.io/v1alpha1 describiendo un Task, un Workspace, un Gateway y un Model, y AX lo deposita en un clúster de Kubernetes donde un runtime minimalista llamado Agent Substrate los ejecuta como actores que se pueden suspender y reanudar.

Lo cloné, instalé la versión exacta de Go que exige (1.27.1), lo compilé, ejecuté su propia suite de pruebas y después busqué la distancia entre el discurso comercial y el código. El build funciona. Las pruebas pasan. Y la distancia es real, concreta y en tres casos relevante para la seguridad.

Lo que AX entrega de verdad

Todos los datos siguientes provienen de un clon de main del 24 de septiembre de 2026, de la API REST de GitHub, de una lectura con navegador headless de agentexecutor.io y del propio hilo de Hacker News.

Siete mil líneas escritas a mano no son una crítica: es la escala correcta para un plano de control. También es la razón por la que la promesa de la web — “an uncompromising focus on ergonomics” — choca de frente con el apartado de inicio rápido del README, que exige un clúster de Kubernetes, ko, un registro de contenedores desde el que el clúster pueda descargar imágenes y una API de control de Agent Substrate accesible, con valor por defecto api.ate-system.svc.cluster.local:443, un servicio que no existe salvo que hayas desplegado Agent Substrate antes.

El hilo de Hacker News detectó esto de inmediato:

“Call me old-fashioned but I don’t find this ’easier’. … there’s a vast chasm between what this tool is being sold as and what it actually is.” — alembic_fumes

"‘2. Deploy the control plane — You need a Kubernetes cluster’ LOL. Bye!" — dabeeeenster

“We want to make dealing with agentic infrastructure easier / Kubernetes / Pick one.” — sarjann

Verificación: compila y sus pruebas pasan

Antes de sacar conclusiones del código conviene comprobar que el código se ejecuta. Instalé Go 1.27.1 —la versión fijada en go.mod— y ejecuté los pasos del propio CI del repositorio (.github/workflows/go.yml):

go mod download   # EXIT 0 — las dependencias de agent-substrate son públicas y resuelven
go build ./...    # EXIT 0
go test ./...     # EXIT 0 — todos los paquetes con pruebas pasan

Esto importa por dos motivos. Primero, la dependencia de github.com/agent-substrate/substrate está fijada a una pseudo-versión sin etiqueta (v0.0.0-20260911232748-672533541dbf, más github.com/agent-substrate/env v0.0.11-0.20260912052224-4468a200b170), justo el tipo de cosa que se rompe en silencio; hoy no se rompió. Segundo, el “todo verde” vale mucho menos de lo que parece, y la culpa es de un solo commit.

Hallazgo 1: la arquitectura es tres días más joven que el lanzamiento

El 19 de septiembre de 2026, un día antes del post en Hacker News, aterrizó el commit dc4f36c: “Restructure AX into a general-purpose orchestration layer for agentic tasks”.

El diffstat es 151 archivos modificados, 16.191 inserciones y 19.988 borrados. Ese commit eliminó casi todo el AX anterior:

• internal/harness/antigravity/ y internal/harness/antigravityinteractions/ — el harness de Antigravity, unas 2.900 líneas más sus pruebas
• internal/skills/geminienterprise/ y internal/skills/local/ — los clientes de registro de skills
• internal/pythonsidecar/ — un sidecar de Python de 430 líneas y su código de arranque
• internal/controller/eventlog/ — registro de eventos sobre SQL, SQLite y Postgres
• internal/config/ — 375 líneas más 421 líneas de pruebas
• cmd/ax/exec.go (526 líneas), cmd/ax/doctor.go (251), cmd/ax/internal/display.go (474), cmd/ax/harness.go (227)

Y, lo más consecuente, borró 22 archivos de prueba que contenían 4.667 líneas de tests. El repositorio conserva hoy 10 archivos de prueba. cmd/ax/main.go —la CLI de 1.230 líneas, el archivo escrito a mano más grande del proyecto— no tiene ninguno.

Cobertura medida con go test -cover ./...:

Los tres paquetes con 0% son, por orden: la línea de comandos que usa la gente, la capa de persistencia y la integración con el runtime de sandbox del que depende todo lo demás. Es un proyecto reconstruido en once semanas de trabajo y publicado con una forma de tres días. El README es honesto sobre la consecuencia —“We will likely to introduce major breaking changes prior to a stable release”— pero la tabla de cobertura te dice dónde va a caer esa ruptura.

Hallazgo 2: los servidores MCP se documentan, se muestran y nunca se usan

Si tuviera que evaluar AX, este sería el hallazgo sobre el que actuaría primero.

El README anuncia que Workspace es la primitiva que “Pre-wire Git repos, MCP servers, and skill packages so every agent starts warm”. La documentación va más lejos:

• docs/concepts.md: un Workspace materializa "MCP servers and registries (Model Context Protocol) that the agent can call" y “Skill registries and the path where skills are materialized”.
• docs/runner.md: el runner debe “clone the Git repos from spec.git, create the skills path, write any MCP configuration, and run any environment bootstrap…”
• docs/sandbox.md: el endpoint /readyz del sandbox devuelve 200 “once clones, MCP config, and skills are in place”.
• examples/task.yaml incluye un default-workspace con un registro MCP google, un registro de skills google y un servidor MCP estático git-tools en http://git-mcp.default.svc.cluster.local:8080.

Ahora el código. internal/workspace/setup.go contiene exactamente un camino de preparación:

res.ClonedRepos, gitOK = cloneRepos(ctx, ws.Spec.Git, targetPath)
res.SkillsMounted = setupSkills(ws.Spec.Skills)

cloneRepos ejecuta git fetch. setupSkills son tres líneas de os.MkdirAll. No existe ningún código de MCP: una búsqueda en todo el repositorio de consumidores de Spec.Mcp fuera de las pruebas devuelve únicamente cmd/ax/main.go, donde la CLI imprime los registros y servidores declarados en ax describe workspace y los cuenta en la columna MCP-SERVERS de ax get workspaces. Los tipos existen (MCPConfig.GetRegistries, SkillsConfig.GetRegistries en el protobuf generado), el YAML se parsea, la CLI lo muestra… y el sandbox arranca con un clon y un directorio vacío.

Dos detalles adyacentes refuerzan la imagen. internal/workspace/planner.go define un Planner de 112 líneas con un método PlanEnvironment documentado para “analyze the declared goal, workspace repositories, MCP servers, and skills using Gemini 3.8 Flash to synthesize execution setup instructions”: no tiene ni un solo llamador en todo el repositorio. Y en docs/roadmap.md, publicado el día anterior a esta auditoría, la “dynamic agentic environment curation” —“discover relevant MCP servers and skills from registries”— sigue figurando como trabajo futuro.

El arranque guiado por objetivo que sí está implementado es real: setup.go llama a runBootstrap, que invoca antigravity_bootstrap.py, una llamada de agente auténtica que prepara el entorno a partir de un objetivo en lenguaje natural. Así que “describe tu entorno y un agente lo construye” funciona. “Conecta mis servidores MCP” no, digan lo que digan cuatro documentos y la propia columna de salida de la CLI.

Hallazgo 3: la lista blanca de egreso se aplica una vez y no se reconcilia nunca

La primitiva Gateway es el argumento de seguridad en el que AX más se apoya. La web: “Define and quickly manage network policies. Lock traffic down to an explicit allowlist of hosts and ports.” El README: “Lock outbound traffic down to an explicit host allowlist.”

Lo que hace el código:

1. Cuando llega un evento de tarea, ax-controller busca el Gateway indicado y se lo pasa a TaskReconciler.Reconcile, que lee gateway.Spec.Egress.Allowlist y llama a ApplyEgressPolicy una sola vez, en el momento de crear el actor.
2. UpdateGateway en internal/server/server.go llama a store.SaveGateway y no publica ningún evento. No puede: el tipo de evento es TaskEvent{ID, Atespace, Name, Action}, donde Action vale "reconcile" o "delete"; no hay campo para el tipo de recurso, así que un cambio de Gateway no tiene representación en el bus.

La consecuencia es concreta. Si una tarea está en Running y ajustas la lista blanca de su Gateway —porque un agente ha empezado a hablar con un host que no debería, o porque has encontrado un camino de inyección de prompt— a esa tarea no le pasa absolutamente nada. La política del actor vivo es la que tenía al crearse. Para aplicar la regla nueva hay que borrar y recrear la tarea, perdiendo su estado guardado.

El propio roadmap de AX, añadido en el commit ace0360 del 23 de septiembre, lo dice con palabras de Google: “Implement full continuous reconciliation for Gateway resources in ax-controller so updates to listeners and egress allowlists dynamically propagate to all referencing tasks and underlying Substrate network policies.” Es la descripción exacta de una funcionalidad ausente, y para quien piense ejecutar agentes no confiables detrás de esto, es la frase más importante de todo el repositorio.

Hallazgo 4: la postura por defecto es egreso total

La otra mitad de la historia de red es qué ocurre cuando no configuras ningún Gateway. En internal/controller/reconciler.go:

// Default to allow all egress if no explicit gateway restriction is set
egressAllowlist = &v1alpha1.EgressAllowlist{
    Hosts: []*v1alpha1.HostRule{{Host: "*", Port: 443}},
}

El examples/task.yaml que se distribuye enlaza default-gateway, y la lista blanca de ese Gateway es host: "*", port: 443. La salida de ejemplo del README para ax get gateways imprime EGRESS-HOSTS: *. Es decir: la experiencia de AX recién instalado —la que sigue un usuario nuevo desde el inicio rápido— es un sandbox de agente con egreso HTTPS sin restricciones hacia todo internet, en el puerto 443. La valla de red es una capacidad real, pero es opcional y el ejemplo distribuido no la activa. Si adoptas AX precisamente por el control de egreso, trata los valores por defecto como hostiles hasta que hayas escrito tu propio Gateway y verificado la política aplicada desde el lado del actor.

Hallazgo 5: “miles de millones de tareas” sobre un único pod de Redis

La afirmación aparece cuatro veces en los materiales de AX. El repositorio: “built to run billions of tasks per cluster”. La web: “Scales up to billions of tasks” y “scale to billions of concurrent agent sessions per cluster without orchestrator limits”.

Este es el plano de control que realmente obtienes con make deploy:

# deploy/redis.yaml
kind: Deployment
metadata: {name: ax-redis, namespace: ax-system}
spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: redis
          image: redis:7-alpine
          resources:
            requests: {cpu: 100m, memory: 128Mi}
            limits:   {cpu: 1000m, memory: 1Gi}

replicas: 1. Sin volumes ni volumeMounts: la persistencia de Redis no se configura nunca, así que ni un AOF ni un RDB sobreviven a un reinicio del pod. Un techo de 1 GiB de memoria. Sin Sentinel, sin Cluster, sin guía para usar un Redis externo. deploy/ax-controller.yaml también es replicas: 1, aunque DESIGN.md afirme que los controladores escalan horizontalmente.

Y ese único Redis no es una caché. DESIGN.md explica el razonamiento: almacenar millones de tareas como CRDs de Kubernetes empujaría a etcd fuera de su zona de confort, de modo que “AX keeps its state in Redis and uses Redis Streams as the work queue”. Tareas, Gateways, Workspaces, Models y el flujo de eventos viven en ese pod sin almacenamiento duradero. Un reinicio de contenedor, un drenaje de nodo o un OOM kill se lleva por delante todo el estado duradero del plano de control.

Hay una historia de escala más sutil. AX dice miles de millones de tareas. Su propia capa de ejecución, Agent Substrate, dice “millions of sandboxes with 10x higher density than standard container runtimes” y demuestra un sobremultiplexado de más de 30x repartiendo unos 250 actores con estado entre 8 pods físicos. Ambas cifras pueden ser defendibles para su propia capa, pero están a tres órdenes de magnitud de distancia en los dos README que describen un mismo stack, y el hilo de Hacker News lo notó:

“billions? who is running BILLIONS of agents? tens, hundreds, maybe a couple thousand at a time? absolutely.” — _zoltan_

"‘billions of tasks’ is a ‘solution’ to problem nobody has (maybe some RL labs?…)." — mirekrusin

El contragolpe más útil vino del mismo hilo: “companies doing evals or RL or training will create really big bursty agent workloads. I think they are the best fit for AX, as opposed to individual dev teams building software” (dbmikus). Si ese es el mercado objetivo, la cifra es una decisión de posicionamiento. Si eres un equipo de plataforma de seis personas, el número que debes mirar es replicas: 1.

Hallazgo 6: el harness es Antigravity, sin versión fija, y el nombre del secreto está escrito a mano

El único harness de agente que AX distribuye es el de Google. Dockerfile.task-runner:

FROM python:3.12-slim
RUN pip install --no-cache-dir google-antigravity

Sin fijar versión. google-antigravity está en PyPI (hoy 0.1.18, con 19 publicaciones), así que cada reconstrucción de esa imagen puede recoger un SDK distinto. internal/controller/reconciler.go fija a mano geminiSecretName = "gemini-api-secret" y la clave GEMINI_API_KEY al inyectar credenciales en las plantillas de actor, aunque el recurso Model permite nombrar cualquier secreto en spec.secretKey y internal/model/client.go sí lo respeta. Si configuras tu Model con un secreto de otro nombre, el arranque dentro del contenedor se queda sin clave, en silencio.

El roadmap confirma que ambos límites se conocen: “Allow Customization: Decouple the built-in workspace bootstrap and coding agent harness so users can configure custom agent runtimes.” La co-creadora de AX, Jaana Dogan (rakyll), lo enmarcó con claridad en el hilo: “AX is a layer that is closer to job orchestration… It’s NOT an agentic framework. We use Antigravity for a few generative features but are abstracting away some of these components so anyone can bring their own.”

Hallazgo 7: la capa de abajo dice que no es un producto soportado por Google

AX vive en la organización google de GitHub y se describe como “Google’s open agentic orchestration runtime”. El runtime sobre el que se apoya no hace esa afirmación. Del README de Agent Substrate:

“NOTE: This is not an officially supported Google product. This project is not eligible for the Google Open Source Software Vulnerability Rewards Program.”

Substrate tiene 3.491 estrellas, 523 issues abiertas y, según su mantenedor en el mismo hilo, está “in the process of being donated to the CNCF as a vendor-neutral common ground”. Mientras tanto, en el manifiesto de despliegue de AX, el controlador se autentica contra Substrate con un token de cuenta de servicio proyectado cuya audiencia es api.ate-system.svc, y confía en un ClusterTrustBundle seleccionado por signerName: servicedns.podcert.ate.dev/identity. Eso no es una dependencia que puedas sustituir por un servicio gestionado en la nube: es una configuración de confianza a nivel de clúster que tienes que asumir tú.

Nada de esto convierte el stack en algo malo. Significa que “el orquestador de Google” describe quién escribió el código, no quién responderá cuando se rompa. Y la ansiedad por el historial de productos cancelados de Google dominó buena parte de los 299 comentarios:

“anyone should think of this as an experimental side project that may be forgotten in 15min and make careful decisions about using them in production environments.” — fg137

“They will sunset this in 6 months. Dont bother.” — mkrishnan

La réplica más sólida del hilo es que el diseño por capas es deliberado: Substrate se mantiene pequeño y neutral respecto al proveedor, absorbe los CVE y se dona a la CNCF; AX es la capa superior con opiniones y forma de producto de Google. Es una arquitectura defendible. También es, hoy, exactamente lo que describen los dos README.

Para qué sirve AX hoy

Leer un repositorio de forma adversarial no significa que no valga nada. Varias partes resisten bien la inspección:

• La abstracción del ciclo de vida es coherente. Task/Workspace/Gateway/Model encajan con preocupaciones operativas reales, y ax suspend / ax resume / ax ssh son los verbos correctos. El borrado en dos fases (MarkTaskDeleting → limpieza del controlador → eliminación del registro) está bien implementado, y la ruta de fallo deja a propósito el registro en Terminating para permitir reintentos.
• El contrato del runner es limpio y testeable. runner/ está al 95% de cobertura y docs/runner.md documenta bien la idempotencia por archivo marcador: la preparación se ejecuta una vez por workspace y un clon fallido retiene el marcador a propósito para reintentar en el siguiente arranque.
• El bucle central del controlador está probado. internal/controller, con 71,4%, cubre suspensión, preparación de workspace y borrado contra un servidor Substrate simulado: justo donde un error sería más caro.
• El roadmap publicado es genuinamente útil. Se lee como una lista interna de huecos y no como material de marketing: migración de actores, reconciliación de Gateway, detección de inactividad, identidades SPIFFE, telemetría de trayectorias, desacoplamiento del harness. Muy pocos proveedores publican eso.

Quién debería adoptarlo y qué verificar primero

Probablemente sí: equipos que montan arneses de evaluación, rollouts de RL o cargas de escaneo de código muy a ráfagas, que ya operan Kubernetes, que ya toleran YAML y cuyo problema real es “miles de agentes, entornos prescriptivos, egreso estricto”. Para ellos la lista de huecos importa menos que el modelo de actores.

Probablemente todavía no: cualquiera cuyo caso de uso sea “unos pocos agentes en mi portátil o en una única máquina virtual”. La cadena de requisitos (clúster + ko + registro + plano de control de Substrate + un controlador que lee secretos de todo el clúster) es un mal negocio para eso, y el hilo de Hacker News está lleno de gente que construyó la versión pequeña en una tarde.

Si decides adoptarlo, verifica estas cinco cosas el primer día:

1. Lee la política de egreso aplicada desde el lado del actor, no desde ax get gateways. Después cambia el Gateway y confirma a qué sigue llegando tu tarea en ejecución. No des por hecha la reconciliación.
2. Comprueba si necesitas que spec.mcp funcione. Hoy no funcionará. Si tu diseño asume servidores MCP accesibles dentro del sandbox, tendrás que incluirlos en una imagen de runner propia o arrancarlos a mano con ax ssh.
3. No ejecutes el Redis distribuido en producción. Apunta --redis-addr a un Redis externo con persistencia y réplica, o acepta que un reinicio del pod borre cada Task, Gateway, Workspace y Model.
4. Fija la imagen del task-runner por digest —examples/task.yaml ya lo hace— y fija tú mismo google-antigravity. El Dockerfile no lo hace.
5. Revisa el RBAC del controlador. deploy/ax-controller.yaml instala un ClusterRole que concede get, list y watch sobre secretos en todo el clúster. Es el precio de resolver gemini-api-secret desde el espacio de nombres de la tarea; también es un permiso muy amplio para un componente cuyo propio README avisa de que la especificación es inestable.

Preguntas frecuentes

¿AX compite con LangGraph, CrewAI o el Agents SDK de OpenAI? No, y la confusión es culpa de AX por llamarse “orquestador”. Esos frameworks componen llamadas a modelos dentro de tu proceso; AX planifica sandboxes fuera de él. La formulación de rakyll —“closer to job orchestration… NOT an agentic framework”— es la correcta. La comparación honesta es kubectl más GKE Sandbox más instantáneas de pods, o agent-sandbox del SIG de Kubernetes, que es más nativo de Kubernetes pero no suspende ni reanuda actores.

¿De verdad reanuda en menos de un segundo? Esa es la afirmación de Agent Substrate (sub-500ms resume, más de 500 activaciones de suspensión/reanudación por segundo), demostrada con 250 actores en 8 pods. AX no aporta maquinaria de reanudación: llama a SuspendActor y ResumeActor. Cada cifra debe atribuirse a su capa.

¿Puedo ejecutarlo sin Kubernetes? Por la vía soportada, no. make deploy ejecuta kubectl apply y ko apply contra un clúster, y el controlador usa por defecto api.ate-system.svc.cluster.local:443. Existe un almacén en memoria (internal/store/memory) y un respaldo por kubectl para resolver secretos que apunta a desarrollo local, pero no hay modo local documentado ni pruebas para el almacén en memoria.

¿Por qué el commit de anteayer borró 20.000 líneas? Porque AX cambió de naturaleza. Hasta el 19 de septiembre de 2026 era un ejecutor de agentes construido alrededor de un harness concreto (Antigravity), un registro de skills, un sidecar de Python y un log de eventos. La reestructuración lo sustituyó por un plano de control general —agnóstico en la intención, con forma de Antigravity en la práctica— y los archivos eliminados se llevaron consigo 4.667 líneas de pruebas.

¿Es seguro ejecutar código no confiable dentro? El aislamiento se delega en Substrate (sandboxes gVisor o microVM, con la garantía procedente de la capa cuyo README renuncia al soporte de Google). Dentro de esa frontera, los dos controles del lado de AX a los que recurrirías primero —lista blanca de MCP y reconciliación de egreso— están respectivamente sin implementar y sin continuidad. Trata AX como comodidad envuelta en aislamiento, no como un motor de políticas.

¿A qué velocidad cambia? Lo bastante como para que esta auditoría caduque en semanas. El roadmap se añadió el 23 de septiembre de 2026; la última reestructuración conocida del código fuente fue cuatro días antes de este artículo; y un mantenedor dijo en el hilo de lanzamiento que la identidad de tarea basada en clave pública era “work in flight, but it will land within a few weeks”. Vuelve a leer docs/roadmap.md antes de construir algo duradero encima.

Conclusión

AX de Google es un sistema real con una idea real: los agentes son una nueva clase de carga de trabajo y merecen un orquestador que asuma estado, ráfagas y suspensión en lugar de fingir que son microservicios o trabajos por lotes. La descomposición en Task/Workspace/Gateway/Model y una CLI con forma de kubectl son buenos cimientos.

Lo que todavía no es es lo que dice su portada. El discurso de la ergonomía choca con un inicio rápido de cinco requisitos previos. La historia de MCP es un campo de YAML y una columna de tabla. La valla de red se aplica una vez y nunca se reconcilia. Los miles de millones de tareas viven en un único pod de Redis sin persistencia. Y el componente más grande del código tiene 0% de cobertura porque un commit de reestructuración tres días antes del lanzamiento borró las pruebas junto con el código que probaban.

Ninguno de estos puntos es fatal. Todos son verificables en una tarde, que es precisamente por lo que los verifiqué, y por lo que el propio roadmap del repositorio, leído con atención, es su archivo más útil. Adopta AX por el modelo de actores y los verbos del ciclo de vida. No lo adoptes por el texto de marketing. 📦

Repositorio: github.com/google/ax · Web: agentexecutor.io · Hilo de lanzamiento: HN 49780797 (661 puntos, 299 comentarios)