Google AX turns agent runs into resumable jobs

Google AX is a distributed agent runtime for resumable, auditable agent runs.

Google's AX repo shows a runtime built for agent jobs that can pause, recover, and keep state across distributed components. The project says it is in early development and already has 1.7k stars.

1. Resumable execution

AX is built around the idea that an agent run should survive interruptions. If a client disconnects, the runtime can replay missed events from the last sequence number instead of restarting the whole conversation.

That matters when agent work takes time or depends on several steps. The CLI examples in the repo show both fresh runs and resumed runs, including cases where a conversation continues with new input after a failure.

• ax exec --conversation ... --resume
• ax exec --last-seq 12 --resume
• Resume by conversation ID

2. Event logging and auditability

AX keeps execution state in an event log, with a single controller managing writes. That design gives the runtime a clear record of what happened and makes it easier to inspect or replay agent activity later.

The repo frames this as a control and audit feature, not just a storage detail. User calls, agent calls, tools, and skills all flow through the controller, which gives teams one place to trace execution.

• Single-writer architecture
• Durable event log
• Controller-based coordination

3. Isolated agents, tools, and skills

AX treats agents, tools, and skills as isolated actors that can run separately from one another. The overview diagram shows a controller routing work to remote agents, tools, and an environment with built-in skills.

That split is useful when you want to keep workloads apart for safety, reliability, or scaling. It also fits systems where different tools are exposed through RPC or MCP-style services instead of being bundled into one process.

• Remote agents over gRPC
• Tools via MCP servers
• Environment and skills as separate actors

4. Custom agents and CLI control

AX ships with a command-line interface that can execute built-in agents or custom ones. The repo includes examples for running a remote agent server, registering it in ax.yaml, and then invoking it through ax exec.

For developers, that means AX is not only a runtime spec. It is also a practical interface for testing agent behavior, wiring in your own agent IDs, and resuming work from the same conversation state.

ax exec --server localhost:8494 --input "Hello agents!" ax exec --agent coding --input "Write a simple HTTP server in Python" ax serve --config my-config.yaml

5. Kubernetes-first deployment

The project says AX is natively supported on Agent Substrate on Kubernetes and recommends that setup for production. It is also described as compute-agnostic, so the core runtime is not tied to one deployment shape.

That makes AX more interesting for teams planning long-running agent workloads than for one-off demos. If you need a controller, recovery behavior, and distributed actors in a production cluster, Kubernetes is clearly the path the maintainers want you to take.

• Recommended production option: Kubernetes
• Works with local and server modes
• Designed for small and large deployments

How to decide

Pick AX if you are building agent systems that need recovery, replay, and a clear execution record. It fits teams that expect agents to run as long-lived jobs rather than short prompt-response calls.

If you only need a simple local wrapper around a model, AX is probably more runtime than you want right now. If you need distributed coordination, custom agents, and a path to Kubernetes, it is worth watching closely.