3 ms·
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)
by dbmikus 5d ago
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 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 https://github.com/gofixpoint/amika
- sroussey 5d agoWhy would you need multiple agents and not one agent with multiple repos?
- srcreigh 5d agoTasks are a good scope for zero trust permissions
- dbmikus 5d agoFor my example where I modify both the OSS and private repos, I sometimes have one agent coordinate both changes (maybe with subagents), or if the work is modular and separate, I have disjoint agents do the work separately. That said, most of the time, I only want an agent to work in one repo. I could give it multiple repos at once and instruct it to work in just one, but that risks it forgetting my instructions and it can load more context into the agent's window. I think my main point was to have flexibility about the topology of VMs, repos, and agents.