Four alpha resources make agent work look like cluster state
AX v0.3.0 reduces its control model to four resources: Task, Workspace, Gateway, and Model. A Task is one isolated unit of execution. A Workspace prepares repositories, MCP servers, and skill packages. A Gateway controls listeners and outbound hosts, while Model points at a provider configuration and a Kubernetes secret. The ax CLI applies those YAML objects and exposes familiar verbs such as get, describe, watch, and delete.
That division is the project's best idea. An agent can retry, delegate, or create a tree of tasks without AX pretending the whole tree is one long process. Operators get a small object to limit, suspend, inspect, and discard. Workspace setup can be reused instead of rebuilt in every agent image. The payoff arrives only when you already have enough agent jobs to justify a control plane. For one coding bot on one machine, four resource types and a cluster are needless ceremony.
The 0.5 MB checkout passed every package test
Our commit d8ed0fe checkout held 62 files and about 14,518 lines of source in 0.5 MB. It installed 247 Go packages in 27 seconds, built in 60 seconds, and completed the test step in another 22 seconds. Go reported 16 passed packages and 0 failures. The repository also had 2 CI workflow files, though our scan found no file named Dockerfile and no top-level tests directory.
Those results make the Go code easy to inspect and change. They do not prove the advertised cluster scale, sandbox isolation, checkpoint reliability, or model cost controls. Our sandbox had 3 CPUs, 8 GB of RAM, no secrets, and no Agent Substrate cluster. We tested the checkout's install, build, and package suite. We did not run billions of tasks, and the README's scale claim should be treated as the project's target rather than our benchmark.
What happened when we ran it
Our sandbox installed all 247 packages in 27 seconds and used the golang:1.24-bookworm image. The build succeeded in 60 seconds. The test run then passed 16 of 16 packages in 22 seconds, with no failed package reported. There was no failed log tail to interpret and no vulnerability count in the supplied measurement, so neither belongs in a buying decision for this commit.
The clean result has a narrow meaning. It says a fresh, unprivileged Debian container could resolve the Go dependencies, compile the repository, and pass the available go test packages. AX's development guide separately lists Go 1.27 or newer, ko, Docker or Podman, Kubernetes, and kubeconfig as prerequisites. A successful library build is only the start of an AX evaluation. The complete deployment has several services our sandbox did not provide.
Deployment adds Redis, a registry, and Agent Substrate
The 27-second install does not include the services that make AX useful. The make deploy target pushes control-plane images with ko, installs Redis, and places AX in the ax-system namespace. The server stores task state in Redis and publishes work through Redis Streams. Controllers then call an external Agent Substrate Control API to create actors, assign workers, and apply egress policy.
This architecture avoids storing millions of short-lived tasks as Kubernetes custom resources, which the design document says would stress etcd. It also gives you another control API to deploy and trust. A real rollout needs a pullable image registry, Redis durability choices, network paths to Substrate, secrets for model providers, and an answer for task-runner images. If your platform team already owns those concerns, AX can put one interface over them. Otherwise, AX creates the platform project before it runs the agent project.
Two open security reports block a casual production rollout
Two open issues describe failures at the exact boundaries AX is meant to enforce. Issue 363 reports that a manifest-controlled Git branch or repository value can make git fetch execute a command inside the task-runner container. Issue 350 reports that a Task referring to a missing Gateway can still start with wildcard egress. We did not reproduce either report in our 22-second test run, so they remain issue reports rather than lab-confirmed findings.
Both reports matter even though execution occurs in a sandbox. AX is sold on turning manifests into constrained work, and a platform operator may allow users to submit those manifests. Command execution during workspace setup crosses from configuration into code before the intended agent command begins. Wildcard egress after a missing policy reference reverses the expected failure mode. Until fixes land and regression tests cover both paths, keep manifest authors trusted and place AX inside another network boundary.
v0.3.0 is active and still explicitly unstable
GitHub showed 7,004 stars and 22 combined issues and pull requests on September 22, 2026. The last push and the v0.3.0 release both landed on September 20. Issue activity continued through September 22, including detailed reports about ARM image builds, task reconciliation, Redis updates, and gateway behavior. Active maintenance is clear from the dated changes and reports.
The README is also unusually direct about maturity: core concepts, protocols, and specifications may change before a stable release. An external-roadmap issue still lists resource stabilization, gateway reconciliation, identity, automatic suspension, custom runners, and clearer Substrate layering. That is useful disclosure, and it defines the buyer. AX is for a platform team willing to test and influence an alpha system. Anyone seeking a settled multi-tenant boundary should watch the fixes, then repeat the deployment and adversarial tests before adoption.