I don't really like the oversubscription of agent pods though, as you can no longer trust the k8s pod identity as being from a singular workload. Haven't seen a solution to this for ax yet and it is a barrier to adoption for us.

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?

IMO, you want the flexibility to create either: (a) permanent devbox VMs, and (b) per-task VMs

Agent sandbox platforms tend to be tuned for the latter, which sometimes involves VMM hackery for fast boot, snapshotting VM filesystem and RAM, etc.

Some workflows are a lot simpler if the multiple agents share a VM. These are workflows where agents must share state. A simple one we have: making related changes in our public OSS repo and our private repo, and then testing the change.

And other times you want to split up the tasks onto isolated VMs so they don't interfere with each other (ie run two dev servers without database or port collisions).

I tweeted a bit about this (https://x.com/dbmikus/status/2099264325231771878) and had a little debate with folks about ephemeral vs persistent VMs for agents

[1]: https://github.com/gofixpoint/amika

Now the stuff people are coming up with is: how do you do authorization in this model? do you need a full sandbox all the time or can it be a workflow? how do you specify an agent is it a prompt or does it have some kind of control flow structure? How do you coordinate among many running agents?

I would say thats where we are now is there’s loads of people all solving the same problems a bit like when CoreOS, Kube etc. were all competing.

I've been working on https://lullabot.github.io/sandbar/latest/ which works with Proxmox for VMs (and lima for locals or regular linux hosts over ssh). There's a diagram in https://lullabot.github.io/sandbar/latest/why/#recommended-w... with what we're currently recommending. Though, after some feedback, I'm in the process of integrating a colleague's web-based review tool as it turns out many preferred fully reviewing locally instead of using draft PRs.

It's got some opinions in terms of default tools for our team and industry so it may not fit yours. Forgive some of the AI-isms in the docs, I want to get the UX and feature set to a solid place before doing a full review.

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.

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.

https://cloud.google.com/blog/products/ai-machine-learning/a...

Google has around 200,000 employees. They probably haven't heard of most things Google releases.

>A Model is not a model. It is a named model configuration: ...

Remember kids, a model is not a model.

We met quite a large number of customers in the last few months, and several teams inside Google, who are asking for a stack that runs on any cluster.

There are several reasons for a layer like this.

(a) Today, it's extremely hard to deliver large agentic applications to someone else's compute, and it kills adoption for products that need to run closer on customer data plane, e.g. large scale code scanning product.

(b) It's tedious to build systems that set up the environment, deal with networking policies, provide integrations for session storage, memory curation, skills retrieval and mounting, etc while all you want to do is to focus on building applications.

(c) People want a truly transparent stack for compliance/auditing, and all other non functional capabilities most people don't usually think about until they have to.

The web page presents ax as a typical developer tool, but it's actually not for developers.