When we first started building agents with our Agents SDK, we needed something to host them on. We tried several “agent sandbox” providers, and they all faced the same issues: non-negotiable tradeoffs that made agent development messy.

Providers that promised speed compromised security and persistence. Providers that promised persistence offered machines that were slow and more expensive. And if you wanted to save on both speed and cost, then you’re stuck with limited runtime hacks, like V8 isolates or Web Assembly.

Everyone claimed to be selling a sandbox for agents. But no one had everything an agent needs.

Our users were facing the same challenges. Most developers started hosting and testing agents locally, which is pretty straightforward: your agent lives on your computer, often with full access to your files, your context, and your life.

But that’s just the tip of the iceberg.

When you start building agents at scale, with thousands of people using it every day, you need to host your agents in the cloud. Suddenly, you need to start worrying about the scope of each agent: what files and credentials should this agent be allowed access to? How do I stop one user’s agent from sharing context with another user’s agent? How can I dynamically scale the amount of compute I am using for each task?

Using a single machine just won’t cut it. You need separation.

There are a few ways developers achieve separation today. One option is containers, a common way to isolate software from other applications on the same host machine. Containers worked great for SaaS code and seemed like the obvious solution to agent use cases too. They’re quick to start, lightweight, and enable several agents to run on the same host machine. However, containers have a fundamental problem: they lack kernel-level isolation.

Things were more controlled and pre-defined in the old days of running SaaS apps, but once one or more AI models enter the equation, you introduce unpredictability and non-determinism. Couple that with your agents executing untested code or touching unverified inputs, and you have a ticking time bomb with a blast radius of every single container that shares the same host kernel.

Containers don’t work for AI agents; you need a virtual machine (VM). VMs offer strong isolation: every VM has its own kernel and can run workloads of any size. However, the problem with most VMs today is they are slow and bulky, with start times measured in seconds. For agents that need on-demand compute in an instant, a few seconds to minutes is an eternity, delaying responses and increasing latency.

Neither containers nor traditional VMs satisfied us or our customers. We were being forced to cram agents into slow, expensive machines that you have to restart every few hours, or make tradeoffs in security for faster start times.

When we first started building agents with our Agents SDK, we needed something to host them on. We tried several “agent sandbox” providers, and they all faced the same issues: non-negotiable tradeoffs that made agent development messy.

Providers that promised speed compromised security and persistence. Providers that promised persistence offered machines that were slow and more expensive. And if you wanted to save on both speed and cost, then you’re stuck with limited runtime hacks, like V8 isolates or Web Assembly.

Everyone claimed to be selling a sandbox for agents. But no one had everything an agent needs.

Our users were facing the same challenges. Most developers started hosting and testing agents locally, which is pretty straightforward: your agent lives on your computer, often with full access to your files, your context, and your life.

But that’s just the tip of the iceberg.

When you start building agents at scale, with thousands of people using it every day, you need to host your agents in the cloud. Suddenly, you need to start worrying about the scope of each agent: what files and credentials should this agent be allowed access to? How do I stop one user’s agent from sharing context with another user’s agent? How can I dynamically scale the amount of compute I am using for each task?

Using a single machine just won’t cut it. You need separation.

There are a few ways developers achieve separation today. One option is containers, a common way to isolate software from other applications on the same host machine. Containers worked great for SaaS code and seemed like the obvious solution to agent use cases too. They’re quick to start, lightweight, and enable several agents to run on the same host machine. However, containers have a fundamental problem: they lack kernel-level isolation.

Things were more controlled and pre-defined in the old days of running SaaS apps, but once one or more AI models enter the equation, you introduce unpredictability and non-determinism. Couple that with your agents executing untested code or touching unverified inputs, and you have a ticking time bomb with a blast radius of every single container that shares the same host kernel.

Containers don’t work for AI agents; you need a virtual machine (VM). VMs offer strong isolation: every VM has its own kernel and can run workloads of any size. However, the problem with most VMs today is they are slow and bulky, with start times measured in seconds. For agents that need on-demand compute in an instant, a few seconds to minutes is an eternity, delaying responses and increasing latency.

Neither containers nor traditional VMs satisfied us or our customers. We were being forced to cram agents into slow, expensive machines that you have to restart every few hours, or make tradeoffs in security for faster start times.