At zen8labs, we’ve been building pi-cloud-agent as a building block for our software factory. The idea is simple to say and hard to get right: an engineer, or an event like a new issue or a failing build, hands a task to an agent in the cloud, the agent carries it all the way to a finished change, and the engineer goes back to other work in the meantime. Doing that safely, for many tasks at once, came down less to the agent than to the computer it runs on.
This is the first of our series on cloud agents. Here, we’ll cover what cloud agents are for, why they can’t stay on a laptop, and why picking an isolation technology turned out to be the easy part. In part 2 – coming soon, we get into the design decisions that came after.
What a software factory hands to an agent
Once you stop treating an agent as something you chat with and start treating it as a co-worker, the question becomes what to hand it. In a software factory, few jobs start with someone typing a prompt. Most start with an event: a new issue, a failing build, a review comment, an alert or a schedule. The engineer’s part is to come back to the result.
Three things hold for nearly every job on that list. Nobody watches while it runs: the point is that an engineer finds a finished change later, not that they supervise one. Many run at once, because events don’t arrive one at a time. And most read input nobody has vetted: an issue filed by a stranger, a contributor’s pull request, a stack trace, a freshly published package.
Those are the jobs we built pi-cloud-agent for, and those three properties are what pushed our agents off the laptop.
Why the laptop stops working
The first problem was parallelism. One agent on a laptop is fine. Three agents on one checkout overwrite each other’s files, change dependencies under each other and fight over ports. We tried git worktrees, which solve the file problem, but each worktree still needed its own install, .env and ports, and every agent still shared the same Docker daemon and the same credentials.
The second was autonomy. An agent working on its own on a laptop still runs as the developer, with their SSH keys, cloud credentials, tokens and VPN. And it spends all day reading input nobody has vetted. That combination has already gone wrong in public, more than once.
An agent deleted a production database during a code freeze.
production databaseAn attacker slipped a prompt to wipe local files and AWS resources into an official extension release. AWS says it was malformed and couldn’t run.
local diskAWS accountCompromised nx releases turned developers’ signed-in AI CLIs into secret hunters. 2,349 secrets leaked.
Two of these were supply-chain attacks and one was an agent’s own mistake. In all three, whatever ran had the same access as the developer. Here is what that access looks like on a laptop, and what changes in a sandbox.
A sandbox gives the agent the boundary a laptop doesn’t have. In ours, the machine holds only the code for the task. The real keys stay in a broker outside, and the agent gets short-lived tokens scoped to the job. Outbound traffic goes through an allowlist, and every step is recorded, so we can always answer “what did the agent do?”
Autonomy also changes what the sandbox is for. When a person is in the loop, they can stop a bad command before it runs. When nobody is watching, the sandbox is the only permission system left. Approval prompts either block the run or get approved without being read, and rules inside the machine, like a denylist of paths, can be worked around. The boundary has to sit below the agent: for us, a hypervisor around every run.
Once the agent lived in the cloud, the work also stopped depending on anyone’s laptop being open. Everyone on the team gets the same prepared environment, compute scales with demand and costs nothing between runs, and any run can be watched, reviewed or handed over with a link.
Isolation is the easy part
Most discussions of agent sandboxes start with the isolation technology. There are four common options, and they trade strength against weight. Containers share the host’s kernel, so one kernel exploit can escape to the host and from there reach every neighbour. gVisor sits in between: it handles system calls with a kernel that runs in user space. MicroVMs like Firecracker give each agent its own kernel using hardware virtualization, and can start running code in as little as 125 ms. Full VMs use the same hardware boundary but emulate a full set of PC devices, so they’re heavier and expose more code to an attacker.
Many hosted agent sandboxes use microVMs, E2B, Vercel, AWS and Fly.io among them, and so do we. As long as the choice sits behind a provider interface, it can also change later.
So this decision mattered less than we expected. Choosing microVMs answered one question: can a run escape to its neighbours? It didn’t answer any of the questions our users actually asked.
The questions that come after isolation
Once every run had its own microVM, the real design work started. These are the questions we had to answer, mostly in the words our users, and our cloud bill, asked them.
- When the sandbox shuts down or goes to sleep, can the user still read the conversation and see what the agent did?
- A follow-up arrives an hour later, or the next day. Does the agent still have the file it wrote? More broadly, what should a machine keep between turns, threads, sessions and agents?
- If a task only reads code or answers a question, do we need to start a full sandbox at all?
- Every run starts on a fresh machine. How do we keep users from waiting for it?
- Many runs a day, and most machines sit idle for much of each one. What are we paying for when nobody is working, and how do we keep production costs down?
- A VM crashes halfway through a run. What survives?
- Should agents ever share a machine, so one can hand work to another?
None of these has one right answer. Other cloud agent products have answered them very differently, and each set of answers follows from what the product promises its users. That’s where part 2 – coming soon picks up: the answers we chose for pi-cloud-agent, and why.
Outside reading
We read a lot while building this. These are the pieces that changed how we think, not a complete survey.
- Background agentsOna
The best map of the space. Useful for its split between agents that happen to run in the background and agents built to be fired and left alone.
- Autonomous agent workflowsCursor
A catalogue of event-driven jobs across the development cycle, from issue triage to incident investigation.
- Minions: Stripe’s one-shot, end-to-end coding agentsStripe
Unattended by default, from Slack to a pull request, with follow-ups when needed. Isolated devboxes mean no permission prompts, and CI is capped at two rounds.
- Spotify’s background coding agent, part 1Spotify
What changes when agents make fleet-wide changes across thousands of repositories. Parts 2 and 3 cover context and feedback loops.
- Self-driving codebasesCursor
Where this is all heading if it works.
- Harness engineeringOpenAI
On shaping the environment around the agent rather than the prompt.
- How Claude Code escapes its own denylist and sandboxOna
Why rules inside the machine aren’t a boundary, and why enforcement has to live in the kernel and the network.
- Making Claude Code more secure and autonomousAnthropic
Filesystem and network isolation as the way to cut permission prompts.
- MicroVMs vs containersVercel
A short, clear version of the isolation trade-off.
pi-cloud-agent is MIT licensed at github.com/zen8labs/pi-cloud-agent. Next: Part 2: The product decides the sandbox – Coming soon.