# Google AX Wants Billions of Agent Tasks. Start With a Budget Kill Switch. **Summary:** Google AX isolates, suspends, and resumes agent tasks, but its preview does not establish a cumulative job budget or a published billion-task benchmark. I would pilot one reversible workload behind an external spending and stop boundary. - Canonical: https://markhuang.ai/news/google-ax-billion-task-budget-boundary - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-09-21 - Section: News - Tags: Google AX, AI Agents, Agent Infrastructure, Kubernetes, Cost Controls - Source: [Agent Executor](https://agentexecutor.io/) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![A vast grid of isolated agent task capsules surrounds one hot looping task held behind a containment barrier](https://cdn.markhuang.ai/news/google-ax-billion-task-budget-boundary/hero.webp) *Fleet scale is the attractive part of the pitch. The production decision starts with the one task that loops, spends, or resumes badly.* Google's [Agent Executor site](https://agentexecutor.io/) now presents AX as a declarative runtime that can sandbox an agent task, prepare its workspace, restrict its network, and scale to billions of tasks per cluster. The project is trying to make long-running agents look less like fragile scripts and more like workloads an operator can inspect, suspend, and resume. I think that is the right problem. Google introduced AX on May 20, 2026, after describing agent jobs that can run for hours or days and fail around outages, client disconnects, or human approvals. My hesitation begins where the scale pitch gets loudest. I would not start by asking whether AX can coordinate a billion tasks. I would ask whether one task can be stopped before it repeats an expensive or irreversible action. Sandboxing the process does not cap model charges or reverse an email, payment, or deployment. AX can provide useful boundaries, but the operator still has to prove what happens at those edges. ## The runtime sits below the agent's judgment AX is not a new model or planning framework. Its current design gives operators four main resources: a `Task` for isolated execution, a `Workspace` for repositories and tools, a `Gateway` for network policy, and a `Model` for provider configuration. That separation appeals to me. It keeps orchestration concerns out of whichever harness happens to be fashionable this month. The [Google Cloud launch post](https://cloud.google.com/blog/products/ai-machine-learning/agent-executor-googles-distributed-agent-runtime) describes event logs and snapshots for recovery, single-writer session state, client reconnection, and trajectory branching. Those are practical answers to failures that show up only after an agent stops behaving like a short API request. The repository also makes the deployment cost visible. Its quickstart requires Kubernetes, Redis, a container registry, `ko`, and a reachable Agent Substrate API. This is infrastructure for teams that already need a control plane. If my workload is a few short, reversible jobs, adopting that stack could create more operational surface than it removes. ## The billion-task claim is a destination, not evidence The landing page says AX can run billions of tasks per cluster. Agent Substrate, the underlying execution layer, publishes smaller concrete figures: its README describes sub-500-millisecond resume operations, more than 500 suspend or resume activations per second, and a reproducible demo that multiplexes about 250 stateful actors across eight physical pods. Those figures help explain the architecture. They do not validate every AX workload at the headline scale. None of the public materials I inspected paired the billion-task claim with a representative AX benchmark, workload mix, failure rate, or cost envelope. The [AX repository](https://github.com/google/ax) also warns that core concepts, protocols, and specifications may change before a stable release. An early project can set an ambitious target. I just would not turn it into a capacity plan. My own benchmark would use the agent, model latency, tool traffic, workspace size, and recovery pattern I expect to operate. A large idle fleet and a large fleet writing files or calling paid models are different systems. > **Info:** > > I would size AX from one controlled workload outward. The first acceptance test is not peak task count. It is whether the operator can deny a call, exhaust a budget, suspend the job, restore its state, and avoid repeating an external action. ## A sandbox does not stop the meter AX's own site notes that agents can burn money in a loop. That is unusually honest, and it points to the gap I care about most. A [September 20 source review by Wavect](https://wavect.io/blog/google-ax-agent-executor-security-self-hosting/) found that the reviewed `TaskSpec` no longer exposed the earlier budget and approval policy field. It also found usage counters, but a counter reports consumption after the fact. It is not an admission control. So I would put the spending limit outside the task. Every model request should pass through an operator-controlled gateway that knows the parent job, reserves against a cumulative allowance, accounts for retries and child tasks, and refuses the next call when the budget is gone. The task should not hold credentials that let it route around that boundary. Network policy needs the same skepticism. A hostname allowlist can block broad internet access, yet an approved tool may still perform powerful actions on the agent's behalf. AX can fence the route. The tool still needs its own authorization, idempotency keys, and audit record. This extends the lesson from my earlier look at an [agent running a small business for 24 hours](https://markhuang.ai/news/gpt-5-6-sol-optimized-the-score): autonomy should be split into permissions and budgets that can fail independently. One blanket instruction is a poor substitute for a boundary the agent cannot edit. ## The resume path deserves a hostile test Durable execution sounds reassuring until the word "durable" hides two different promises. AX's runner documentation says `/workspace` survives suspend and resume, while the task returns in a fresh container with a new process tree. It also says the control plane does not currently read the command's exit status back from the container. That means my agent must persist enough state to resume deliberately, and my supervisor needs a completion signal stronger than a healthy runner. I would kill the task between a tool request and its response, revoke its credential while it is suspended, and resume it after an external write has succeeded. Restored files are only part of the pass condition. The job must know what already happened and avoid doing it twice. ## One boring pilot before a fleet I would pilot AX with synthetic data, a disposable repository, and a low-privilege model credential. I would pin the AX and Agent Substrate revisions because the interfaces are still moving. Then I would test a hard cost ceiling, denied network destinations, credential revocation, failed command reporting, suspend and resume, and a rollback to the previous runtime. If AX passes those tests, the project has real appeal. The four-resource model is small enough to understand, and separating execution from the agent harness could let teams change models without rebuilding the operational layer each time. But I would earn scale in that order. First prove that one agent can fail safely. Then prove that ten agents share budgets and credentials correctly. The billionth task is an infrastructure problem. The first runaway loop is a product problem, and it arrives much sooner.