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?

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?

I'm working on something in the "cloud VMs for agents" space[1], so I have some battle scars and opinions!

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

Basically everyone has a sandbox of some sort to run agents inside. Everyone has a registry of some sort for tools. Everyone has a way of running agents inside a sandbox and giving it some tools.

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 wrote a little program to spin up isolated rootless workspaces: https://github.com/jgillich/tpd

Works pretty well for me but I haven't put any effort into promoting it

From what I've seen, the vast majority of agent sandboxes with funding aren't for developers to use when coding, but for production applications that want to have LLMs do work. It's just a different model - APIs are better than a great terminal experience for a coding harness.

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.

I have no idea, I just live in my terminal at this point, on linux. Don't use Visual Studio or Jetbrains products anymore at all. I use visual studio code to view the occasional diff and run sql queries. Other than that, zero desktop apps, just terminal & cli tooling. Its great! I have about 20 terminals open at any given time though. I have no idea how some of my colleagues stay productive as they are messing around with all these workflow tools, desktop apps etc.

For my workflow I need both, a permanent-ish VM and emphemeral sandboxes. Both have their place and pros and cons.

VMs are better for personal assistant work, GUI clicktesting, investigating bugs in your personal dogfooding dev instance and anything you haven‘t yet made repeatable and fast to set up.

Sandboxes are better when you need resource isolation or security and have a graph of tasks to work through. My agents often starve each other on one VM, so if they don‘t need any of the above it‘s just easier to isolate them.

Everyone is working in this area, including me [0], but either option really isn‘t that convenient to use yet. It‘s a bit of a „isn‘t Dropbox just FTP on a VM“ moment right now.

[0] https://github.com/madeinorbit/podium

My advice: stop your fomo. Just get useful work done.

The general workflow I have seen for non-technical people building software is something like:

- Do multiple tasks in the same context window / session, conflate different changes into the same prompt

- Repo mixed with old markdown files from previous tasks, excel and word docs and 300 playwright screenshots

- 5 tools all calling each other, test and deployment scripts are all markdown skills

Personally I prefer a ticketing system and isolated work trees

"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.

> What's wrong with that?

Nothing at all. You'll know when you've outgrown it.

> what the general workflow is now that people are converging to?

Graph-based workflows where agents pick up work as it becomes available, structured output, while you manage the work queue and outcomes. Maybe? IDK really, it's all moving quite fast.

This sort of works.

The problem is that you'll end up wanting to run 2 or 3 (or 20, 100, 10,000) agents at once and that gets very hard with a single VM.

There's also an argument that you should be using a separate sandbox for each code operation a LLM performs (or at least each set of related operations). That's even harder to do with conventional VMs.

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.

The goal is "ticket in JIRA -> solution in production" without human intervention. Right now agentic frameworks are multiplying to bring us closer to that solution like JavaScript frameworks did ~10y ago. We still haven't uncovered the "React" of this space yet, the one that business decides is good enough to standardize on.

> I've been still just like, making VM's with proxmox, then putting my agent in the machine and letting it run free

I outgrew this when I wanted to bring different sets of skills and templates to different machines, wanted to be able to share a small number of credentials, different agents in different machines, different egress rules etc. I wrote https://github.com/pjlsergeant/byre which gives you a TUI and some machinery for doing this easily on top of Docker or Podman.

There's no convergence, but there sure as hell is a lot of pseudo-scientific voodoo and overengineering going on.

[dead]

[dead]