Google just released AX, an orchestrator built to run agentic tasks at a scale most of us will never touch. Sandboxed workspaces, network policies, sub-second suspend and resume, billions of concurrent tasks per cluster. It is genuinely clever infrastructure. It also has almost nothing to do with what determines whether an AI agent works for the businesses I build for.
What AX is actually solving
Reading through the AX documentation, the problem they are solving is real and specific: agents are not stateless microservices and they are not predictable batch jobs. They sit idle waiting for a model to respond, then burst into activity, then wait again. Keep a sandbox running the whole time and you pay for idle capacity. Google's answer is to checkpoint and suspend an agent in under a second and bring it back with no cold start, so you only pay while it is actually thinking. Wrap that in isolation, an allowlist for network traffic, and a single place to configure models and rotate keys, and you have a control plane for running agent fleets at research and production scale.
That is a compute density problem. It is the kind of thing you need if you are running reinforcement learning loops or evaluating thousands of agent variants at once. I do not doubt it is useful for that. I just do not think it tells you anything about whether the WhatsApp bot or voice agent you are considering for your own business will actually work.
The businesses I work with don't have a scale problem
Nobody I have built for needed to run a billion of anything. A clinic needs one voice agent that calls the right patients at the right time and says the right thing. A distributor needs one document pipeline that reads an invoice correctly. The unit of success is not throughput, it is whether that single agent, run a few hundred times a day, does its job without embarrassing anyone.
I built a voice bot for a hospital that calls pregnant patients in their eighth month with health guidance, and again after delivery for follow-up care. Before that, staff made every one of those calls by hand. The infrastructure question, sandboxing, isolation, none of it mattered here. What mattered was listening to the actual calls after launch. The first script was too long, so I cut it to what a patient genuinely needed to hear. And the calls moved into the patients' own local language, because people listen differently when spoken to in the language they think in. Neither change came from planning. Both came from sitting with recordings and noticing where people disengaged. The result was full coverage on critical follow-up calls, with staff doing none of the manual dialling they used to do.
That is the work. Not orchestration. Listening.
Where the actual gains come from
I built myself an email assistant that sends a short WhatsApp message every morning listing the emails that need action. Everything else waits until I choose to look at it. I stopped opening my inbox first thing in the morning, which used to set the agenda for my whole day around other people's priorities. The effect was bigger than the tool because it changed a habit, not because it processed anything at scale. One agent, one job, checked once a day.
The same pattern showed up when I ran automated Instagram posting and an AI music channel on YouTube. I expected a few standout posts to carry the account. What actually mattered was posting reliably. An account that shows up on schedule builds an audience that expects it. An account that posts one great thing and goes quiet has to start over every time. Automation earned its place there not by making each post cleverer, but by making sure the posting never stopped. Again, nothing about scale. Everything about consistency.
Same story with getting a site read properly by AI answer engines. On my own site I set up structured data, an llms.txt file, and deliberately let crawlers from ChatGPT, Claude and Perplexity in rather than blocking them, which is what a lot of sites still do by default. On a client site I automated the internal linking and ran a monthly SEO pass. I have since seen sites I work on cited in AI answers. None of that required an orchestrator. It required doing the boring maintenance work every month without skipping it.
What I'd actually ask before touching infrastructure like this
- Is the agent doing one job well, or is it trying to be a general assistant that does everything badly
- Has anyone actually listened to or read what the agent produces, or has it only been tested against a script
- Would this still work if it ran ten times a day instead of ten thousand
- Is the bottleneck compute and isolation, or is it that nobody has iterated on the thing after launch
Most businesses answer that last question and realise the bottleneck was never infrastructure. It was that the agent got built, deployed, and then nobody went back to fix the parts that were obviously wrong once real people started using it. AX solves a problem that appears when you are running agents at a density none of my clients will ever reach. If you are a founder wondering whether you need something like it before you automate a process, you almost certainly do not. You need someone to sit with the first hundred real interactions and change what is clearly not working, which is unglamorous and has nothing to do with clusters or sandboxes.
Google building this says something about where the frontier of the industry is pointed, toward running enormous numbers of agents cheaply for research and large-scale deployment. That is a different problem from the one sitting in front of most operations leads right now, which is simply getting one agent to behave.
