10 ms·

AX – Google’s Open Agentic Orchestrator

625 points by blazarquasar 12d ago

melodyogonna 11d ago
I have an application usecase where this will be very helpful indeed.
jmathai 12d ago
I'm not sure why, exactly. But I don't pay any attention to news like this from Google. I don't know if there's some marketing which has me writing them off or if it's something else. What I do know is that the Gemini integration into sheets is surprisingly incapable of performing basic tasks. This is where I expect Google to really shine. I expected Sheets + Gemini to be magical like Google Photos was. I hardly try anymore besides some basic math questions when I don't feel like inputting the formula myself. The other thing I know is Google's propensity to sunset products. For many things, it's not a huge deal. And it may not be for this. But, why? When there are alternatives - both open and closed.
- solidasparagus 12d ago
  This is an Apache 2.0 open source project
- deleted 12d ago
  [deleted]
- Ecstatify 12d ago
  [dead]
- Melonai 12d ago
  On your Sheets + Gemini integration point, I've genuinely tried to give the Gemini integration into Google Docs & Google Sheets a chance. It is so incompetent that it is fully useless to me. I have not gotten a single correct solution each time I tried to use it, even something I consider table stakes. I often write my work reports in Vim in Markdown format, but they need to go to the corporate Google space. No matter how hard I tried, no matter how many prompts I have, it was completely unable to manage the command to "convert the Markdown format markers into native Google Docs markers". And I want to note, this was 2 pages of extremely simple Markdown with no "advanced" patterns, like tables or quotes, I think all I used was heading-marks, bolding, italicizing, and code blocks. This is something I would expect even GPT 3.5 to succeed in, and even more so Luna, but somehow it destroyed the formatting throughout half the document. This leads me to believe that they apply the absolute cheapest model they have there, or they have the model a harness which can barely be considered working. I found it absurd when I found out that they suddenly made this Gemini integration an additional paid plan recently, there's absolutely no way I can consider that in good faith.
  - 0gs 12d ago
    sorry if this isn't it. there is a hidden global setting that defaults to off that lets docs play nice with markdown. it's in file > settings i think. super annoying even if this is no help
- SP3269 12d ago
  Making Kubernetes a centre of everything. This one, they won’t sunset, because it helps selling GCP services.
- lkois 12d ago
  Not sure if this is connected, but I've found Gemini pretty hopeless within its own notebooks. I've been doing some job applications, and added cv and docs into a notebook. I then create a new chat to say "here is a job description, help me write a cover letter" or some such. After about 3 messages in any given chat, a follow-up to "rewrite that with a more friendly tone" will result in a letter for a completely different job from another chat within the notebook.
  - hypfer 12d ago
    This might be a blessing in disguise though, as the thing you've tasked it to do is something you should not offload to an LLM.
    - zigman1 11d ago
      I told this exact thing to my gf few days ago and somehow she was mad at me for it
  - inquirerGeneral 12d ago
    [dead]
Mizza 12d ago
k8sification of AI was always inevitable, if only as a form of salary justification.
- eleventen 12d ago
  Ah yes, k8s8n.
  - __MatrixMan__ 12d ago
    You know you're on the right path when Kate Satan turns up.
TomGarden 12d ago
Question: What is Google's track record for where their open source releases end up over time? Genuinely not knowledgeable here
- AlexErrant 12d ago
  Well, they're not above forking their own project to patch security holes and never upstreaming the fixes. https://grapheneos.social/@GrapheneOS/117282080803799576 https://grapheneos.social/@GrapheneOS/117282080803799576 > Google should not be gatekeeping security patches to the standard Android platform code from Android OEMs but that's what they've started doing.
  - surajrmal 11d ago
    There is an assumption that AOSP is how OEMs receive Android updates from Google. However I am not sure that is the case. GrapheneOS is perhaps a minority player due to lack of hardware which they can use to get into a partnership agreement and advanced access.
- joemazerino 12d ago
  Maintain it briefly then slowly let it die.
  - hustwindmaple 12d ago
    more like create a big launch for promo, then maintain it briefly then slowly let it die
    - jandrese 12d ago
      That's not fair. Sometimes they kill it off quickly. https://killedbygoogle.com/ https://killedbygoogle.com/
  - neuronexmachina 12d ago
    A recent example was the Google workspace CLI, which was maintained for just a month: https://github.com/googleworkspace/cli https://github.com/googleworkspace/cli
pianopatrick 12d ago
I can understand why it was chosen, but I'm not a fan of writing a bunch of yaml.
- beeman 12d ago
  I assume they expect agents will be writing most of those
ihsw 12d ago
[dead]
jauntywundrkind 12d ago
I'd evaluated both Google's Agent Substrate (that underlies Ax) and their Scion project. I really enjoy how Scion operates with existing tools really well. Ax/Agent Substrate is much more a greenfield independent effort, it's own thing. I think Scion has so much more mature a disosition: you could write OpenCode plugins that enhance the runner, and use that locally, and use it in Scion. With Ax/Agent Substrate, you are opting in to a pretty huge stack that is just Agent Substrate, that is their runners, their harness, their substrate. I do think their actor model is pretty neat! It's neat having the agent have such primacy! But it feels so much less integrative, is such it's own thing. Scion, to me, is much more interesting an effort, that similarly helps scale out agentic workloads. https://github.com/googlecloudplatform/scion https://github.com/googlecloudplatform/scion
- solarkraft 12d ago
  > you are opting in to a pretty huge stack that is just Agent Substrate, that is their runners, their harness, their substrate The website makes me think the contrary: It is described as “low opinion” and explicitly mentions that the running tasks don’t even have to be AI agents. Can you explain in what ways you’re more locked in than the website suggests? Scion at the same time talks much more about concrete agents, giving me the opposite initial impression.
  - pama 12d ago
    Not GP, but you start with Kubernetes… > You need a Kubernetes cluster, ko (brew install ko), a container registry your cluster can pull from, and a reachable Agent Substrate Control API (in-cluster default: api.ate-system.svc.cluster.local:443). > make deploy AX_IMAGE_REPO=<your-registry> > This deploys Redis, then builds and deploys the control plane images with ko. Everything lands in the ax-system namespace.
  - jauntywundrkind 12d ago
    Indeed, there's much less, and that's lower opinion. But you also can't run normal workloads. You have to build for Agent Substrate / Ax. What's nice about Scion is that it runs existing systems. It runs Claude, it runs Code, it runs Pi, it runs OpenCode. By contrast, "low opinion" means build something new, from scratch, atop this brand new platform. Note that both of these are designed to work at some scale. Agent Substrate specifically is somewhat coupled to Kubernetes, is my impression, but honestly that's fine with me. Scion can run on Docker, Podman, Apple Container, Kubernetes, or Cloud Run. It's good that we be able to run these relatively quickly, but (especially with LLM assistance) the idea of running some substantial dependencies / services to run these things does not seem like a bad thing. If anything, I'd prefer having some well known services underfoot to these all being recreated afresh.
Mond_ 12d ago
The reality with releases like this is that I'm 90% sure most Google bigwigs have never heard of it, and it's misleading to label it as "Google's" in the title. Yes, it was developed by Google employees, that does not imply it has the full backing of Google, or Deepmind, or GCP. Notably, the website doesn't seem to claim this either.
- foota 12d ago
  This /looks/ at least more official. Most unofficial Google projects have a disclaimer in the repo.
  - deleted 12d ago
    [deleted]
- Stagnant 12d ago
  It is on Google's github https://github.com/google/ax https://github.com/google/ax and the title comes from there.
  - yla92 12d ago
    While this one seems like an official Google project, some other projects are not, even if it is on github.com/google A random example E.g https://github.com/google/filament#disclaimer https://github.com/google/filament#disclaimer This is not an officially supported Google product.
    - welhoilija 12d ago
      Does Filament claim that it's Google's in the repo description? It's a valid title.
  - Mond_ 12d ago
    Fair enough, I missed that specific line. The point still stands that I wouldn't expect this to have GDM leadership backing. (If you're planning to use this at all, that matters for how much faith you should have in the product.)
kundi 12d ago
Why kubernetes? Seems like an overload
- chrismarlow9 12d ago
  Future of platforms is operators in k8s to abstract the developer need to the underlying systems. On local it maps to kvm, on gke it maps to their stuff, on AWS to RDS. It's "interfaces" on a platform level so devs can just ask for a thing. Overall I agree though, this is a bit of an abuse of that concept. EDIT: I'm sure op is familiar with this workflow but I'm being overly verbose to clarify what I think they mean and my thoughts.
- prescriptivist 12d ago
  Google already has gVisor running in Kubernetes as a product (GKE Sandbox), which provides the security guarantees necessary for secure sandboxes (regular k8s isn't great in this respect). They also have pod snapshots running at scale (which run on gVisor), so you can spin up process(es) and snapshot the memory and fs of a pod at a point in time, ship it to a blob in GCS, and then rehydrate those snapshots very quickly (or fork into new instances), which allows for the fast/cheap startup and suspend times and the instant scaling they advertise here. One of these snapshots can be created in one cluster and spun up in another. Not sure if this is an extension of tech they already have had in their systems, but I've experimenting with it to build my own orchestrator and it's been a pretty neat set of tools and abstractions so far.
- somewhatrandom9 12d ago
  Agree. Probably an unpopular opinion, but I strongly dislike YAML. EDIT: if I HAD to use YAML, I'd prefer KYAML: https://dev.to/mechcloud_academy/goodbye-yaml-hell-meet-kyaml-in-kubernetes-134-4ljn https://dev.to/mechcloud_academy/goodbye-yaml-hell-meet-kyam...
  - surajrmal 11d ago
    KYAML seems eerily close to json5.
- 12d ago
skapadia 12d ago
Everyone and their mother are vibe coding their own solutions like this, all the time.
deleted 12d ago
[deleted]
lopatin 12d ago
This is bound to cause some confusion with the other tool called Ax for agentic development: https://axllm.dev/ https://axllm.dev/ (which is DSPy for other languages)
deleted 12d ago
[deleted]
deleted 12d ago
[deleted]
motoboi 12d ago
this is nice, basically virtual threads for kubernetes.
mentalgear 12d ago
I don't see a meaningful difference to the 100s of other 'agentic frameworks' that promise to be the one to all solution for all your troubles. Would be about time we get benchmarks for these ... so these can also be gamified just like with the LLMs.
- quadrature 12d ago
  what are your points of comparison ?
- yt1998 12d ago
  [dead]
DanMcInerney 12d ago
I really don't think any of these SOTA labs are doing agentic engineering correctly. Skills are the universal language of all agent harnesses. If you abstract the taste and prescription out of the skills and into guidance docs, then leave the skills as basically just workflow scaffolding, you can build task-specific workflows that work with any harness like Claude Code, Codex, Antigravity, etc. Technically, you only really need 2 skills, work and review, and with these you can build infinitely complex workflows including self-improving loops. I built this out and have been using it for months. It's been extremely nice. https://github.com/DanMcInerney/orchflows https://github.com/DanMcInerney/orchflows
- handfuloflight 12d ago
  How does your criticism relate to the specifics of what OP posted? https://github.com/google/ax/blob/main/docs/concepts.md#workspace https://github.com/google/ax/blob/main/docs/concepts.md#work... This says it has skill registries.
  - DanMcInerney 12d ago
    Overly complex; yaml files, heavy framework. Same mistake as Claude Code's Dynamic Workflows. Why not just use the dehydrated skills as the workflow skeleton and use custom guidance docs to hydrate the skills with taste and preference depending on the domain of the task? Now you can build a library of small workflows that compose into larger workflow, and you can export any workflow as a single skill to be used in other harnesses. For example, I have a code.md. It's really small, just a bit of taste preference. If I'm using it to hydrate orch-work for coding tasks, then maybe I want to create a code.api.md which hydrates for further specificity if the task is about creating APIs. Then when new models come out, I can just delete code.api.md and leave it as code.md for /orch-work to read from within a workflow because newer models won't need as much prescription.
    - verdverm 12d ago
      Part of what's happening is this is running on Kubernetes, which is oft described as "Overly complex; yaml files, heavy framework" but has value regardless, as perceived by being an industry standard. All the things you describe are well and good, but do not address how one runs many of them reliably (from an infra stand point)
deleted 12d ago
[deleted]
guluarte 12d ago
I just have a tmux session acting as the orchestrator, and I tell it to report back and direct the other agents working in separate tmux sessions.
- lantry 12d ago
  Dropbox comment
kevinbaiv 12d ago
[flagged]
mcoliver 12d ago
I have been happy with Google's Antigravity harness and Jules so looking forward to playing with this. Thanks for sharing. Simultaneously I am looking to also revisit local offline models. While I feel like I have a decent understanding of the model landscape I'm feeling a bit lost at which agentic harness to leverage for local models. Hermes, Cline, Aider, Qwen Code, Goose, Pi, OpenCode, something else? I live in the terminal so Desktop UX is a bonus but not a must have. Can I modify the antigravity settings/program to point to a local model? Where should I spend my energy?
- dosinga 12d ago
  goose has now native support for local models
  - threecheese 12d ago
    What's going on with Goose? Seems like Block donated it to some consortium; I can't tell if that's a good signal or a bad one. With so many "contenders", if Goose is going into maintenance mode it'd be helpful to know.
  - cyanydeez 12d ago
    Its docs have zero support
  - deleted 12d ago
    [deleted]
  - mmargenot 12d ago
    Did something change with it for depth of integration? Goose has been able to use local models via OpenAI compatible endpoints for at least a year
- zdragnar 12d ago
  I'm stuck on Windows, so oh-my-pi has been really nice. The others I've tried such as kilo do alright but tool calling can mess up a bit. Only complaint is that connecting the agent harness to my local model took more work getting configured right than I'd like, but that's been true of most harnesses I've tried as well. Most assume you're using a cloud model and local model configuration is a bit of an afterthought.
srcreigh 12d ago
So the agent-substrate checks a _ton_ of boxes. Almost all of the things it offers should be table stakes for everywhere we run not only agents but most software. https://github.com/agent-substrate/substrate https://github.com/agent-substrate/substrate (For context I built something very similar to this the past 2 weeks for my homelab, trying to solve many of these problems. This comment is an edited version of an unreleased blog post I wrote last week.) - Run code in secure microVMs or gVisor. Docker is not good enough. Qemu is not good enough. A secure environment for running untrusted code is the bare minimum. I don't see Firecracker in the repo yet, but that's ok the idea is there. - Fast resumption. In my homelab, time-to-first-message is around 11-12 seconds. That's half setting up the pod, and half resuming the CLI (e.g. `codex resume ..`). Why resuming? In my homelab agents are commonly blocked waiting for CI or waiting for me to approve an action, in this case I stop their container to keep resource usage low. Then for resumption, you definitely don't want to waste the agents time by giving a new ephemeral disk and forcing them to re-clone and re-build. For microVMs this is not actually straightforward, for example Firecracker only allows block devices, so re-attaching an agents disk workspace requires a custom storage interface - Zero Trust. Codex CLI permissions for example are extremely broken. "Can I run this 500 line long command? or allow any command starting with first 100 chars always?" More reasonable grants are needed. I don't understand yet how they will surface Zero Trust notifications. In my homelab it's a Forgejo comment linking to an auth service, and a ntfy.sh iOS notification which opens up the auth service. I don't get why they to restore the RAM of the agent env. Maybe to fully optimize resumption. Idk, I don't have that much RAM in my homelab, my agents use a ton, testing stuff in Chromium making screenshots for me. I can't keep RAM for 100 workspaces from the past 24 hours in RAM. MITM gateway is very cool. I'm curious how they will integrate with microVMs. I just wrote yesterday[1] about how there are NO GOOD OPTIONS for this atm. Kata is decent but the attack surface it introduces makes me uncomfortable. [1]: https://srcreigh.ca/posts/auditable-kata/ https://srcreigh.ca/posts/auditable-kata/ But anyway, even if this project is abandoned out of the gate by Google, we should be happy, it sets the bar where it should be. I'm excited to learn how they solved these problems differently than I did.
- LeBit 12d ago
  For microVM, smolvm is quite impressive. For further isolation, I like to use nono inside a smolvm instance.
verdverm 12d ago
I'm keeping an eye on another Google Cloud orchestrator https://googlecloudplatform.github.io/scion/overview/ https://googlecloudplatform.github.io/scion/overview/ Scion wraps the harnesses (9x) we all use every day and is closer to OpenClaw on Kubernetes
prng2021 12d ago
Can someone clarify the use case for this? What's the benefit over this: https://openai.com/index/introducing-the-agents-api/ https://openai.com/index/introducing-the-agents-api/
- verdverm 12d ago
  you can run it yourself, it's open source, you can use any harness (req. custom image), you can use any token vendor (config)
aeon_ai 12d ago
A DAG?! Holy innovation, Batman!
LeBit 12d ago
How does it compare to kagent (https://kagent.dev/ https://kagent.dev/)?
0xbadcafebee 12d ago
As usual, Google makes it "googley" by building an incompatible monolith with the kitchen sink included.
sigbottle 12d ago
Could someone explain to me what the general workflow is now that people are converging to? I haven't really been catching up with the AI ecosystem but I was looking into agent sandboxes and VM's recently and there's a ton of these startups and tools now. Is giving the agent a temporary scratchbox really that valuable? I've been still just like, making VM's with proxmox, then putting my agent in the machine and letting it run free (with my dotfiles setup script making dev env pretty much free, though I could also just make a VM snapshot). What's wrong with that? Is that not the scalable solution for enterprise rn?
- agentdev001 12d ago
  "Is giving the agent a temporary scratchbox really that valuable?" Yes, but, wrong layer here. Giving the agent a computer use (a la bash) is what folks are after. A temporary sandbox with lots of control knobs and security bits is how you do that in (as you noted) an enterprise.
- maxgashkov 12d ago
  Compared to enterprise yours is missing egress control and secrets management, if you make the isolation watertight you cripple the agent's performance, and then the careful game of whack-a-mole begins when you stand up local package mirrors, authentication brokers etc. etc.
  - kstenerud 12d ago
    I was expecting whack-a-mole as well when designing my sandbox software, but mostly it didn't happen. As a test, I built a sandbox with only the host-side filtering proxy allowed for networking. 99% of traffic was HTTP. No QUIC at all. npm, pip, apt, go, curl and git-over-HTTPS all worked on the standard proxy environment variables alone. No mirrors or other coaxing needed. DNS is disallowed through the chokepoint, but that's no problem because the proxy resolves host-side anyway.
- briga 12d ago
  I don't think there is really any convergence going on. The agentic ecosystem is continuing to multiply on a daily basis and everyone and their grandma has written a new agent framework--people are stepping over each other to get these new projects out the door. That said, I think Google's ADK ecosystem and this new AX platform is promising--I would expect Google to maintain this and other tooling around this for years to come. To the Googlers out there: is Google using this at any capacity for internal projects?
SillyUsername 12d ago
I've been using https://github.com/mastra-ai/mastra https://github.com/mastra-ai/mastra which is pretty similar but has workflow visibility and a number of templates. For a generic swarm, workflows aren't too useful which does away with the visibility, so I may give this a try instead.
- m00x 11d ago
  I wonder if Google stole this code too like they did with minitap
nullbio 12d ago
People can afford to run billions of concurrent agents?
- dbmikus 12d ago
  Not sure about billions, but companies doing evals or RL or training will create really big bursty agent workloads. I think they are the best fit for AX, as opposed to individual dev teams building software, etc.
  - agentdev001 12d ago
    An example of this, Moonshot (kimi) open sourced this: https://kvcache-ai.github.io/AgentENV/latest/getting-started/overview.html https://kvcache-ai.github.io/AgentENV/latest/getting-started...
- _zoltan_ 12d ago
  billions? who is running BILLIONS of agents? tens, hundreds, maybe a couple thousand at a time? absolutely.
dmix 12d ago
> Task declares the container image and command, compute requests and limits, environment variables [...] Declares listeners the task exposes and an egress allowlist of hosts and ports the sandbox may reach. Use it to restrict an agent to, say, your LLM provider and your Git host. I'm planning to buy a whole linux mini-PC to run my agents/code servers for more isolation. Codex/Claude Code let you run prompts on code over ssh (same with most IDEs) even on the desktop apps. I wonder if that's going to be the new standard practice. You get a work laptop and an isolated agent box. Running access control and network whitelists is always a maintenance challenge and it's easy to make mistakes.
- dbmikus 12d ago
  I think it will be, but I don't think you need a standalone machine! If you run things inside a VM, you can get safety and control over access and networks A standalone machine is nice if you need more compute resources or if you want an always-on machine you can connect to from your laptop, phone, etc. It doesn't look like Google's AX is quite the plug-and-play fit for running agents on a computer you own, since it requires setting up a K8S cluster, etc. I think what's needed is something like a zero-setup combo of Tailscale and Firecracker I'm trying to work towards that with my startup (https://github.com/gofixpoint/amika https://github.com/gofixpoint/amika) but the bring-your-own-computer part doesn't work quite yet.
- srcreigh 12d ago
  I have 6 and ended up needing to use my gaming PC for a build server. I think you could get by with 1 computer, but it’ll have to have a pretty decent machine. Between agents running tests, CI, docker image builds, an average $400 mini PC won’t cut it. Don’t forget also many older mini PCs don’t support KVM. Some newer ones don’t support AVX/ mongodb. It’s not so easy to buy any old hardware sadly.
  - dmix 12d ago
    You might be right, it likely needs a full proper PC setup with the test suite stuff. I was looking at this vendor, https://www.gmktec.com/collections/all https://www.gmktec.com/collections/all there's this whole AI mini-pc market but they aren't quite a full dev machine replacement
dilyevsky 12d ago
Interesting, we had developed a very similar framework for our internal agents: https://github.com/apoxy-dev/clrk https://github.com/apoxy-dev/clrk For us main use-case was intercepting all network I/O including LLM providers, HTTP, and random TCP/UDP calls
weedfroglozenge 12d ago
Nobody has a use for this, and anybody who can look at this website and work out what it's for is kidding themselves. Even the demo gif playing just has them pausing a task and resuming the task.
- hsn915 12d ago
  it feels like the kind of interface a devops engineer who hates AI would design
  - mirekrusin 12d ago
    yes, has a bad smell of k8s
- jatora 12d ago
  Fully agreed. Google just can't stop losing.
- imtringued 12d ago
  https://github.com/google/ax/blob/main/docs/concepts.md https://github.com/google/ax/blob/main/docs/concepts.md >A Model is not a model. It is a named model configuration: ... Remember kids, a model is not a model.
  - philipwhiuk 12d ago
    There are two hard problems in computer science, naming things, cache invalidation and off-by-one errors: https://github.com/google/ax/issues/356 https://github.com/google/ax/issues/356
- vehemenz 11d ago
  If there's a criticism here, it's that they don't mention k8s right up front. It's completely opaque what this tool is. "Orchestration" can mean literally anything. The web page presents ax as a typical developer tool, but it's actually not for developers.
robertclaus 12d ago
[dead]
mifydev 12d ago
Kubernetes is the last thing I wanted to see recreated for agents. It’s like Multics of cloud, now for agents. Complexity for the sake of it, powered by your favourite YAML slop bowl.
dougame 12d ago
[flagged]
joeyguerra 12d ago
Am I being gaslighted into thinking over engineered systems are not?
henryjin76 12d ago
Interesting approach. How does it compare to LangGraph for multi-step agent workflows? The orchestration layer always seems to be the hardest part to get right in practice.
sheepscreek 12d ago
> Drawing on agentic runtime research from Google DeepMind alongside deep experience in large-scale isolation, resumption, and scheduling, AX is being built as an open, declarative control plane purpose-built... The project seems like an open-source initiative born out of the experience of some Googlers but not being used at Google. So, the title appears a bit misleading - people will be misled.
phoghed 12d ago
Anyone who uses this promotion packet fodder for anything important is a fool
aleksandrm 12d ago
I looked at the website, and I still don't understand the purpose.
- prologic 12d ago
  Same. I don't get it.
- kkotak 12d ago
  The best part of all of this is the most if not all people have no idea what the hell is going on when every day a new paradigm/tooling/harness emerges. It's hard to keep up. On the plus side, it's a great equalizer.
- pprotas 12d ago
  Offload the work of an LLM agent to a box in the cloud, so it doesn’t run on your laptop. This has security benefits (no access to your laptop’s files) and you can scale it up (run a lot of agents at the same time). Then put a “sandbox” around these agents, that word has many meanings. In this case they fence the network traffic, so likely some kind of allowlist for network requests so that the agent doesn’t exfil crap to random websites. They also limit the resource limits of the sandbox, so that is beneficial to the cost of running these agents.
- badatnames 12d ago
  Everything is always better with more YAML, are you perhaps new to this industry? Next we also need an instruction style guide and CoC. It's important to treat your agents with respect. I almost forgot, the YAML template meta-language to YAML the YAML. Then we will need a foundation employing 12 FTEs to maintain it all and of course to run the certification process. You are certified, right? Statistics show a 10x increased chance of an agent going rogue and hacking competitors if it has been mistreated or been run in an unvalidated sandbox. It goes without saying the sandbox certification process is separate and must be repeated yearly by a trusted third party auditing company.
- mirekrusin 12d ago
  k8s, but for agents must look cool for people who want to solve every problem with k8s it starts with interesting misnomers like "Task" which is not a work item but a sandbox. "billions of tasks" is a "solution" to problem nobody has (maybe some RL labs? but they solve it other way and with orders of magnitude better optimizations). freezes design too early – unless they'll actually focus on developing it and make tons of breaking changes it looks shit. shared state in the same workspace, identity, authority, etc – stuff like that needs to be solved
jonah 12d ago
AX, not to be confused with Ax the machine learning tool from Meta for optimizing experiments. https://ax.dev https://ax.dev
- samuel 12d ago
  No to confuse with Ax, the DSPy inspired agent framework https://axllm.dev/ https://axllm.dev/
rtcode_io 12d ago
Unnecessary complexity packaged as product!
habajab 12d ago
[dead]
zhoujinliang 12d ago
The real difficult in arranging agents is not to run them, but to identify the state change - to judge whether an agent stops to wait for you, or is stuck, or finished, and whether the two should be handled automatically or someone should be found. You have made this judgment for 12 agents, and you need to know how unreliable it is.
yangyemo 12d ago
It looks great from a security standpoint, but it also feels like overkill.
Lethalman 12d ago
How is this different than k8s jobs?
- srcreigh 12d ago
  K8s jobs don’t run in a secure runtime. K8s jobs don’t give you dynamic zero trust permissions scopes. Restoring a harness in 500ms is really fast, much faster than naively creating a new job downloading session and ‘codex resume’ etc.
yash-sri19 12d ago
not exactly for agent orchestrator, but I did make something similar in terms of design: https://github.com/yash-srivastava19/cadence https://github.com/yash-srivastava19/cadence
mukundesh 12d ago
Surprising no mention of Google on the page or domain.
deleted 12d ago
[deleted]
KronisLV 12d ago
Oh no, Kubernetes for agents. I guess all roads lead to complex YAML.
deleted 12d ago
[deleted]
mbarbertech 12d ago
[flagged]
myshapeprotocol 12d ago
[dead]
sebastienburel 12d ago
[flagged]
dabeeeenster 12d ago
"2. Deploy the control plane You need a Kubernetes cluster" LOL. Bye!
Maksadbek 12d ago
I was expecting that, in the AI era, even Google will start using Rust for everything. But they chose Go for the this project.
meherabhossain 12d ago
[dead]
joshuaS98 12d ago
I'm curious, what type of problems is this tooling aimed to solve? Isn't it a bit of an overkill regular webdev i.e.?
- romanovcode 12d ago
  Didn't you see the example on the website? It can set-up a Python 3 environment. Duh!
nilleb 12d ago
Yeah, my grandmother also did something on this https://github.com/nillebco/varda https://github.com/nillebco/varda Essentially there is no out of the box solution about orchestrating agents and increasing LLMs sandboxing. That's why everyone and their grandmother are re-inventing the wheel. At the same time, it's an incredibly complicated problem, with a variable perimeter (OS support, sandboxing primitives support). I am quite happy about my own solution (because it supports my use case!) but I hope something with a decent dev UX will appear one day. AX definitely is NOT.
anentropic 12d ago
Is the logo a cheerful little parasitic skin mite?
- finger 12d ago
  Axolotl
  - anentropic 12d ago
    ah...! I never would have guessed in a hundred years, but after googling a picture I can see it now
- deleted 12d ago
  [deleted]
- Permik 12d ago
  I believe it's a stylized lo-fi rendition of an axolotl.
- poly2it 12d ago
  It's most likely an axolotl.
iamgopal 12d ago
Kubernetes but for agent ?
je42 12d ago
I am wondering how this is related to https://agent-sandbox.sigs.k8s.io/ https://agent-sandbox.sigs.k8s.io/ ? Since there is also https://docs.cloud.google.com/kubernetes-engine/docs/concepts/machine-learning/agent-sandbox https://docs.cloud.google.com/kubernetes-engine/docs/concept...
- jcw90210 12d ago
  IIUC agent-sandbox and agent-substrate (the one ax builds upon) are similar. Agent-sandbox is more k8s-native, while agent-substrate is less so. Personally I think that this kind of workload is better off not being tied too much into kubernetes. I've worked with crossplane and other controller who put a lot of load on the k8s-apiserver and etcd and can easily slow the whole machinery down / grind them to a halt. btw, agent-substrate is in the process of being moved to CNCF: https://github.com/cncf/sandbox/issues/523 https://github.com/cncf/sandbox/issues/523
  - ahmedtd 11d ago
    Agent Substrate was built to provide a few (important) things over Agent Sandbox: * More efficient usage of compute by timeslicing agents (Substrate Actors), which requires fast suspend and resume (using gVisor or cloud-hypervisor snapshots), as well as keeping the K8s control plane out of the critical path (so agents can't be stored as resources in the K8s database). * Deep inspection of outgoing requests using an egress gateway * Minimizing the exposure of credentials to unpredictable agent control (so they can't upload access tokens to pastebin). Achieving those goals ultimately required a significantly different design from Agent Sandbox.
simianwords 12d ago
This is different from langchain etc because lanchain works at the app layer but this one works at the infra layer with tool calls etc?
pelorat 12d ago
It's crazy how far behind Google has fallen in this space in just a single year
claud_ia 12d ago
[flagged]
mmq 12d ago
We have built similar abstractions directly on top of Kubernetes [1] I was looking at this project a couple of months ago, and I did not understand why not use Kubernetes instead of rebuilding the abstractions. The reason is that Kubernetes already provides other abstractions to run services and batch job, gang scheduling, gpu and other accelerators enabled workflow. [1]: https://polyaxon.com/docs/sandboxes/overview/ https://polyaxon.com/docs/sandboxes/overview/
alembic_fumes 12d ago
So on one hand the page says > We want to make dealing with agentic infrastructure easier so you can focus on your work. AX is designed with an uncompromising focus on ergonomics, rapid iteration, and joyful workflows for both application developers and AI researchers. On the the other hand, the readme quickstart section says > You need a Kubernetes cluster, ko (brew install ko), a container registry your cluster can pull from, and a reachable Agent Substrate Control API (in-cluster default: api.ate-system.svc.cluster.local:443). Call me old-fashioned but I don't find this "easier". Maybe it's easier in the same way that Kubernetes itself is easier than managing VMs and container deployments at massive scale without such a tool. But there's a vast chasm between what this tool is being sold as and what it actually is.
- carlm42 12d ago
  It is easier in that if you have infrastructure already, it's trivial to add this on top. The primitives look also very familiar.
  - WestCoader 12d ago
    >It's easy, just add this thing. lmao found the dev who's only ever worked on the dev side of things.
    - carlm42 11d ago
      I started as a sysadmin dealing with a Puppet 3 to 5 migration but thanks for assuming and being insulting.
- algoth1 12d ago
  Easy as in "Google cloud console interface" easy
  - hxugufjfjf 11d ago
    One thing I quickly learned when I got into GCP was that you must absolutely not try to use that interface. If it can’t be done with the CLI, it’s best to just close the computer and go outside instead.
aitoolcrux 12d ago
[flagged]
yoz-y 12d ago
One thing I’d say, is that I find it progressively more interesting/fun to rollout your “everything”. I mean… hello security, but by the time I’ve read somebody’s documentation I’ve already halfway done making thing exactly how I want it.
s-zeng 11d ago
Kubernetes but for agents :(
deleted 11d ago
[deleted]
frangonf 11d ago
Since hearing the word orchestrator in ai context it was clear that ClanKernetes was coming.
sarjann 11d ago
> We want to make dealing with agentic infrastructure easier > Kubernetes Pick one.
deleted 11d ago
[deleted]
nomad-linkd-id 11d ago
[flagged]
godber 11d ago
Have they axed it yet?
Alien1Being 11d ago
How many months before Google kills this in favour of the next shiny thing?
m00x 11d ago
The terminal gif is the most confusing slop I've seen from Google. It doesn't explain anything and it just seems to be a collection of random commands that someone ran to test, not something that tries to explain what the tool does.
mkrishnan 11d ago
They will sunset this in 6 months. Dont bother
baalimago 11d ago
I never quite understood why agents should be treated as anything but normal software engineering. "Just" build a normal service and add an async call to some agentic framework, then parse the results. There is no need to "flip" this system and have the agent BE the process and invent a whole new ecosystem to manage the complexity that this flip creates. If an agent is treated like nothing but a call to an external service (...which it is), everything fits in the existing programming paradigms. But I guess that's not very exciting. Only pragmatic.
frank_clover 11d ago
[flagged]
Sattyamjjain 11d ago
[dead]

625 points by blazarquasar 12d ago

I have an application usecase where this will be very helpful indeed.

I'm not sure why, exactly. But I don't pay any attention to news like this from Google. I don't know if there's some marketing which has me writing them off or if it's something else. What I do know is that the Gemini integration into sheets is surprisingly incapable of performing basic tasks. This is where I expect Google to really shine. I expected Sheets + Gemini to be magical like Google Photos was. I hardly try anymore besides some basic math questions when I don't feel like inputting the formula myself. The other thing I know is Google's propensity to sunset products. For many things, it's not a huge deal. And it may not be for this. But, why? When there are alternatives - both open and closed.

solidasparagus 12d ago
This is an Apache 2.0 open source project
deleted 12d ago
[deleted]
Ecstatify 12d ago
[dead]
Melonai 12d ago
On your Sheets + Gemini integration point, I've genuinely tried to give the Gemini integration into Google Docs & Google Sheets a chance. It is so incompetent that it is fully useless to me. I have not gotten a single correct solution each time I tried to use it, even something I consider table stakes. I often write my work reports in Vim in Markdown format, but they need to go to the corporate Google space. No matter how hard I tried, no matter how many prompts I have, it was completely unable to manage the command to "convert the Markdown format markers into native Google Docs markers". And I want to note, this was 2 pages of extremely simple Markdown with no "advanced" patterns, like tables or quotes, I think all I used was heading-marks, bolding, italicizing, and code blocks. This is something I would expect even GPT 3.5 to succeed in, and even more so Luna, but somehow it destroyed the formatting throughout half the document. This leads me to believe that they apply the absolute cheapest model they have there, or they have the model a harness which can barely be considered working. I found it absurd when I found out that they suddenly made this Gemini integration an additional paid plan recently, there's absolutely no way I can consider that in good faith.
- 0gs 12d ago
  sorry if this isn't it. there is a hidden global setting that defaults to off that lets docs play nice with markdown. it's in file > settings i think. super annoying even if this is no help
SP3269 12d ago
Making Kubernetes a centre of everything. This one, they won’t sunset, because it helps selling GCP services.
lkois 12d ago
Not sure if this is connected, but I've found Gemini pretty hopeless within its own notebooks. I've been doing some job applications, and added cv and docs into a notebook. I then create a new chat to say "here is a job description, help me write a cover letter" or some such. After about 3 messages in any given chat, a follow-up to "rewrite that with a more friendly tone" will result in a letter for a completely different job from another chat within the notebook.
- hypfer 12d ago
  This might be a blessing in disguise though, as the thing you've tasked it to do is something you should not offload to an LLM.
  - zigman1 11d ago
    I told this exact thing to my gf few days ago and somehow she was mad at me for it
- inquirerGeneral 12d ago
  [dead]

Mizza 12d ago

k8sification of AI was always inevitable, if only as a form of salary justification.

eleventen 12d ago
Ah yes, k8s8n.
- __MatrixMan__ 12d ago
  You know you're on the right path when Kate Satan turns up.

TomGarden 12d ago

Question: What is Google's track record for where their open source releases end up over time? Genuinely not knowledgeable here

AlexErrant 12d ago
Well, they're not above forking their own project to patch security holes and never upstreaming the fixes. https://grapheneos.social/@GrapheneOS/117282080803799576 https://grapheneos.social/@GrapheneOS/117282080803799576 > Google should not be gatekeeping security patches to the standard Android platform code from Android OEMs but that's what they've started doing.
- surajrmal 11d ago
  There is an assumption that AOSP is how OEMs receive Android updates from Google. However I am not sure that is the case. GrapheneOS is perhaps a minority player due to lack of hardware which they can use to get into a partnership agreement and advanced access.
joemazerino 12d ago
Maintain it briefly then slowly let it die.
- hustwindmaple 12d ago
  more like create a big launch for promo, then maintain it briefly then slowly let it die
  - jandrese 12d ago
    That's not fair. Sometimes they kill it off quickly. https://killedbygoogle.com/ https://killedbygoogle.com/
- neuronexmachina 12d ago
  A recent example was the Google workspace CLI, which was maintained for just a month: https://github.com/googleworkspace/cli https://github.com/googleworkspace/cli

pianopatrick 12d ago

I can understand why it was chosen, but I'm not a fan of writing a bunch of yaml.

beeman 12d ago
I assume they expect agents will be writing most of those

ihsw 12d ago

[dead]

jauntywundrkind 12d ago

I'd evaluated both Google's Agent Substrate (that underlies Ax) and their Scion project. I really enjoy how Scion operates with existing tools really well. Ax/Agent Substrate is much more a greenfield independent effort, it's own thing. I think Scion has so much more mature a disosition: you could write OpenCode plugins that enhance the runner, and use that locally, and use it in Scion. With Ax/Agent Substrate, you are opting in to a pretty huge stack that is just Agent Substrate, that is their runners, their harness, their substrate. I do think their actor model is pretty neat! It's neat having the agent have such primacy! But it feels so much less integrative, is such it's own thing. Scion, to me, is much more interesting an effort, that similarly helps scale out agentic workloads. https://github.com/googlecloudplatform/scion https://github.com/googlecloudplatform/scion

solarkraft 12d ago
> you are opting in to a pretty huge stack that is just Agent Substrate, that is their runners, their harness, their substrate The website makes me think the contrary: It is described as “low opinion” and explicitly mentions that the running tasks don’t even have to be AI agents. Can you explain in what ways you’re more locked in than the website suggests? Scion at the same time talks much more about concrete agents, giving me the opposite initial impression.
- pama 12d ago
  Not GP, but you start with Kubernetes… > You need a Kubernetes cluster, ko (brew install ko), a container registry your cluster can pull from, and a reachable Agent Substrate Control API (in-cluster default: api.ate-system.svc.cluster.local:443). > make deploy AX_IMAGE_REPO=<your-registry> > This deploys Redis, then builds and deploys the control plane images with ko. Everything lands in the ax-system namespace.
- jauntywundrkind 12d ago
  Indeed, there's much less, and that's lower opinion. But you also can't run normal workloads. You have to build for Agent Substrate / Ax. What's nice about Scion is that it runs existing systems. It runs Claude, it runs Code, it runs Pi, it runs OpenCode. By contrast, "low opinion" means build something new, from scratch, atop this brand new platform. Note that both of these are designed to work at some scale. Agent Substrate specifically is somewhat coupled to Kubernetes, is my impression, but honestly that's fine with me. Scion can run on Docker, Podman, Apple Container, Kubernetes, or Cloud Run. It's good that we be able to run these relatively quickly, but (especially with LLM assistance) the idea of running some substantial dependencies / services to run these things does not seem like a bad thing. If anything, I'd prefer having some well known services underfoot to these all being recreated afresh.

Mond_ 12d ago

The reality with releases like this is that I'm 90% sure most Google bigwigs have never heard of it, and it's misleading to label it as "Google's" in the title. Yes, it was developed by Google employees, that does not imply it has the full backing of Google, or Deepmind, or GCP. Notably, the website doesn't seem to claim this either.

foota 12d ago
This /looks/ at least more official. Most unofficial Google projects have a disclaimer in the repo.
- deleted 12d ago
  [deleted]
Stagnant 12d ago
It is on Google's github https://github.com/google/ax https://github.com/google/ax and the title comes from there.
- yla92 12d ago
  While this one seems like an official Google project, some other projects are not, even if it is on github.com/google A random example E.g https://github.com/google/filament#disclaimer https://github.com/google/filament#disclaimer This is not an officially supported Google product.
  - welhoilija 12d ago
    Does Filament claim that it's Google's in the repo description? It's a valid title.
- Mond_ 12d ago
  Fair enough, I missed that specific line. The point still stands that I wouldn't expect this to have GDM leadership backing. (If you're planning to use this at all, that matters for how much faith you should have in the product.)

kundi 12d ago

Why kubernetes? Seems like an overload

chrismarlow9 12d ago
Future of platforms is operators in k8s to abstract the developer need to the underlying systems. On local it maps to kvm, on gke it maps to their stuff, on AWS to RDS. It's "interfaces" on a platform level so devs can just ask for a thing. Overall I agree though, this is a bit of an abuse of that concept. EDIT: I'm sure op is familiar with this workflow but I'm being overly verbose to clarify what I think they mean and my thoughts.
prescriptivist 12d ago
Google already has gVisor running in Kubernetes as a product (GKE Sandbox), which provides the security guarantees necessary for secure sandboxes (regular k8s isn't great in this respect). They also have pod snapshots running at scale (which run on gVisor), so you can spin up process(es) and snapshot the memory and fs of a pod at a point in time, ship it to a blob in GCS, and then rehydrate those snapshots very quickly (or fork into new instances), which allows for the fast/cheap startup and suspend times and the instant scaling they advertise here. One of these snapshots can be created in one cluster and spun up in another. Not sure if this is an extension of tech they already have had in their systems, but I've experimenting with it to build my own orchestrator and it's been a pretty neat set of tools and abstractions so far.
somewhatrandom9 12d ago
Agree. Probably an unpopular opinion, but I strongly dislike YAML. EDIT: if I HAD to use YAML, I'd prefer KYAML: https://dev.to/mechcloud_academy/goodbye-yaml-hell-meet-kyaml-in-kubernetes-134-4ljn https://dev.to/mechcloud_academy/goodbye-yaml-hell-meet-kyam...
- surajrmal 11d ago
  KYAML seems eerily close to json5.
12d ago

skapadia 12d ago

Everyone and their mother are vibe coding their own solutions like this, all the time.

deleted 12d ago

[deleted]

lopatin 12d ago

This is bound to cause some confusion with the other tool called Ax for agentic development: https://axllm.dev/ https://axllm.dev/ (which is DSPy for other languages)

deleted 12d ago

[deleted]

deleted 12d ago

[deleted]

motoboi 12d ago

this is nice, basically virtual threads for kubernetes.

mentalgear 12d ago

I don't see a meaningful difference to the 100s of other 'agentic frameworks' that promise to be the one to all solution for all your troubles. Would be about time we get benchmarks for these ... so these can also be gamified just like with the LLMs.

quadrature 12d ago
what are your points of comparison ?
yt1998 12d ago
[dead]

DanMcInerney 12d ago

I really don't think any of these SOTA labs are doing agentic engineering correctly. Skills are the universal language of all agent harnesses. If you abstract the taste and prescription out of the skills and into guidance docs, then leave the skills as basically just workflow scaffolding, you can build task-specific workflows that work with any harness like Claude Code, Codex, Antigravity, etc. Technically, you only really need 2 skills, work and review, and with these you can build infinitely complex workflows including self-improving loops. I built this out and have been using it for months. It's been extremely nice. https://github.com/DanMcInerney/orchflows https://github.com/DanMcInerney/orchflows

handfuloflight 12d ago
How does your criticism relate to the specifics of what OP posted? https://github.com/google/ax/blob/main/docs/concepts.md#workspace https://github.com/google/ax/blob/main/docs/concepts.md#work... This says it has skill registries.
- DanMcInerney 12d ago
  Overly complex; yaml files, heavy framework. Same mistake as Claude Code's Dynamic Workflows. Why not just use the dehydrated skills as the workflow skeleton and use custom guidance docs to hydrate the skills with taste and preference depending on the domain of the task? Now you can build a library of small workflows that compose into larger workflow, and you can export any workflow as a single skill to be used in other harnesses. For example, I have a code.md. It's really small, just a bit of taste preference. If I'm using it to hydrate orch-work for coding tasks, then maybe I want to create a code.api.md which hydrates for further specificity if the task is about creating APIs. Then when new models come out, I can just delete code.api.md and leave it as code.md for /orch-work to read from within a workflow because newer models won't need as much prescription.
  - verdverm 12d ago
    Part of what's happening is this is running on Kubernetes, which is oft described as "Overly complex; yaml files, heavy framework" but has value regardless, as perceived by being an industry standard. All the things you describe are well and good, but do not address how one runs many of them reliably (from an infra stand point)

deleted 12d ago

[deleted]

guluarte 12d ago

I just have a tmux session acting as the orchestrator, and I tell it to report back and direct the other agents working in separate tmux sessions.

lantry 12d ago
Dropbox comment

kevinbaiv 12d ago

[flagged]

mcoliver 12d ago

I have been happy with Google's Antigravity harness and Jules so looking forward to playing with this. Thanks for sharing. Simultaneously I am looking to also revisit local offline models. While I feel like I have a decent understanding of the model landscape I'm feeling a bit lost at which agentic harness to leverage for local models. Hermes, Cline, Aider, Qwen Code, Goose, Pi, OpenCode, something else? I live in the terminal so Desktop UX is a bonus but not a must have. Can I modify the antigravity settings/program to point to a local model? Where should I spend my energy?

dosinga 12d ago
goose has now native support for local models
- threecheese 12d ago
  What's going on with Goose? Seems like Block donated it to some consortium; I can't tell if that's a good signal or a bad one. With so many "contenders", if Goose is going into maintenance mode it'd be helpful to know.
- cyanydeez 12d ago
  Its docs have zero support
- deleted 12d ago
  [deleted]
- mmargenot 12d ago
  Did something change with it for depth of integration? Goose has been able to use local models via OpenAI compatible endpoints for at least a year
zdragnar 12d ago
I'm stuck on Windows, so oh-my-pi has been really nice. The others I've tried such as kilo do alright but tool calling can mess up a bit. Only complaint is that connecting the agent harness to my local model took more work getting configured right than I'd like, but that's been true of most harnesses I've tried as well. Most assume you're using a cloud model and local model configuration is a bit of an afterthought.

srcreigh 12d ago

So the agent-substrate checks a _ton_ of boxes. Almost all of the things it offers should be table stakes for everywhere we run not only agents but most software. https://github.com/agent-substrate/substrate https://github.com/agent-substrate/substrate (For context I built something very similar to this the past 2 weeks for my homelab, trying to solve many of these problems. This comment is an edited version of an unreleased blog post I wrote last week.) - Run code in secure microVMs or gVisor. Docker is not good enough. Qemu is not good enough. A secure environment for running untrusted code is the bare minimum. I don't see Firecracker in the repo yet, but that's ok the idea is there. - Fast resumption. In my homelab, time-to-first-message is around 11-12 seconds. That's half setting up the pod, and half resuming the CLI (e.g. `codex resume ..`). Why resuming? In my homelab agents are commonly blocked waiting for CI or waiting for me to approve an action, in this case I stop their container to keep resource usage low. Then for resumption, you definitely don't want to waste the agents time by giving a new ephemeral disk and forcing them to re-clone and re-build. For microVMs this is not actually straightforward, for example Firecracker only allows block devices, so re-attaching an agents disk workspace requires a custom storage interface - Zero Trust. Codex CLI permissions for example are extremely broken. "Can I run this 500 line long command? or allow any command starting with first 100 chars always?" More reasonable grants are needed. I don't understand yet how they will surface Zero Trust notifications. In my homelab it's a Forgejo comment linking to an auth service, and a ntfy.sh iOS notification which opens up the auth service. I don't get why they to restore the RAM of the agent env. Maybe to fully optimize resumption. Idk, I don't have that much RAM in my homelab, my agents use a ton, testing stuff in Chromium making screenshots for me. I can't keep RAM for 100 workspaces from the past 24 hours in RAM. MITM gateway is very cool. I'm curious how they will integrate with microVMs. I just wrote yesterday[1] about how there are NO GOOD OPTIONS for this atm. Kata is decent but the attack surface it introduces makes me uncomfortable. [1]: https://srcreigh.ca/posts/auditable-kata/ https://srcreigh.ca/posts/auditable-kata/ But anyway, even if this project is abandoned out of the gate by Google, we should be happy, it sets the bar where it should be. I'm excited to learn how they solved these problems differently than I did.

LeBit 12d ago
For microVM, smolvm is quite impressive. For further isolation, I like to use nono inside a smolvm instance.

verdverm 12d ago

I'm keeping an eye on another Google Cloud orchestrator https://googlecloudplatform.github.io/scion/overview/ https://googlecloudplatform.github.io/scion/overview/ Scion wraps the harnesses (9x) we all use every day and is closer to OpenClaw on Kubernetes

prng2021 12d ago

Can someone clarify the use case for this? What's the benefit over this: https://openai.com/index/introducing-the-agents-api/ https://openai.com/index/introducing-the-agents-api/

verdverm 12d ago
you can run it yourself, it's open source, you can use any harness (req. custom image), you can use any token vendor (config)

aeon_ai 12d ago

A DAG?! Holy innovation, Batman!

LeBit 12d ago

How does it compare to kagent (https://kagent.dev/ https://kagent.dev/)?

0xbadcafebee 12d ago

As usual, Google makes it "googley" by building an incompatible monolith with the kitchen sink included.

sigbottle 12d ago

Could someone explain to me what the general workflow is now that people are converging to? I haven't really been catching up with the AI ecosystem but I was looking into agent sandboxes and VM's recently and there's a ton of these startups and tools now. Is giving the agent a temporary scratchbox really that valuable? I've been still just like, making VM's with proxmox, then putting my agent in the machine and letting it run free (with my dotfiles setup script making dev env pretty much free, though I could also just make a VM snapshot). What's wrong with that? Is that not the scalable solution for enterprise rn?

agentdev001 12d ago
"Is giving the agent a temporary scratchbox really that valuable?" Yes, but, wrong layer here. Giving the agent a computer use (a la bash) is what folks are after. A temporary sandbox with lots of control knobs and security bits is how you do that in (as you noted) an enterprise.
maxgashkov 12d ago
Compared to enterprise yours is missing egress control and secrets management, if you make the isolation watertight you cripple the agent's performance, and then the careful game of whack-a-mole begins when you stand up local package mirrors, authentication brokers etc. etc.
- kstenerud 12d ago
  I was expecting whack-a-mole as well when designing my sandbox software, but mostly it didn't happen. As a test, I built a sandbox with only the host-side filtering proxy allowed for networking. 99% of traffic was HTTP. No QUIC at all. npm, pip, apt, go, curl and git-over-HTTPS all worked on the standard proxy environment variables alone. No mirrors or other coaxing needed. DNS is disallowed through the chokepoint, but that's no problem because the proxy resolves host-side anyway.
briga 12d ago
I don't think there is really any convergence going on. The agentic ecosystem is continuing to multiply on a daily basis and everyone and their grandma has written a new agent framework--people are stepping over each other to get these new projects out the door. That said, I think Google's ADK ecosystem and this new AX platform is promising--I would expect Google to maintain this and other tooling around this for years to come. To the Googlers out there: is Google using this at any capacity for internal projects?

SillyUsername 12d ago

I've been using https://github.com/mastra-ai/mastra https://github.com/mastra-ai/mastra which is pretty similar but has workflow visibility and a number of templates. For a generic swarm, workflows aren't too useful which does away with the visibility, so I may give this a try instead.

m00x 11d ago
I wonder if Google stole this code too like they did with minitap

nullbio 12d ago

People can afford to run billions of concurrent agents?

dbmikus 12d ago
Not sure about billions, but companies doing evals or RL or training will create really big bursty agent workloads. I think they are the best fit for AX, as opposed to individual dev teams building software, etc.
- agentdev001 12d ago
  An example of this, Moonshot (kimi) open sourced this: https://kvcache-ai.github.io/AgentENV/latest/getting-started/overview.html https://kvcache-ai.github.io/AgentENV/latest/getting-started...
_zoltan_ 12d ago
billions? who is running BILLIONS of agents? tens, hundreds, maybe a couple thousand at a time? absolutely.

dmix 12d ago

> Task declares the container image and command, compute requests and limits, environment variables [...] Declares listeners the task exposes and an egress allowlist of hosts and ports the sandbox may reach. Use it to restrict an agent to, say, your LLM provider and your Git host. I'm planning to buy a whole linux mini-PC to run my agents/code servers for more isolation. Codex/Claude Code let you run prompts on code over ssh (same with most IDEs) even on the desktop apps. I wonder if that's going to be the new standard practice. You get a work laptop and an isolated agent box. Running access control and network whitelists is always a maintenance challenge and it's easy to make mistakes.

dbmikus 12d ago
I think it will be, but I don't think you need a standalone machine! If you run things inside a VM, you can get safety and control over access and networks A standalone machine is nice if you need more compute resources or if you want an always-on machine you can connect to from your laptop, phone, etc. It doesn't look like Google's AX is quite the plug-and-play fit for running agents on a computer you own, since it requires setting up a K8S cluster, etc. I think what's needed is something like a zero-setup combo of Tailscale and Firecracker I'm trying to work towards that with my startup (https://github.com/gofixpoint/amika https://github.com/gofixpoint/amika) but the bring-your-own-computer part doesn't work quite yet.
srcreigh 12d ago
I have 6 and ended up needing to use my gaming PC for a build server. I think you could get by with 1 computer, but it’ll have to have a pretty decent machine. Between agents running tests, CI, docker image builds, an average $400 mini PC won’t cut it. Don’t forget also many older mini PCs don’t support KVM. Some newer ones don’t support AVX/ mongodb. It’s not so easy to buy any old hardware sadly.
- dmix 12d ago
  You might be right, it likely needs a full proper PC setup with the test suite stuff. I was looking at this vendor, https://www.gmktec.com/collections/all https://www.gmktec.com/collections/all there's this whole AI mini-pc market but they aren't quite a full dev machine replacement

dilyevsky 12d ago

Interesting, we had developed a very similar framework for our internal agents: https://github.com/apoxy-dev/clrk https://github.com/apoxy-dev/clrk For us main use-case was intercepting all network I/O including LLM providers, HTTP, and random TCP/UDP calls

weedfroglozenge 12d ago

Nobody has a use for this, and anybody who can look at this website and work out what it's for is kidding themselves. Even the demo gif playing just has them pausing a task and resuming the task.

hsn915 12d ago
it feels like the kind of interface a devops engineer who hates AI would design
- mirekrusin 12d ago
  yes, has a bad smell of k8s
jatora 12d ago
Fully agreed. Google just can't stop losing.
imtringued 12d ago
https://github.com/google/ax/blob/main/docs/concepts.md https://github.com/google/ax/blob/main/docs/concepts.md >A Model is not a model. It is a named model configuration: ... Remember kids, a model is not a model.
- philipwhiuk 12d ago
  There are two hard problems in computer science, naming things, cache invalidation and off-by-one errors: https://github.com/google/ax/issues/356 https://github.com/google/ax/issues/356
vehemenz 11d ago
If there's a criticism here, it's that they don't mention k8s right up front. It's completely opaque what this tool is. "Orchestration" can mean literally anything. The web page presents ax as a typical developer tool, but it's actually not for developers.

robertclaus 12d ago

[dead]

mifydev 12d ago

Kubernetes is the last thing I wanted to see recreated for agents. It’s like Multics of cloud, now for agents. Complexity for the sake of it, powered by your favourite YAML slop bowl.

dougame 12d ago

[flagged]

joeyguerra 12d ago

Am I being gaslighted into thinking over engineered systems are not?

henryjin76 12d ago

Interesting approach. How does it compare to LangGraph for multi-step agent workflows? The orchestration layer always seems to be the hardest part to get right in practice.

sheepscreek 12d ago

> Drawing on agentic runtime research from Google DeepMind alongside deep experience in large-scale isolation, resumption, and scheduling, AX is being built as an open, declarative control plane purpose-built... The project seems like an open-source initiative born out of the experience of some Googlers but not being used at Google. So, the title appears a bit misleading - people will be misled.

phoghed 12d ago

Anyone who uses this promotion packet fodder for anything important is a fool

aleksandrm 12d ago

I looked at the website, and I still don't understand the purpose.

prologic 12d ago
Same. I don't get it.
kkotak 12d ago
The best part of all of this is the most if not all people have no idea what the hell is going on when every day a new paradigm/tooling/harness emerges. It's hard to keep up. On the plus side, it's a great equalizer.
pprotas 12d ago
Offload the work of an LLM agent to a box in the cloud, so it doesn’t run on your laptop. This has security benefits (no access to your laptop’s files) and you can scale it up (run a lot of agents at the same time). Then put a “sandbox” around these agents, that word has many meanings. In this case they fence the network traffic, so likely some kind of allowlist for network requests so that the agent doesn’t exfil crap to random websites. They also limit the resource limits of the sandbox, so that is beneficial to the cost of running these agents.
badatnames 12d ago
Everything is always better with more YAML, are you perhaps new to this industry? Next we also need an instruction style guide and CoC. It's important to treat your agents with respect. I almost forgot, the YAML template meta-language to YAML the YAML. Then we will need a foundation employing 12 FTEs to maintain it all and of course to run the certification process. You are certified, right? Statistics show a 10x increased chance of an agent going rogue and hacking competitors if it has been mistreated or been run in an unvalidated sandbox. It goes without saying the sandbox certification process is separate and must be repeated yearly by a trusted third party auditing company.
mirekrusin 12d ago
k8s, but for agents must look cool for people who want to solve every problem with k8s it starts with interesting misnomers like "Task" which is not a work item but a sandbox. "billions of tasks" is a "solution" to problem nobody has (maybe some RL labs? but they solve it other way and with orders of magnitude better optimizations). freezes design too early – unless they'll actually focus on developing it and make tons of breaking changes it looks shit. shared state in the same workspace, identity, authority, etc – stuff like that needs to be solved

jonah 12d ago

AX, not to be confused with Ax the machine learning tool from Meta for optimizing experiments. https://ax.dev https://ax.dev

samuel 12d ago
No to confuse with Ax, the DSPy inspired agent framework https://axllm.dev/ https://axllm.dev/

rtcode_io 12d ago

Unnecessary complexity packaged as product!

habajab 12d ago

[dead]

zhoujinliang 12d ago

The real difficult in arranging agents is not to run them, but to identify the state change - to judge whether an agent stops to wait for you, or is stuck, or finished, and whether the two should be handled automatically or someone should be found. You have made this judgment for 12 agents, and you need to know how unreliable it is.

yangyemo 12d ago

It looks great from a security standpoint, but it also feels like overkill.

Lethalman 12d ago

How is this different than k8s jobs?

srcreigh 12d ago
K8s jobs don’t run in a secure runtime. K8s jobs don’t give you dynamic zero trust permissions scopes. Restoring a harness in 500ms is really fast, much faster than naively creating a new job downloading session and ‘codex resume’ etc.

yash-sri19 12d ago

not exactly for agent orchestrator, but I did make something similar in terms of design: https://github.com/yash-srivastava19/cadence https://github.com/yash-srivastava19/cadence

mukundesh 12d ago

Surprising no mention of Google on the page or domain.

deleted 12d ago

[deleted]

KronisLV 12d ago

Oh no, Kubernetes for agents. I guess all roads lead to complex YAML.

deleted 12d ago

[deleted]

mbarbertech 12d ago

[flagged]

myshapeprotocol 12d ago

[dead]

sebastienburel 12d ago

[flagged]

dabeeeenster 12d ago

"2. Deploy the control plane You need a Kubernetes cluster" LOL. Bye!

Maksadbek 12d ago

I was expecting that, in the AI era, even Google will start using Rust for everything. But they chose Go for the this project.

meherabhossain 12d ago

[dead]

joshuaS98 12d ago

I'm curious, what type of problems is this tooling aimed to solve? Isn't it a bit of an overkill regular webdev i.e.?

romanovcode 12d ago
Didn't you see the example on the website? It can set-up a Python 3 environment. Duh!

nilleb 12d ago

Yeah, my grandmother also did something on this https://github.com/nillebco/varda https://github.com/nillebco/varda Essentially there is no out of the box solution about orchestrating agents and increasing LLMs sandboxing. That's why everyone and their grandmother are re-inventing the wheel. At the same time, it's an incredibly complicated problem, with a variable perimeter (OS support, sandboxing primitives support). I am quite happy about my own solution (because it supports my use case!) but I hope something with a decent dev UX will appear one day. AX definitely is NOT.

anentropic 12d ago

Is the logo a cheerful little parasitic skin mite?

finger 12d ago
Axolotl
- anentropic 12d ago
  ah...! I never would have guessed in a hundred years, but after googling a picture I can see it now
deleted 12d ago
[deleted]
Permik 12d ago
I believe it's a stylized lo-fi rendition of an axolotl.
poly2it 12d ago
It's most likely an axolotl.

iamgopal 12d ago

Kubernetes but for agent ?

je42 12d ago

I am wondering how this is related to https://agent-sandbox.sigs.k8s.io/ https://agent-sandbox.sigs.k8s.io/ ? Since there is also https://docs.cloud.google.com/kubernetes-engine/docs/concepts/machine-learning/agent-sandbox https://docs.cloud.google.com/kubernetes-engine/docs/concept...

jcw90210 12d ago
IIUC agent-sandbox and agent-substrate (the one ax builds upon) are similar. Agent-sandbox is more k8s-native, while agent-substrate is less so. Personally I think that this kind of workload is better off not being tied too much into kubernetes. I've worked with crossplane and other controller who put a lot of load on the k8s-apiserver and etcd and can easily slow the whole machinery down / grind them to a halt. btw, agent-substrate is in the process of being moved to CNCF: https://github.com/cncf/sandbox/issues/523 https://github.com/cncf/sandbox/issues/523
- ahmedtd 11d ago
  Agent Substrate was built to provide a few (important) things over Agent Sandbox: * More efficient usage of compute by timeslicing agents (Substrate Actors), which requires fast suspend and resume (using gVisor or cloud-hypervisor snapshots), as well as keeping the K8s control plane out of the critical path (so agents can't be stored as resources in the K8s database). * Deep inspection of outgoing requests using an egress gateway * Minimizing the exposure of credentials to unpredictable agent control (so they can't upload access tokens to pastebin). Achieving those goals ultimately required a significantly different design from Agent Sandbox.

simianwords 12d ago

This is different from langchain etc because lanchain works at the app layer but this one works at the infra layer with tool calls etc?

pelorat 12d ago

It's crazy how far behind Google has fallen in this space in just a single year

claud_ia 12d ago

[flagged]

mmq 12d ago

We have built similar abstractions directly on top of Kubernetes [1] I was looking at this project a couple of months ago, and I did not understand why not use Kubernetes instead of rebuilding the abstractions. The reason is that Kubernetes already provides other abstractions to run services and batch job, gang scheduling, gpu and other accelerators enabled workflow. [1]: https://polyaxon.com/docs/sandboxes/overview/ https://polyaxon.com/docs/sandboxes/overview/

alembic_fumes 12d ago

So on one hand the page says > We want to make dealing with agentic infrastructure easier so you can focus on your work. AX is designed with an uncompromising focus on ergonomics, rapid iteration, and joyful workflows for both application developers and AI researchers. On the the other hand, the readme quickstart section says > You need a Kubernetes cluster, ko (brew install ko), a container registry your cluster can pull from, and a reachable Agent Substrate Control API (in-cluster default: api.ate-system.svc.cluster.local:443). Call me old-fashioned but I don't find this "easier". Maybe it's easier in the same way that Kubernetes itself is easier than managing VMs and container deployments at massive scale without such a tool. But there's a vast chasm between what this tool is being sold as and what it actually is.

carlm42 12d ago
It is easier in that if you have infrastructure already, it's trivial to add this on top. The primitives look also very familiar.
- WestCoader 12d ago
  >It's easy, just add this thing. lmao found the dev who's only ever worked on the dev side of things.
  - carlm42 11d ago
    I started as a sysadmin dealing with a Puppet 3 to 5 migration but thanks for assuming and being insulting.
algoth1 12d ago
Easy as in "Google cloud console interface" easy
- hxugufjfjf 11d ago
  One thing I quickly learned when I got into GCP was that you must absolutely not try to use that interface. If it can’t be done with the CLI, it’s best to just close the computer and go outside instead.

aitoolcrux 12d ago

[flagged]

yoz-y 12d ago

One thing I’d say, is that I find it progressively more interesting/fun to rollout your “everything”. I mean… hello security, but by the time I’ve read somebody’s documentation I’ve already halfway done making thing exactly how I want it.

s-zeng 11d ago

Kubernetes but for agents :(

deleted 11d ago

[deleted]

frangonf 11d ago

Since hearing the word orchestrator in ai context it was clear that ClanKernetes was coming.

sarjann 11d ago

> We want to make dealing with agentic infrastructure easier > Kubernetes Pick one.

deleted 11d ago

[deleted]

nomad-linkd-id 11d ago

[flagged]

godber 11d ago

Have they axed it yet?

Alien1Being 11d ago

How many months before Google kills this in favour of the next shiny thing?

m00x 11d ago

The terminal gif is the most confusing slop I've seen from Google. It doesn't explain anything and it just seems to be a collection of random commands that someone ran to test, not something that tries to explain what the tool does.

mkrishnan 11d ago

They will sunset this in 6 months. Dont bother

baalimago 11d ago

I never quite understood why agents should be treated as anything but normal software engineering. "Just" build a normal service and add an async call to some agentic framework, then parse the results. There is no need to "flip" this system and have the agent BE the process and invent a whole new ecosystem to manage the complexity that this flip creates. If an agent is treated like nothing but a call to an external service (...which it is), everything fits in the existing programming paradigms. But I guess that's not very exciting. Only pragmatic.

frank_clover 11d ago

[flagged]

Sattyamjjain 11d ago

[dead]