AINEWS
AX offers sandboxing, repos, network policy, and model keys as one declarative runtime. The lock in question is what every agent builder should walk away with.
A new open-source project called AX wants to do for AI agents what Kubernetes did for containers: turn a sprawling, hand-rolled mess of scripts and cron jobs into a small declarative spec. The repo sits at github.com/google/ax, and the project page frames the target as "billions of autonomous agent workloads in a cluster." The work runs on top of a separate runtime the project calls Agent Substrate, a compute layer built for "massive density and fast stateful actor lifecycles," where the agent itself is treated as a cheap, suspendable, throwaway task rather than a long-lived process.
The four primitives are deliberately small. Isolated execution wraps each unit of work in a sandbox with CPU and memory limits. A Workspace wires the sandbox to a git repo, an MCP server, and a set of skills, so the agent starts with the right context. A Gateway applies an allowlist of network destinations and injects credentials, so an agent can call outside services without a human pasting API keys into a prompt. A Model resource centralizes model configuration and secrets in one place, so swapping providers is a config change rather than a code change. The concepts doc puts every AX resource inside a namespace called an "atespace" (default name: "default"). A Task is the smallest isolated unit; it can be the whole job or the root of a tree of subtasks as an agent breaks the problem down. Tasks can be created, watched, suspended, resumed, and deleted; they expose phase, actor, and worker IP, and there is an ax ssh command for poking inside a running sandbox.
The workload framing is the part that needs translation. The project page calls agents "a new kind of workload" that "are neither microservices nor batch jobs" and warns they "can burn money in a loop if nobody is watching." In practice that means a system has to handle long-lived, stateful, model-driven jobs that do not fit either the request-response shape of a web service or the scheduled, run-to-completion shape of a batch job. Treating the agent task itself as the unit of scheduling, rather than the container that runs it, is the bet. A Hacker News commenter reading the early code put it bluntly: the AX actor model is "pretty neat." The same commenter compared the project to Google's Scion effort and called AX "a greenfield independent effort" that ships "a pretty huge stack" of runners, harness, and substrate.
A few things are not yet public, and they matter. The README warns that the project is "still actively refining our core concepts, protocols, and specifications" and that "major breaking changes" are likely before a stable release. The project page does not name the operator behind the work, list a customer, ship a benchmark, or include an independent side-by-side against Kubernetes primitives, Temporal, or Ray actors. The "billions per cluster" line is a vendor claim, not a measured number, and the landing page's framing of agents as a "new kind of workload" echoes earlier waves (serverless, then actors) that promised similar category-defining breaks.
The portable question is not whether AX wins. It is what flows through whatever wins. If a primitives-based runtime becomes the default for agentic work, model keys, network egress, and sandbox boundaries all pass through it. That is a platform-lock-in decision disguised as a tooling choice. Three questions follow any team building agents in 2026 into the next vendor demo: where do model credentials actually live and who can rotate them, can egress be fenced to an explicit allowlist, and can a long-running agent task be suspended and resumed without losing state. AX's four primitives claim to answer all three. The reader's job is to ask the same questions of whoever comes next.