Google's AX, Audited: 9,045 Stars, a 3-Day-Old Rewrite, and MCP Support That Ends at mkdir

On September 20, 2026, a Hacker News submission titled “AX – Google’s Open Agentic Orchestrator” reached 661 points and 299 comments. It did not link to GitHub. It linked to agentexecutor.io, a marketing site with an animated terminal and the sentence “Scales up to billions of tasks.” The repository behind it, google/ax, now sits at 9,045 stars, 434 forks and 39 open issues, and on September 24 it was the second-fastest-growing repository on GitHub Trending with 1,543 stars gained in a single day — the highest daily velocity of anything on the board that day.

It is worth being precise about what AX is, because the confusion is the point. AX is not an agent framework. It is a declarative control plane that turns “run this agent in a sandbox” into a kubectl-shaped workflow: you write ax.io/v1alpha1 YAML describing a Task, a Workspace, a Gateway and a Model, and AX drops them into a Kubernetes cluster where a stripped-down runtime called Agent Substrate executes them as checkpointable actors.

I cloned it, installed the exact Go toolchain it demands (1.27.1), built it, ran its own test suite, and then went looking for the gap between the pitch and the code. The build works. The tests pass. And the gap is real, specific, and in three cases security-relevant.

What AX actually ships

Every figure below comes from a fresh clone of main on 2026-09-24, the GitHub REST API, a headless-browser read of agentexecutor.io, and the Hacker News thread itself.

Seven thousand hand-written lines is not a criticism. It is the correct scale for a control plane. It is also why the marketing site’s claim of “an uncompromising focus on ergonomics” gets tested pretty hard by the quick-start section of the README, which requires a Kubernetes cluster, ko, a container registry your cluster can pull from, and a reachable Agent Substrate control API — the default being api.ate-system.svc.cluster.local:443, a service that does not exist unless you deployed Agent Substrate yourself first.

The Hacker News thread landed on this immediately:

“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

Verification: it builds, and its tests pass

Before drawing conclusions from source code it helps to establish that the code actually runs. I installed Go 1.27.1 — the version go.mod pins — and ran the repository’s own CI steps (.github/workflows/go.yml):

go mod download   # EXIT 0 — the agent-substrate dependencies are public and resolve
go build ./...    # EXIT 0
go test ./...     # EXIT 0 — every package with tests passes

This matters for two reasons. First, the dependency on github.com/agent-substrate/substrate is pinned to an untagged pseudo-version (v0.0.0-20260911232748-672533541dbf, plus github.com/agent-substrate/env v0.0.11-0.20260912052224-4468a200b170), which is exactly the kind of thing that silently breaks — it did not break today. Second, the “all green” result is worth a lot less than it sounds, and the reason is a single commit.

Finding 1: the architecture is three days older than the launch

On 2026-09-19, one day before the Hacker News post, commit dc4f36c landed: “Restructure AX into a general-purpose orchestration layer for agentic tasks.”

The diffstat is 151 files changed, 16,191 insertions, 19,988 deletions. That commit deleted the previous AX almost entirely:

• internal/harness/antigravity/ and internal/harness/antigravityinteractions/ — the Antigravity harness, ~2,900 lines plus tests
• internal/skills/geminienterprise/ and internal/skills/local/ — the skill registry clients
• internal/pythonsidecar/ — a 430-line Python sidecar and its setup code
• internal/controller/eventlog/ — SQL, SQLite and Postgres event logging
• internal/config/ — 375 lines plus 421 lines of tests
• cmd/ax/exec.go (526 lines), cmd/ax/doctor.go (251), cmd/ax/internal/display.go (474), cmd/ax/harness.go (227)

More consequentially, it deleted 22 test files containing 4,667 lines of tests. The repository now carries 10 test files. cmd/ax/main.go — the 1,230-line CLI, the largest hand-written file in the project — has none.

Coverage, measured with go test -cover ./...:

The three packages with 0% are, in order: the user-facing CLI, the persistence layer, and the integration with the sandbox runtime everything depends on. This is a project that was rebuilt eleven weeks of engineering time into a three-day-old shape and shipped. The README is honest about the consequence — “We will likely to introduce major breaking changes prior to a stable release” — but the coverage table tells you where the breakage will land.

Finding 2: MCP servers are documented, displayed, and never used

This is the finding I would act on first if I were evaluating AX.

AX’s README advertises Workspace as the primitive that will “Pre-wire Git repos, MCP servers, and skill packages so every agent starts warm.” The docs go further:

• docs/concepts.md: a Workspace materializes "MCP servers and registries (Model Context Protocol) that the agent can call" and “Skill registries and the path where skills are materialized.”
• docs/runner.md: the runner must “clone the Git repos from spec.git, create the skills path, write any MCP configuration, and run any environment bootstrap…”
• docs/sandbox.md: the sandbox’s /readyz endpoint returns 200 “once clones, MCP config, and skills are in place.”
• examples/task.yaml ships a default-workspace with a google MCP registry, a google skills registry, and a static git-tools MCP server at http://git-mcp.default.svc.cluster.local:8080.

Now the code. internal/workspace/setup.go contains exactly one setup path:

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

cloneRepos runs git fetch. setupSkills is three lines of os.MkdirAll. There is no MCP code at all — a repository-wide search for every consumer of Spec.Mcp outside tests returns only cmd/ax/main.go, where the CLI prints the declared registries and servers in ax describe workspace and counts them in the MCP-SERVERS column of ax get workspaces. The types exist (MCPConfig.GetRegistries, SkillsConfig.GetRegistries in the generated protobuf), the YAML parses, the CLI displays it… and the sandbox boots with a clone and an empty directory.

Two adjacent details reinforce the picture. internal/workspace/planner.go defines a 112-line Planner with a PlanEnvironment method that is documented to “analyze the declared goal, workspace repositories, MCP servers, and skills using Gemini 3.8 Flash to synthesize execution setup instructions” — it has zero callers anywhere in the repository. And in docs/roadmap.md, published the day before this audit, “dynamic agentic environment curation” — “discover relevant MCP servers and skills from registries” — is still listed as future work.

The goal-driven bootstrap that is implemented is real: setup.go calls runBootstrap, which invokes antigravity_bootstrap.py, a genuine agent call that sets up the environment from a natural-language goal. So “describe your environment and an agent builds it” works. “Wire up my MCP servers” does not, despite what four documents and the CLI’s own output column say.

Finding 3: your egress allowlist is applied once and never reconciled

The Gateway primitive is the security story AX leans on hardest. The site: “Define and quickly manage network policies. Lock traffic down to an explicit allowlist of hosts and ports.” The README: “Lock outbound traffic down to an explicit host allowlist.”

What the code does:

1. When a task event arrives, ax-controller looks up the named Gateway, passes it to TaskReconciler.Reconcile, which reads gateway.Spec.Egress.Allowlist and calls ApplyEgressPolicy once, at actor-creation time.
2. UpdateGateway in internal/server/server.go calls store.SaveGateway and publishes no event at all. It cannot: the event type is TaskEvent{ID, Atespace, Name, Action} where Action is "reconcile" or "delete" — there is no resource-kind field, so a Gateway change has no representation on the wire.

The consequence is concrete. If a task is Running and you tighten its Gateway’s allowlist — because an agent started talking to a host it should not, or because you found a prompt-injection path — nothing happens to that task. The policy on the live actor is whatever it was at creation. To enforce the new rule you must delete and recreate the task, losing its checkpointed state.

AX’s own roadmap, added in commit ace0360 on 2026-09-23, says this in Google’s words: “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.” That is an accurate description of a missing feature, and it is the single most important sentence in the repository for anyone planning to run untrusted agents behind this thing.

Finding 4: the default posture is allow-all egress

The second half of the networking story is what happens when you do not configure a Gateway. From 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}},
}

The shipped examples/task.yaml binds default-gateway, and that Gateway’s own allowlist is host: "*", port: 443. The README’s own sample output for ax get gateways prints EGRESS-HOSTS: *. So the out-of-the-box AX experience — the one a new user runs from the quick start — has an agent sandbox with unrestricted HTTPS egress to the entire internet, on port 443. The network fence is real capability, but it is opt-in and the shipped example does not opt in. If you are adopting AX specifically for egress control, treat the defaults as hostile until you have written your own Gateway and verified the applied policy from the actor’s side.

Finding 5: “billions of tasks” runs on one Redis pod

The claim appears four times in AX’s own materials. The repository: “built to run billions of tasks per cluster.” The site: “Scales up to billions of tasks” and “scale to billions of concurrent agent sessions per cluster without orchestrator limits.”

Here is the control plane you actually get from 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. No volumes, no volumeMounts — Redis persistence is never configured, so an AOF/RDB file cannot survive a pod restart. A 1 GiB memory ceiling. No Sentinel, no Cluster, no external Redis guidance. deploy/ax-controller.yaml is also replicas: 1, even though DESIGN.md says controllers scale horizontally.

And this single Redis instance is not a cache. DESIGN.md explains the design rationale explicitly: storing millions of tasks as Kubernetes CRDs would push etcd past its comfort zone, so “AX keeps its state in Redis and uses Redis Streams as the work queue.” Tasks, Gateways, Workspaces, Models and the event stream all live in that one pod with no durable storage. A container restart, a node drain or an OOM kill takes the entire control plane’s durable state with it.

There is a subtler scale story too. AX says billions of tasks. Its own runtime layer, Agent Substrate, says “millions of sandboxes with 10x higher density than standard container runtimes” and demonstrates 30x+ oversubscription by multiplexing ~250 stateful actors across 8 physical pods. Both numbers may be defensible for their own layer, but they are three orders of magnitude apart in the two READMEs that describe one stack — and the Hacker News thread noticed:

“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

The most useful counter-argument came from the same thread: “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). If that is the target market, the claim is a positioning choice. If you are a platform team of six, the number you should look at is replicas: 1.

Finding 6: the harness is Antigravity, unpinned, and the secret name is hardcoded

The only agent harness AX ships is Google’s own. Dockerfile.task-runner:

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

No version pin. google-antigravity is on PyPI (0.1.18 today, 19 releases to date), so every rebuild of that image can pick up a different SDK. internal/controller/reconciler.go hardcodes geminiSecretName = "gemini-api-secret" and key GEMINI_API_KEY when it injects credentials into actor templates — even though the Model resource’s spec.secretKey lets you name any secret, and internal/model/client.go does honour it. Configure your Model with a differently-named secret and the container-level bootstrap silently has no key.

The roadmap confirms both limits are known: “Allow Customization: Decouple the built-in workspace bootstrap and coding agent harness so users can configure custom agent runtimes.” AX’s co-creator Jaana Dogan (rakyll) framed it plainly in the thread: “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.”

Finding 7: the layer below says it is not a supported Google product

AX lives in the google GitHub organisation and is described as “Google’s open agentic orchestration runtime.” The runtime it sits on does not make that claim. From the Agent Substrate README:

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

Substrate is 3,491 stars, 523 open issues, and — per its maintainer in the same Hacker News thread — “in the process of being donated to the CNCF as a vendor-neutral common ground.” Meanwhile, in the AX deployment manifest, the controller authenticates to Substrate with a projected service-account token whose audience is api.ate-system.svc, and trusts a ClusterTrustBundle selected by signerName: servicedns.podcert.ate.dev/identity. That is not a dependency you can swap for a managed cloud service; it is a cluster-level trust configuration you have to own.

None of this makes the stack bad. It does mean “Google’s orchestrator” describes who wrote the code, not who will answer when it breaks — and killedbygoogle anxiety dominated a large fraction of the 299 comments:

“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

The strongest rebuttal in the thread is that the layered design is deliberate: Substrate stays small and vendor-neutral, gets the CVEs, and gets donated; AX is the opinionated Google-shaped layer above it. That is a defensible architecture. It is also, today, exactly what the two READMEs describe.

What AX is good at right now

Reading a repository adversarially does not mean it is worthless. Several parts hold up well under inspection:

• The lifecycle abstraction is coherent. Task/Workspace/Gateway/Model map cleanly onto real operational concerns, and ax suspend / ax resume / ax ssh are the right verbs. The two-phase delete (MarkTaskDeleting → controller cleanup → record removal) is implemented properly, with the failure path deliberately leaving the record in Terminating so a retry is possible.
• The runner contract is clean and testable. runner/ sits at 95% coverage and docs/runner.md documents the marker-file idempotency rule well: setup runs once per workspace, and a failed clone intentionally withholds the marker so the next boot retries.
• The controller’s core loop is tested. internal/controller at 71.4% coverage includes suspend, workspace-readiness and delete paths against a mock Substrate server — this is the part where a mistake would be most expensive.
• The published roadmap is genuinely useful. It reads like an internal gap list rather than a marketing artefact: actor migration, gateway reconciliation, idleness detection, SPIFFE identities, trajectory telemetry, harness decoupling. Very few vendors publish that.

Who should adopt it, and what to check first

Probably yes: teams doing evaluation harnesses, RL rollouts or large bursty code-scanning workloads who already run Kubernetes, already tolerate YAML, and whose problem is genuinely “thousands of agents, prescriptive environments, strict egress.” For them, the gap list matters less than the actor model.

Probably not yet: anyone whose workload is “a few agents on my laptop or a single VM.” The prerequisite chain (cluster + ko + registry + Substrate control plane + a cluster-wide secret-reading controller) is a poor trade for that, and the Hacker News thread is full of people who built the smaller version in an afternoon.

If you do adopt it, verify these five things on day one:

1. Read the applied egress policy from the actor side, not from ax get gateways. Then change the Gateway and confirm what your running task can still reach. Do not assume reconciliation.
2. Check whether you need spec.mcp to work at all. Today it will not. If your design assumes MCP servers are reachable in-sandbox, you need to bake them into a custom runner image or start them manually via ax ssh.
3. Do not run the shipped Redis in production. Point --redis-addr at an external Redis with persistence and a replica, or accept that a pod restart wipes every Task, Gateway, Workspace and Model.
4. Pin the task-runner image by digest — examples/task.yaml already does this — and pin google-antigravity yourself. The Dockerfile does not.
5. Review the controller’s RBAC. deploy/ax-controller.yaml installs a ClusterRole granting get, list and watch on secrets cluster-wide. That is the price of resolving gemini-api-secret from a task’s namespace; it is also a very broad grant for a component whose own README warns the specification is unstable.

FAQ

Is AX a competitor to LangGraph, CrewAI or the OpenAI Agents SDK? No, and the confusion is AX’s fault for calling itself an “orchestrator”. Those frameworks compose LLM calls inside your process. AX schedules sandboxes outside it. rakyll’s own phrasing — “closer to job orchestration… NOT an agentic framework” — is the correct one. The honest comparison is kubectl plus GKE Sandbox plus pod snapshotting, or Kubernetes SIG’s agent-sandbox, which is more Kubernetes-native but does not suspend and resume actors.

Does it really resume in under a second? That is Agent Substrate’s claim (sub-500ms resume, >500 suspend/resume activations per second), demonstrated at 250 actors across 8 pods. AX itself contributes no resumption machinery; it calls SuspendActor and ResumeActor. Each layer’s number should be attributed to that layer.

Can I run it without Kubernetes? Not through the supported path. make deploy runs kubectl apply and ko apply against a cluster, and the controller defaults to api.ate-system.svc.cluster.local:443. There is an in-memory store (internal/store/memory) and a kubectl fallback for secret resolution that hints at local development, but no documented local mode and no tests for the memory store.

Why did yesterday’s commit delete 20,000 lines? Because AX changed kind. Until 2026-09-19 it was an agentic executor built around a specific harness (Antigravity), a skills registry, a Python sidecar and an event log. The restructure replaced that with a general control plane — harness-agnostic in intent, Antigravity-shaped in practice — and the deleted files took 4,667 lines of tests with them.

Is it safe to run untrusted code in? The isolation is delegated to Substrate (gVisor or microVM sandboxes, with the isolation guarantee coming from the layer whose README disclaims Google support). Inside that boundary, the two AX-side controls you would reach for first — MCP allowlisting and egress reconciliation — are respectively unimplemented and non-continuous. Treat AX as isolation-wrapped convenience, not as a policy engine.

How fast is it moving? Fast enough that this audit has a shelf life measured in weeks. The roadmap was added on 2026-09-23; the last known source restructure was four days before this article; and a maintainer said in the launch thread that public-key-based task identity was “work in flight, but it will land within a few weeks.” Re-read docs/roadmap.md before you build anything durable on top.

The bottom line

Google’s AX is a real system with a real design idea: agents are a new workload class, and they deserve an orchestrator that assumes state, bursting and suspension rather than pretending they are microservices or batch jobs. The Task/Workspace/Gateway/Model decomposition and the kubectl-shaped CLI are good bones.

What it is not, yet, is what its front page says it is. The ergonomics pitch collides with a five-prerequisite quick start. The MCP story is a YAML field and a table column. The network fence is applied once and never reconciled. The billions of tasks live in one un-persisted Redis pod. And the codebase’s largest component has 0% coverage because a restructuring commit three days before launch deleted the tests along with the code they tested.

None of these are fatal. All of them are checkable in an afternoon, which is why I checked them — and why the repository’s own roadmap, read carefully, is the most useful file in it. Adopt AX for the actor model and the lifecycle verbs. Do not adopt it for the marketing copy. 📦

Repository: github.com/google/ax · Site: agentexecutor.io · Launch thread: HN 49780797 (661 points, 299 comments)