I haven't paid super close attention to Orbs, but I also build an agent runtime + orchestration layer on top of remote VMs (https://github.com/gofixpoint/amika). I do think it's smart marketing to name the concept. And for coding agents, there's a lot of annoying fiddly stuff you have to do to get the experience to work well:
1. auto-refresh base VM snapshots with latest delta of git commit changes
2. extend the VM lifetime when it receives an interaction (chat, HTTP request, etc.) and sleep it when inactive
3. oauth refresh of MCP servers, coding agent subscriptions, etc.
4. support inter-VM and communication for agents and exec commands
5. keeping track of agent work across VMs
That said, I think it's important to not hide the VM and computer from the agents. The user should have total control to put 1 or more agents on a VM, to make VMs ephemeral or permanent, to manage the network access of VMs, etc. It's basically a networking + VM scheduling problem, for which there's a ton of prior art since the 90s (or earlier).
A few examples:
Many remote agents products have a "one agent per VM" restriction, but it's better to have N agents across M VMs. For example, I have agents work on a singular VM in parallel worktrees and then stack the worktrees at the end on that VM for the final change.
Just give me OpenSSH with normal SSH key management. Lets you manage VM access the same way we've done it since the 90s.
Connect VMs in a network topology: we build our VM/agent scheduling + remote control product inside itself, so we often test interactions between user, control plane, and sandbox(es). If you can directly control VM creation and lifecycle, it's easy to spin this structure up and let agents work across it.
I should be able to use whichever coding agents I want, connected to the VM. Whether that's OpenCode or Pi Web in the browser, or loading the VM into Cursor or Codex app, or using the TUI or sending messages to agent(s) via API.
A few examples:
Many remote agents products have a "one agent per VM" restriction, but it's better to have N agents across M VMs. For example, I have agents work on a singular VM in parallel worktrees and then stack the worktrees at the end on that VM for the final change.
Just give me OpenSSH with normal SSH key management. Lets you manage VM access the same way we've done it since the 90s.
Connect VMs in a network topology: we build our VM/agent scheduling + remote control product inside itself, so we often test interactions between user, control plane, and sandbox(es). If you can directly control VM creation and lifecycle, it's easy to spin this structure up and let agents work across it.
I should be able to use whichever coding agents I want, connected to the VM. Whether that's OpenCode or Pi Web in the browser, or loading the VM into Cursor or Codex app, or using the TUI or sending messages to agent(s) via API.