Google's ax Makes an AI Agent a Kubernetes Object, and Suspend Is the Command That Matters

A declarative orchestrator that runs agent tasks as sandboxed actors, where pausing a running agent and picking it up later is the primitive your harness does not have

Google published an orchestrator called ax that treats a running AI agent the way Kubernetes treats a pod. You write YAML. You run ax apply -f task.yaml. Then ax get tasks, ax describe task <name>, ax delete task <name>, and if you want to look inside, ax ssh <task> -- <command>.

Every one of those has an obvious analogue in something you already use. One command in the list does not:

ax suspend task <name>
ax resume task <name>

Sandboxing is table stakes by now. Trail of Bits ships disposable VMs for coding agents. Cloudflare and Microsoft both sell agent sandboxes. What none of them offer, and what no coding harness offers either, is a paused agent that the scheduler is holding for you.

What "resume" means in every other tool, and what it means here

When Claude Code or Codex resumes a session, it replays a transcript. The conversation comes back. The process does not. Anything the agent had in flight, a half-written file in a container that no longer exists, an open connection, a build that was thirty seconds from finishing, is gone, and the model reconstructs its situation from what it can read on disk plus what it said last time.

That works because agents are mostly stateless between turns by design. It also means an agent's actual execution is disposable, which is fine for a ten-minute task and expensive for a four-hour one.

ax's README describes suspend differently: "Pause an idle agent and pick up exactly where it left off." The claim is about execution, not transcript. If the task is a cluster object with a sandbox attached, then pausing it is a scheduling decision rather than a teardown. The cluster keeps the thing; you get the node back.

I want to be careful here, and I will come back to it in the limitations, because the README does not say what suspend actually persists.

The three primitives, in the project's own words

ax has a small surface. Three resource types carry it.

Task. "Run untrusted agent code in an isolated sandbox with CPU/memory limits." The project's own concepts doc calls it the smallest unit of isolated execution, declaring container images, compute resources and a workspace reference. Tasks are meant to be small and disposable.

Workspace. "Pre-wire Git repos, MCP servers, and skill packages so every agent starts warm." One workspace serves many tasks. This is the piece that removes per-task setup, and it is the piece most teams have hand-rolled badly.

Model. "Configure which LLM the platform itself uses, with credentials from a Kubernetes secret." Provider settings, model identifiers and API credentials become a cluster resource rather than environment variables scattered across jobs.

Underneath sits a component the README names but does not ship here. Of ax, the README says: "It runs on top of Agent Substrate for sandboxed execution and is built to run billions of tasks per cluster." Agent Substrate is the actual isolation layer. ax is the control plane on top of it.

The part that transfers even if you never install this

Model an agent run as a resource and you inherit an entire operational vocabulary for free.

Quotas become CPU and memory limits on a Task. Access control becomes RBAC. Credential handling becomes a Kubernetes secret with a documented blast radius instead of a dotfile with an undocumented one. Observability becomes ax watch task <name>. Cleanup becomes ax delete. Cost control becomes the same problem as any other workload that the README is refreshingly blunt about, noting agents "can burn money in a loop if nobody is watching."

The Model primitive is the one I would copy first. Putting provider credentials in a secret, referenced by name from the task spec, means the question "which agents can spend money against this API key" becomes an RBAC question with an auditable answer. Most agent setups answer it with "whoever can read the environment," which is not an answer.

The Workspace primitive is the second. Pre-wiring git repos, MCP servers and skill packages into a named, reusable object is portable to any harness, with or without Kubernetes. Right now most teams express that as a setup script that drifts.

Put this into practice

Do not start by installing it. The install is a real commitment: you need a Kubernetes cluster with Agent Substrate already on it, plus Go, kubectl and ko, then go install github.com/google/ax/cmd/ax@latest and make deploy AX_IMAGE_REPO=<your-registry>. Agent Substrate is the dependency that decides whether this is an afternoon or a quarter.

Start with a sheet of paper instead. Write down your current agent setup's answer to each of the three primitives:

Task. What limits a runaway agent's CPU, memory and wall clock today? If the answer is "nothing, it runs on my laptop," that is your first gap and it is fixable without Kubernetes.
Workspace. How does a new agent run get its repo, its MCP servers and its skills? If the answer is a shell script nobody has read in two months, name it, version it, and treat it as a resource.
Model. Where does the provider credential live, and who can read it? Write down the actual list of processes and people.

Most teams find gap two and three are the expensive ones, and neither requires adopting ax to fix.

If you do run a cluster and want to evaluate it properly, the single test worth running is the one the README's strongest claim rests on. Start a long task, let it get genuinely mid-work, ax suspend task, wait, ax resume task, and then check whether the work in progress survived or whether the agent reconstructed it. That is a one-afternoon experiment and it separates "pick up exactly where it left off" from "reload the conversation."

One operational note before you do: the Model secret and untrusted task pods should not share a namespace without checking what RBAC actually grants. The Task primitive's own description says the code it runs is untrusted. Take that at face value.

What this article does not establish

I ran nothing. No cluster, no Agent Substrate install, no ax apply. Everything above is a reading of the README and the project's concepts doc, and the quotes are verbatim from those files.

The central claim is the least verified thing here. The README says suspend lets you "pick up exactly where it left off" and does not say what that means mechanically. Process state, container checkpoint, conversation state and filesystem snapshot are four very different implementations with four different guarantees, and I could not determine which one ax uses. My reading of why it matters may be more generous than the implementation deserves.

Agent Substrate is doing the work that all of ax's isolation claims rest on, and I did not evaluate it. "Built to run billions of tasks per cluster" is a design statement with no published benchmark, no methodology and no independent reproduction attached.

The repository signals are mixed and worth saying out loud. Apache-2.0, but the LICENSE file is the unfilled template with Copyright [yyyy] [name of copyright owner] still in it, which is paperwork rather than a trap, though license scanners will flag it. Roughly 10,000 to 11,000 stars against about 50 watchers on a repository created on March 30, which is not the shape of organic infrastructure adoption. The star figure deserves a footnote of its own: two cache-busted reads hours apart in the same day returned 11,044 and then 10,274, a gap of about 7% in the wrong direction, so treat any single number you see for this repository, including mine, as a reading rather than a count. The latest tagged release, v0.3.0 on September 20, shipped with empty release notes. Stars are not adoption and a Trendshift position is a momentum score read at one moment, in this case 07:24 ET on September 25.

And the project tells you itself: "We are still actively refining our core concepts, protocols, and specifications. We will likely to introduce major breaking changes prior to a stable release." The grammatical slip is theirs. The warning is real, and for a CRD-based API, breaking changes mean your YAML.

The part worth keeping

The interesting move is not that Google built agent orchestration for Kubernetes. Somebody was always going to. The interesting move is deciding that an agent mid-task is a thing a scheduler can hold, because that reframes a running agent from a process you babysit into state you manage.

Whether ax delivers that is an open question I have not answered. Whether your own setup could answer the three primitive questions is not open at all, and you can settle it before lunch.

Sources: google/ax on GitHub · ax README · ax concepts doc · Trendshift daily board

Medium metadata

Title: Google's ax Makes an AI Agent a Kubernetes Object, and Suspend Is the Command That Matters
Subtitle: A declarative orchestrator that runs agent tasks as sandboxed actors, where pausing a running agent and picking it up later is the primitive your harness does not have
Tags: Kubernetes, AI Agents, DevOps, Open Source, Platform Engineering
Canonical: import from the fervorai.dev URL