Declare agent tasks in YAML and run them safely in a cluster
What if agent tasks that modify code and run tests could happen in an isolated space, pausing and resuming whenever needed? AX is a runtime that defines agent tasks declaratively, executes them in sandboxes, and manages them at scale. It follows a structure familiar to anyone who has used Kubernetes, allowing complex agent workloads to be controlled with simple YAML files.
Current development status and key changes
AX and some of its features are currently in active development. Core concepts, protocols, and specifications are being refined, and major breaking changes may occur before a stable release. Therefore, it should be used with the expectation of such changes rather than being applied directly to production environments. It is appropriate to view it as a tool focused on proof of concept and early experimentation.
Three primitives for agent workloads
Agents differ from stateless microservices or batch jobs.
- Task Executes untrusted agent code in an isolated sandbox with CPU and memory limits.
- Workspace Pre-configures Git repositories, MCP servers, and skill packages so that all agents start in a ready state.
- Model Configures the LLM the platform will use and securely retrieves credentials from Kubernetes secrets.
- Pause and Resume Allows pausing idle agents and resuming them exactly where they stopped.
- Debugging Enables direct inspection of internal state by connecting to a running agent sandbox via shell.
Kubernetes-based installation and execution
AX schedules all tasks on top of a sandbox execution environment called Agent Substrate. Therefore, Agent Substrate must be installed in the cluster, and Go, kubectl, ko, and a container registry are required. Agent Substrate is installed in the ate-system namespace, and AX communicates through its Control API. The CLI is installed using the go install command, and the control plane is deployed using the make deploy command. During deployment, PostgreSQL is installed, and the control plane image is built and deployed using ko. All configuration is located in the ax-system namespace.
kubectl-style CLI interface
The ax CLI communicates with the control plane via gRPC and follows a structure similar to kubectl. In addition to basic commands like apply, get, describe, and delete, it provides agent-specific commands. It also integrates with kubectx to automatically connect to the control plane following the active Kubernetes context.
An early-stage tool requiring stability verification
AX provides the basic structure needed to manage large-scale agent workloads, but it is not yet a stable version. Since core specifications and protocols may change, it is recommended to verify it in development and testing environments first rather than relying on it for production systems. It is distributed under the Apache License 2.0, and its dependency on Agent Substrate is clear, making it suitable for teams that have already built that infrastructure. If you need to directly manage the isolation and scheduling of agent execution environments and prefer a declarative approach, AX is worth considering. However, because major features are likely to change, you should consistently check the latest release notes.
