AX just forced a question every platform team running agents on Kubernetes has been dancing around: what happens when you point etcd at millions of short-lived AI tasks? Google's v0.3.0 release, shipped September 20, 2026, answers it by moving task state out of Kubernetes custom resources and into Redis Streams. Two days later, the AX repository topped Hacker News with more than 600 points.

AX, short for Agent Executor, is an open-source orchestrator Google first announced May 26, 2026, with a blunt warning that breaking changes were likely before a stable release, a warning still in the README today; v0.3.0 proves it wasn't boilerplate. The repo, github.com/google/ax, is Apache-2.0, written in Go, created March 30, 2026, now at roughly 5,635 stars and 236 forks, 625 commits on main, 16 open issues. Install: go install github.com/google/ax/cmd/ax@latest, docs at agentexecutor.io.

RelatedMeta's New Muse AI Agent Grabbed a Rock Band's Social Handle

AX repository stats as of September 22, 2026 Bar chart of google/ax GitHub metrics: 5,635 stars, 236 forks, and 16 open issues, shown on a log scale so all three bars are visible together. AX REPO PULSE · AS OF 2026-09-22 log scale 5,635 Stars 236 Forks 16 Open issues genztech.blog
Fig 1 AX's GitHub numbers four months after its May announcement, forks and issues drawn on a log scale so they stay visible next to the star count.

You declare a task with workspace and gateway specs, and AX sandboxes it, wires the workspace, fences the network, and runs it at scale on top of Agent Substrate (github.com/agent-substrate/substrate), a separate project doing the actual sandboxed execution. Google's justification is the thesis the project hangs on: "Agents are a new kind of workload. They are neither stateless microservices nor run-to-completion batch jobs. They accumulate state, need strict isolation, call out to model APIs and tool servers, and can burn money in a loop if nobody is watching."

How fast has AX been moving toward this release?

  1. 2026-03-30Repo created google/ax goes up, Apache-2.0.
  2. 2026-05-26Public announcement README warns of breaking changes ahead.
  3. 2026-07-23v0.2.2 Old Python-harness architecture.
  4. 2026-08-13v0.2.3 Last release before the rewrite.
  5. 2026-09-20v0.3.0 Redis Streams replace CRDs; Gateway added.

Why did state have to leave Kubernetes' etcd?

etcd, the store behind every Kubernetes control plane, was built to hold a cluster's configuration: Deployments, Services, a few thousand Pods that change occasionally. Its default storage cap is 2GB, the aggressive recommended ceiling around 8GB. Fine for infrastructure, nowhere near enough for a task that lives ninety seconds and vanishes.

Every AX Task used to be a Kubernetes custom resource: every creation, status change and completion was an etcd write, pushed to every watching controller. Multiply that by millions of short-lived tasks and you hit the failure mode DESIGN.md names: "Storing millions of short-lived tasks as Kubernetes CRDs pushes etcd past its comfort zone (single-digit GB storage limits, write-rate bottlenecks, control plane degradation)." CRDs are the wrong shape for a job queue, not infrastructure.

AX v0.3.0 control plane, from CLI to sandboxed agent A CLI request flows to ax-server, a stateless gRPC API on port 8080, which writes task state into Redis hashes and pushes an event onto a Redis stream. A horizontally scaled ax-controller pool consumes that stream through consumer groups and provisions a sandboxed task on Agent Substrate. A dashed Gateway fence with a host allowlist surrounds the sandbox. AX v0.3.0 CONTROL PLANE ax CLI (apply / get / watch) ax-server gRPC :8080 · stateless Redis hashes (state) + streams (queue) ax-controller pool XREADGROUP consumers · scale by replica GATEWAY · HOST ALLOWLIST Agent Substrate sandboxed task ("atespace") genztech.blog
Fig 2 A Redis stream, not an etcd watch, is now the work queue between the API server and the controllers that provision sandboxes.

A Redis stream is an append-only log with consumer groups built in; XREADGROUP lets workers claim entries without stepping on each other, no storage ceiling attached. Now ax-server is a stateless gRPC API on port 8080 that validates manifests and publishes events onto the stream. A scalable pool, ax-controller, consumes it, provisions sandboxed atespaces on Agent Substrate, and enforces the task's Gateway policy. Need more throughput? Add controller replicas, impossible past etcd's single-writer limits.

What else shipped in v0.3.0?

Google cut things too: the earlier Python harness, the ATE client, the SQL-based event log and the bundled skill examples are gone. In their place, Gateway, a primitive letting a platform team declare which hosts an untrusted agent may reach.

AX now runs on four YAML primitives under ax.io/v1alpha1: Task (sandboxed agent code, CPU and memory limits), Workspace (pre-wires the Git repos, MCP servers and skill packages an agent needs so it starts warm), Gateway (the network fence), and Model (which LLM to call, credentials from a Kubernetes secret; the README's example points at gemini-3.8-flash). ax suspend and ax resume checkpoint an idle agent and resume it where it left off; ax ssh drops into a running agent's shell when spec.debug: true is set. None of this is a weekend install: it needs a Kubernetes cluster, the ko build tool, a registry, and a reachable Agent Substrate Control API before make deploy installs Redis and the control plane into an ax-system namespace, infrastructure for platform teams running agent fleets, not one developer wiring up one agent.

How does AX stack up against Temporal, OpenAI's SDK and plain Kubernetes Jobs?

AX v0.3OpenAI Agents SDKTemporalKubernetes Jobs
Unit of workTask manifest (YAML)In-process agent runWorkflow + activitiesJob / Pod
State storeRedis (hashes + streams)Process memoryCassandra/Postgres/MySQLetcd, via the Pod
SandboxingAgent Substrate atespacesNone built inNone built inContainer only
Network policyGateway allowlistNoneNoneManual NetworkPolicy
Suspend / resumeYes, checkpointedNoDurable, wait/signalNo
MaturityPre-1.0, breaking changes likelyStable SDKMature, years in prodMature, not agent-aware

Temporal is the closest real rival on durability, but has no sandbox or network fence for untrusted code. The OpenAI Agents SDK is a library you import, not a cluster scheduler, so there's nothing to compare on state store or suspend semantics. Plain Kubernetes Jobs win on maturity and lose everywhere agent-specific; you'd hand-roll the rest yourself.

RelatedDeepMind Disbanded the AlphaFold Team, Not AlphaFold

What does this mean for the market?

Google Cloud gets a concrete answer to "what's your agent infrastructure story," open-source infrastructure running on any Kubernetes cluster, not only GKE, a different pitch than the managed, single-cloud tooling AWS and Azure favor here. "We wrote the orchestrator" is still gravity toward Google Cloud, and Alphabet (GOOGL).

Redis Ltd. is the other name worth watching. AX is one more piece of high-profile infrastructure treating Redis Streams as the default answer for ephemeral, high-throughput state, a data point that Redis keeps winning the fight over what sits in front of a database when full database semantics cost too much.

What to watch · late 2026
  • Whether the churn slows. Three releases in five months, two removing entire subsystems. A v0.4 that adds rather than rips out is the real signal.
  • Real throughput numbers. "Billions of workloads" is a design goal, not a published benchmark.
  • Whether AWS or Azure answer with something comparable. Neither ships an open, cluster-native agent scheduler like this yet.

Our take

AX is Google saying out loud what platform teams running agents have been muttering privately: Kubernetes is a solid scheduler for services, and a mediocre one for a queue of stateful jobs that need a leash. Moving state to Redis Streams isn't a clever optimization, it's an admission the first architecture picked the wrong primitive.

That doesn't make AX finished. "Billions of workloads" is a design target in the README, not a published benchmark, and a project that just deleted its Python harness, event-log database and bundled examples in one release is still finding its architecture; it also depends on Agent Substrate, a second, equally young project, for the sandboxing itself. Still, it's the clearest attempt yet at defining what infrastructure looks like for a workload that accumulates state, needs strict isolation, and can burn real money unattended. Platform teams running agent fleets should test it against their own load; anyone wiring up a single agent can wait for the README warning to come off the door.

Primary sources

Original analysis by GenZTech. Source: google/ax on GitHub