AX – Google’s Open Agentic Orchestrator
Google’s new AX project aims to provide a Kubernetes-based, open source “agentic orchestrator” for running large numbers of AI agents in secure, sandboxed environments, with features like fast snapshot/resume and tight network and permission controls. Commenters are split: some see it as a serious, infra-level tool suited to research labs or enterprises needing to manage bursty, untrusted agent workloads at scale, while others view it as overengineered “Kubernetes for agents” that’s unnecessary for typical development use. Skepticism is heightened by Google’s mixed track record on sustaining both products and open source projects, leading many to treat AX as experimental and potentially short-lived despite its technical ambition.
What AX Is and Isn’t
- Many readers struggled to understand AX’s purpose from the landing page; “orchestrator” felt vague.
- Clarified by some as: k8s-based control plane to run LLM agents in isolated sandboxes off the user’s machine, with egress controls, resource limits, and fast suspend/resume.
- It is infra-level, not an app-layer agent framework like LangChain; more about “where and how agents run” than “how they think.”
Kubernetes, YAML, and Complexity
- Strong criticism that AX is “Kubernetes for agents”: requires a k8s cluster, container registry, Agent Substrate API, YAML configs.
- Some see this as needless overengineering and not “ergonomic” despite marketing claims.
- Others argue that in enterprise or existing k8s environments it’s natural: familiar primitives, easy add‑on if you already have clusters, and aligned with industry infra patterns.
Security, Sandboxing, and Scale
- Positive reactions to strong isolation: microVM/gVisor, zero‑trust egress allowlists, MITM gateway, fast task resumption, workspace persistence.
- Several note this matches real needs for running untrusted agent code, especially at scale or in security-sensitive workflows.
- Debate over microVM technologies and how much isolation different approaches (Firecracker, qemu, smolvm, etc.) actually provide.
- AX is seen as more relevant for large, bursty agent workloads (evals, RL, training) than for small dev teams.
Comparison to Other Google Efforts and Ecosystem
- AX builds on Agent Substrate, which is being moved into CNCF; contrasted with another Google project, Scion, which wraps existing harnesses and is seen by some as more integrative.
- Some prefer Scion or other orchestrators that run “normal workloads” and existing harnesses rather than requiring a new stack.
- Many remark that “everyone and their grandmother” is building agent frameworks/sandboxes; there is no clear “React of agents” yet.
Trust in Google and Longevity
- Recurring skepticism about Google’s product and open-source longevity, citing “killed by Google” history and quickly abandoned tools.
- Others counter with examples of long-lived Google OSS (Kubernetes, Go, Chromium, etc.), but overall sentiment: treat AX as experimental and avoid deep production dependence.
Usefulness and Overkill
- Some see strong technical merits and are excited to study its design.
- Others argue very few users actually need “billions of agents” or such heavy infra; for many, simple VMs, containers, or local tools remain sufficient.