AX – Google’s Open Agentic Orchestrator

We need to summarize 4 most prevalent themes in the discussion, with direct quotations. Must quote directly with author attribution, double quotes. Fix HTML entities. Output markdown. Keep overall summary short and focused on these 4 themes.

We need to read the discussion and identify themes.

The discussion is about Google's open source project AX (Agent Executor?) and general sentiment about Google's open source projects, their reliability, maintenance, use of Kubernetes/YAML complexity, and doubts about integration usefulness (Gemini in Sheets). Also talk about alternatives, open source, "killed by Google" meme.

Let's scan:

• jmathai: Not paying attention to Google news; Gemini integration in Sheets is surprisingly incapable; Google's propensity to sunset products.

• solidasparagus: This is an Apache 2.0 open source project

• Melonai: Gemini integration in Docs & Sheets is useless; can't do simple Markdown conversion; feels like they used cheapest model; paid plan absurd.

• 0gs: hidden global setting for markdown.

• SP3269: Making Kubernetes a centre of everything. This one, they won’t sunset, because it helps selling GCP services.

• lkois: Gemini notebooks cause confusion across chats.

• hypfer: Might be blessing in disguise; you shouldn't offload to LLM.

• Mizza: k8sification of AI inevitable, as salary justification.

• eleventen: k8s8n.

• MatrixMan: Kate Satan turns up.

• TomGarden: Question about Google's track record for open source releases.

• AlexErrant: They fork their own project to patch security holes and never upstream.

• joemazerino: Maintain briefly then slowly let it die.

• hustwindmaple: More like create big launch for promo, then maintain briefly then slowly let it die.

• jandrese: Sometimes they kill it off quickly.

• neuronexmachina: Google Workspace CLI maintained only a month.

• Mond_: Not official; guy not following standard procedures.

• verdverm: Yet they maintain pinned state on org page.

• blazarquasar: Some examples that went well: Kubernetes, Go, Tensorflow, Chromium, gRPC.

• calebkaiser: Less hesitant to try Google open source than new products; many open source efforts stable; V8, Jax, Protobuf; even declining ones still maintained; huge graveyard but you can fork.

• accidc: If commercially valuable, embrace, extend, extinguish.

• schainks: cgroups.

• pianopatrick: Not a fan of writing yaml.

• beeman: Assume agents will write most yaml.

• jauntywundrkind: Evaluated Google's Agent Substrate and Scion; Scion more mature, integrative; Agent Substrate is greenfield.

• solarkraft: website says low opinion; tasks don't need to be AI agents.

• pama: Need Kubernetes, ko, container registry, reachable Agent Substrate Control API.

• jauntywundrkind: Scion runs existing systems; runs Claude, Code, Pi, OpenCode.

• Mond_: Most Google bigwigs never heard of it; misleading to label as "Google's".

• foota: This looks at least more official; most unofficial have disclaimer.

• Stagnant: It is on Google's github; title from there.

• yla92: While this seems official, some other projects not official even if on github.com/google.

• welhoilija: Does Filament claim that it's Google's in repo description? It's a valid title.

• Mond_: Fair enough, missed line; point stands no GDM leadership backing.

• ShinyLeftPad: built on top of agent-substrate/substrate which is not on Google github.

• jcw90210: Agent Substrate moving to CNCF.

• varun_ch: repo description says "Google's open agentic orchestrator".

• verdverm: For comparison, Scion has disclaimer "not officially supported Google project".

• mpeg: The project that ax builds on top of does have that disclaimer, sits on non-google org.

• mynegation: Effort in GCP; red flag; Gemini CLI shut down in favor of Antigravity CLI.

• panarky: Antigravity CLI far superior to Gemini CLI.

• Mond_: Agree.

• ychnd: Not interoperable walled garden.

• esseph: Google has 200k employees; they haven't heard of most things.

• dudus: Formal announcement on blog 4 months ago.

• fg137: Think of as experimental side project; may be forgotten; Google's open source projects not trustworthy; like Android, Gemini CLI.

-skapadia: Everyone vibe coding their own solutions.

• lopatin: Confusion with other tool called Ax.

• motoboi: virtual threads for kubernetes.

• mentalgear: No meaningful difference to hundreds of other agentic frameworks; need benchmarks.

• quadrature: points of comparison?

• DanMcInerney: Critique of agentic engineering; skills universal language; overly complex yaml; heavy framework.

• handfuloflight: Asks how criticism relates to specifics; mentions skill registries.

• DanMcInerney: Overly complex yaml; heavy framework; same mistake as Claude Code's Dynamic Workflows.

• cobolcomesback: OP is workspace manager that facilitates controlled environments.

• nl: Need different skills depending on model.

• guluarte: tmux session as orchestrator.

• lantry: Dropbox comment.

• kundi: Why kubernetes? Overload.

• chrismarlow9: Future of platforms is operators in k8s to abstract developer need; overall agrees but thinks it's abuse.

• prescriptivist: Google already has gVisor running in Kubernetes as product (GKE Sandbox); pod snapshots; etc.

• somewhatrandom9: Dislike YAML; prefer KYAML.

• srcreigh: agent-substrate checks many boxes; secure microVMs or gVisor; fast resumption; Zero Trust; etc.

• LeBit: smolvm impressive.

• chrisweekly: smolmachines.com.

• srcreigh: Not interested in VM which supports mounting host filesystems in untrusted Kubernetes pods.

• LeBit: smolvm integrates with k8s.

• srcreigh: It doesn't provide isolation; not part of conversation.

• Melatonic: Thought whole point of microVM is isolation.

• LeBit: What do you mean by "It doesn’t provide isolation"?

• dbmikus: Restoring memory useful; but resuming with memory more trouble; losing ability to control state.

• nilleb: msb?

• verdverm: Keeping eye on Scion orchestrator.

• prng2021: Clarify use case; benefit over OpenAI Agents API.

• verdverm: you can run yourself, open source, can use any harness, any token vendor.

• aeon_ai: DAG?! Holy innovation.

• LeBit: Compare to kagent.

• 0xbadcafebee: Google makes it "googley" by building incompatible monolith with kitchen sink.

• sigbottle: Could explain general workflow; making VMs with proxmox; giving agent temporary scratchbox valuable? etc.

• agentdev001: Yes, but wrong layer; giving agent computer use (bash) is what folks after; temporary sandbox with control knobs and security bits is how you do that.

• maxgashkov: Compared to enterprise yours missing egress control and secrets management; if isolation watertight cripple agent's performance; then whack-a-mole.

• kstenerud: built sandbox with only host-side filtering proxy allowed; 99% traffic HTTP; no QUIC; etc.

• briga: No convergence; agentic ecosystem multiplying; everyone writing new framework; Google's ADK and AX promising; expect Google to maintain for years.

• QuiDortDine: Same Google that pulls plugs on a whim.

• verdverm: at least this one is pre-named for past tense when that day arrives /s

• briga: Dialogflow still alive after decade; marketing spent; could see lasting.

• bahmboo: Legit concern whenever see new Google initiative that feels like a wart.

• sigmoid10: Google dumped original agent framework on Linux foundation after realizing no one liked it; overzealous managers would go apeshit if dropped support fast; agentic tools lifetime measured in months.

• gnaman: Same Google that killed gemini cli and reintroduced as antigravity cli.

• fishfasell: Google+ would like a word.

• ozmaverick72: Google Wave waving.

• sssilver: Google Buzz buzzing.

• bethekidyouwant: Maintaining everything perpetually makes you #2.

• anjel: Yahoo would like a word.

• rolymath: Gmail for Your Domain etc.

• hendler: Google gears grinding.

• p_l: Gears superseded, not canceled.

• flir: Actually, I think it's drowning.

• egl2020: Google tries lots of stuff; doesn't always work out; sometimes give up; not complete loss; we get to see what didn't work; if valuable, someone else can pick up.

• 1dom: Negative impact of Google's approach far more than benefit of specific learning that idea doesn't make enough money.

• calgoo: Would never trust to use one of their productions in production.

• contentkraft: Wouldn't build anything on Google's products that might not exist in x years.

• therein: "Gosh, that Italian family at the next table sure is quiet"

• pigeons: Same as earlier; sarcasm.

• falcor84: Read as intentional sarcasm.

• fnord77: Everyone and grandma written new agent framework.

• klaushougesen1: ditto.

• ncruces: Tell us more about your grandma.

• ElFitz: Dog refactoring framework.

• avazhi: First time?

• nl: This sort of works; problem wanting many agents; separate sandbox per code operation.

• christophilus: Use git worktrees in single container.

• binsquare: Worktrees help agent work on different code repo; env variables wonky.

• dbmikus: Working on cloud VMs for agents; want permanent devbox VMs and per-task VMs; agent sandbox platforms tuned for latter; etc.

• sroussey: Why need multiple agents not one agent with multiple repos?

• srcreigh: Tasks are good scope for zero trust permissions.

• deviantintegral: Majority of funded agent sandboxes not for developers coding but for production applications wanting LLMs to do work; APIs better than terminal experience.

• lullabot sandbar etc.

• bitwize: Goal ticket in JIRA -> solution in production; agentic frameworks multiplying like JS frameworks; still haven't uncovered "React" of this space.

• ngruhn: Ticket in JIRA -> solution production; often want agents to do tasks with no input ticket; output not code change.

• imtringued: Bash coding agents like pi.dev got things backwards with anti-minimalist bloated core tools; giving agent access to every command is detrimental.

• vidarh: As long as system regularly wiped; if not wiped can't measure output; pets vs cattle.

• oblio: Only sandboxing that works is default deny, like Tcl or Lua; especially autonomous agents.

• vidarh: Need build this thing flow; shifts bottleneck; need infrastructure around it; JIRA-to-production pipeline not interesting part.

• internet101010: Base layer converged on Kubernetes + MicroVM; if you mean how to interact with it and permissions, yeah agree.

• faizshah: Everyone has sandbox, registry, way to run agents; now figuring authorization, need full sandbox or workflow, specify agent prompt or control flow, coordinate many agents.

• Onavo: No sandbox needed if inference only; code execution useful for open-ended problems.

• IanCal: Need if agent can access internet and read files you don't want public.

• debazel: Easy to restrict contain AI agent if no terminal; restrict tools rather than sandbox whole env; need sandbox when providing bash or arbitrary code execution.

• hosteur: Access to read sensitive files and internet could lead to data exposures.

• debazel: Yes, but limiting read_file or http tool easier than sandboxing whole env.

• TeMPOraL: Do you actually need it, or fear you need it? realistic threat model for median developer/user? leaking grandma's recipes etc not likely.

• kstenerud: Forensics on compromised WP sites; used two agents: one with network access to collect evidence, one with everything except model endpoint cut off did analysis; second agent's input attacker-authored; sandbox restricts access to source data read-only; work dir transfers via patch/apply; restricted network means compromise can't go anywhere; second agent couldn't install PHP or contact CVE site; could write report; then pass to third agent with network access.

• threatofrain: Security by obscurity bet on weights; economic motivations insufficient; worked before; developments in ML calls to account debt.

• chickensong: Nothing wrong; you'll know when outgrown.

• fmbb: Where are revolutionary software products?

• vidarh: Revolutionary products depend on revolutionary ideas, not faster execution.

• chickensong: ChatGPT is good starting point; enable voice control ask robot to draw pelican riding bicycle; much wow.

• zulban: Stop FOMO; get useful work done.

• IceDane: No convergence, but lots of pseudo-scientific voodoo and overengineering.

• oblio: Wild enthusiasm, not much proof mass-agent anything + orchestration financially viable or useful.

• petesergeant: Outgrew making VMs with proxmox; wanted bring different skills/templates to different machines; share small number of credentials; different agents in different machines; different egress rules; wrote TUI and machinery on Docker/Podman.

• BatteryMountain: Live in terminal; no desktop apps; 20 terminals open; colleagues messy with workflow tools etc.

• pmontra: Working more in terminal typing English sentences; looks like smart adventure game UI from 80s.

• embedding-shape: Doing same replacing vscode for vim; three/four panes; codex running in container; git diffs; shelling; neovim.

• mgw: Need both permanent-ish VM and ephemeral sandboxes; VMs better for personal assistant work, GUI click-testing, investigating bugs; sandboxes better for resource isolation/security and graph of tasks.

• TeMPOraL: Not first mention of Dropbox; Dropbox best when just folder sync; downfall started killing most useful accidental feature; enshittification; now zero options for bullshit-free folder sync; techies have Syncthing.

• pmontra: Maybe legal office had word with marketing about risk of becoming publisher.

• TeMPOraL: Before CDNs; they may have decided can't afford to be one; after shutting down direct Public/ links, still useful as folder sync but lost market share as OneDrive/Google Drive became more broadly useful; Dropbox lost focus and tried failed pivots towards cloudification.

• jiaosdjf: General workflow for non-technical people building software: multiple tasks in same context window; repo mixed with old markdown etc.; 5 tools calling each other; test/deployment scripts are markdown skills; prefer ticketing system and isolated work trees.

• jgillich: Wrote program to spin up isolated rootless workspaces.

• Melatonic: microVM future but nothing wrong with solid proxmox.

• romanovcode: From their own example "Setting up a Python 3 environment" is best it can do.

• stabbles: Even simpler sandbox is separate user and home dir for LLM.

• SillyUsername: Using mastra-ai/mastra similar but workflow visibility and templates.

• For generic swarm, workflows not useful; may give this a try.

• nullbio: People can afford to run billions of concurrent agents?

• dbmikus: Not sure about billions; companies doing evals, RL, training create bursty agent workloads; best fit for AX vs individual dev teams.

• agentdev001: Example Moonshot (kimi) open sourced.

• zoltan: billions? who running BILLIONS of agents? tens, hundreds, maybe a couple thousand at a time? absolutely.

• dmix: Task declares container image, command, compute requests/limits, env vars; declares listeners task exposes and egress allowlist of hosts/ports sandbox may reach; use to restrict agent to LLM provider and Git host.

• Planning to buy linux mini-PC to run agents/code servers for more isolation; Codex/Claude Code let you run prompts on code over ssh (same with most IDEs) even on desktop apps.

• Wonder if new standard practice: work laptop and isolated agent box.

• Running access control and network whitelists maintenance challenge; easy to make mistakes.

• dbmikus: Think it will be, but you don't need standalone machine; if run inside VM can get safety and control over access/networks.

• Standalone machine nice if need more compute resources or always-on machine you can connect from laptop, phone, etc.

• Doesn't look like Google's AX is plug-and-play fit for running agents on computer you own, since requires setting up K8S cluster etc.

• Think needed is zero-setup combo of Tailscale and Firecracker.

• Trying to work towards that with my startup.

• srcreigh: Have 6 and ended up needing to use gaming PC for build server; think you could get by with 1 computer but needs pretty decent machine; between agents running tests, CI, docker image builds, average $400 mini PC won't cut it; many older mini PCs don't support KVM; some newer don't support AVX/mongodb.

• dmix: Might need full proper PC setup with test suite stuff; looking at vendor gmktec.com; AI mini-pc market but not full dev machine replacement.

• petesergeant: Running ~5 agents at time comfortably on $280 mini PC with 8GB; Docker containers, a couple have sidecar VMs they can own and run; no issue with load.

• justincormack: Depends on workload; building large Rust projects so only one can build and test at a time.

• dilyevsky: Developed similar framework for internal agents; intercepting all network I/O including LLM providers, HTTP, random TCP/UDP calls.

• weedfroglozen