AX

AX is Google's declarative orchestration runtime for running autonomous AI agent workloads on a cluster. It is aimed at platform and infrastructure engineers who already think in manifests, schedulers and resource limits, and who now have to run agents the same way they run services. The repository makes the comparison itself: if you have used Kubernetes, ax will feel familiar — you write YAML that describes the work, apply it, and the system places the workload and lets you watch it. The project has collected 12,839 stars and 632 forks since it was created in March 2026, and the video's framing is that it picked up about three thousand of those stars in a single week, alongside more than six hundred points on Hacker News in a day.

What it does

AX treats an agent run as a first-class cluster workload. Its own argument is that agents 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. The answer is a small set of declarative primitives:

• Task — runs untrusted agent code in an isolated sandbox with CPU and memory limits.
• Workspace — pre-wires Git repositories, MCP servers and skill packages so an agent starts warm instead of cloning and configuring itself on every run.
• A third resource configures which LLM the platform itself uses, with credentials pulled from a Kubernetes-style secret. The README's table is truncated in the copy available here, so its exact kind name is not quoted.

The stated ambition is throughput: AX describes itself as a high-throughput orchestrator built to run billions of autonomous agent tasks per cluster.

How it works

Objects are declared under the ax.io/v1alpha1 API group with kind, metadata and spec fields, which is what makes the Kubernetes resemblance more than skin deep. A Workspace named golang lists a Git repository and the branch to check out. A Task then references that workspace by name and attaches a goal written in plain English — the README's example asks the agent to ensure a Go toolchain is available and built from source. Setting debug: true on the task keeps the sandbox reachable so a human can open a shell into it and look over the agent's shoulder.

Execution is not AX's own invention. Sandboxed execution is delegated to Agent Substrate, a separate project that AX runs on top of. AX is the declarative layer above that: it accepts your manifests, wires up the workspace, and schedules and exposes the run. The implementation is Go, under the Apache 2.0 licence, with the most recent push in late September 2026.

Getting started

The workflow in the README is three commands against one file:

• ax apply -f task.yaml submits the workspace and the task together.
• ax watch task test follows the task as it comes up.
• ax ssh test -- ls -al /workspace runs a command inside the sandbox, or drops you into it.

Before planning anything around this, read the warning at the top of the repository. The maintainers state that AX and several of its features are in heavy development, that core concepts, protocols and specifications are still being refined, and that major breaking changes are likely before a stable release. The v1alpha1 in the API group is not decoration.

When to use it / when not

AX is a reasonable fit if you are running many agent jobs rather than one, if isolation and hard CPU and memory ceilings are a requirement rather than a nicety, and if your team is comfortable keeping workload definitions as YAML in version control. The Workspace primitive is the practical draw for anyone who has written the same repository-clone-and-MCP-setup glue three times.

It is a poor fit in a few cases. If you run a single agent on a laptop, a cluster orchestrator is overhead with no payoff. If you need a stable API to build a product on this quarter, the project says plainly that it will break. And if what you are looking for is the agent itself — the reasoning loop, the prompt strategy, the tool-calling logic — AX does not supply that. It runs agent workloads; it does not write them.

Anyone operating AI agents as production infrastructure should read this repository now, because it is the clearest statement yet of what the Kubernetes model looks like when the pods are agents that spend money. Platform teams with an existing cluster and a growing pile of ad-hoc agent runners are the natural audience, and the Task and Workspace split is worth studying even if you never deploy it. Everyone else should bookmark it and wait for the alpha label to come off.