Running agents in a sandbox or VM is the wrong pattern

You might have seen a weird scene where people carry their laptop with the lid half open. It turns out to be their running agent, and they don’t want their laptop to go to sleep even when they are walking around. The laptop is telling you two things: the agent is so useful that people are willing to babysit the hardware for it, and it’s running in the wrong place.

The obvious solution is to move the agent from the laptop to the cloud. I have seen many people deploying their agents in sandboxes and VMs. It looks like a trivial solution at first, but it will bite you later. In this article, I will explain why this is a bad pattern and why decoupling is the right approach.

I would like to cover three parts to help you understand the benefits of the cloud agent and the correct way to deploy it.

• Why move to the cloud at all?
• Why is the trivial answer—an agent in a sandbox—wrong?
• Decouple the hands from the brain.

Why move to the cloud at all

There are three reasons.

Continuous running. Your laptop closes, and the agent stops. Anything that lasts beyond your attention span can’t live on a machine that sleeps while you are away.

For example, there is a loan approval agent that handles mortgage refinances. A borrower asks about the rates on Monday, but doesn’t submit the application until the following week. In between, the agent pulls a quote, files an inquiry, waits two days, answers a question over email, calls the applicants to remind them of the application deadline, and hands off to a human when the numbers get unusual.

No human is sitting and watching the entire process. The agent wakes up on a signal, decides what to do, finishes the work, and goes back to sleep. This is a very typical long-horizon task that an agent can handle, but it is an impossible shape for a laptop.

Elasticity. When workloads are unpredictable and spiky, the laptop’s hardware cannot handle them.

Let’s say you have a one-off job to build the wiki for the company codebase. There are two options: launching 500 agents as a swarm to explore the codebase collaboratively, or launching a single agent that fits on a laptop. You get the result in 20 minutes with parallelism, or in a week with a single agent.

This kind of request is ad hoc. We don’t need to do such wiki building every day. For example, we can replace the agent swarm with a maintenance agent that handles changes only. It’s unrealistic to purchase 500 laptops for this ad hoc task and then leave them idle after the task is completed.

You want 500 agents for 20 minutes on Tuesday and one agent for the rest of the week. This is exactly what cloud infrastructure is good at: scale up first, go back down to nothing, and pay for the 20 minutes.

Isolation. Since the launch of OpenClaw, people have shared their experiences of email being mistakenly deleted and credentials being stolen.

On a laptop, the agent runs as you. That means it has your API keys, cloud credentials, and browser profiles. They are the exact reason people have an Aha moment when they install OpenClaw for the first time. The agent seems to know you so well that it can execute like a personal assistant on your behalf.

However, this is the trade-off between security and convenience. The cloud lets you ask a better question: what is the minimum environment the agent needs to complete this task?

For example, a refactoring task requires GitHub authorization. The initial triage of an on-call ticket requires only read access to observability endpoints, with no write access at all. Fortunately, most environment configurations are reusable because most tasks are repeatable.

On a laptop, engineers discover the blast radius after a real incident. In the cloud, we can define it in advance.

So, move the agent to the cloud. Fine. Now how?

Why is the trivial answer (agent in a sandbox) wrong?

The common approach is a direct port: take the agent that runs on the laptop and move it to a VM or sandbox. It was so simple that many small SaaS offerings emerged to let people deploy OpenClaw in a VM. Everything ships as a single unit: the loop that decides what to do next, the shell that executes commands, and the session files that live on the container’s local disk.

The appeal is real. Nothing about the agent has to change; there is exactly one thing to deploy, and it works the first time you run it.

Nobody notices the dropped context. When you move your agent to a cloud VM or sandbox, it loses the working context that is available only on your personal machine. Those small SaaS offerings hide this issue, which is why many people never experience the Aha moment when they first try OpenClaw in the cloud. The failure here isn’t technical; it’s a decision made silently.

The second failure is that the hands and the brain fail together. When the agent loop and shell-command execution live in the same container, every failure is total. For example, if the agent is using a browser, memory usage can increase rapidly and unpredictably. The OOM (out-of-memory) killer doesn’t care which part of your process was important. The entire container dies due to OOM. Now consider what you lost. The agent had been running for 40 minutes. It had read more than 30 files, run the unit tests twice, and built a session that actually knew something. All of that was located in process memory and in a JSONL file on a disk that no longer exists. You cannot resume from that. You have to start over and pay for the same tokens again.

Scaling looks easy at the start. If you need more agents, you allocate more containers. It stays easy until you start to care about the failure rate and the invoice from inference providers.

Decouple the hands from the brain

In April 2026, Anthropic launched Claude Managed Agent with a blog post titled “Scaling Managed Agents: Decoupling the Brain from the Hands.” The most valuable lesson from that post is “do not adopt a pet,” where a “pet” is a non-disposable service—just like the agent in the sandbox.

How can we decouple the agent so that it is no longer a pet? If you open any local agent, you’ll find the same three parts:

A session store. Every user message, inference result, and tool request and result is recorded in the session store. On your laptop, it is a JSONL file or a SQLite database.

An agent loop. It is essentially a while true loop that reads the last message in the session and decides what happens next: call the model, run a tool, or stop. It then appends the result to the session store.

An execution layer. This is the component that actually runs the shell command. Your laptop itself is the execution layer. All the packages, networks, skills, and working directories are available on this device.

In the cloud, we want to make each one its own service.

The session store becomes the single source of truth. We can make it a distributed log system that you can append to and read from anywhere. Because it is distributed:

• There is no need to worry about losing session information, unlike with a traditional JSONL file.
• A single machine failure will not bring down the entire agent session.

The agent loop becomes a stateless worker. A worker reads the tail of the log, performs exactly one step—either inference or tool execution—appends the result, and forgets everything. It holds zero session state between turns. Any worker can pick up any session, and any new worker can replace a dead worker.

The execution layer becomes the sandbox. This is where the agent’s working environment is configured. The user loads skills and installs packages into the sandbox. They can also mount customized file systems to:

• Provide extra working context
• Retain artifacts from the agent

This is how the context problem is solved rather than ignored.

With this decoupling, here is what you actually get:

• Recovery costs one step instead of one session.
• The single point of failure is gone. All services are cattle instead of pets.
• Elasticity becomes native.

When can you use an agent in a sandbox?

If you are building a prototype, you can deploy the agent in the sandbox. At the end of the day, you will throw it away. Decoupling buys durability, elasticity, and cost efficiency. None of those are needed for a prototype, and the extra services will slow you down.

Production is a different story, especially when you want to run your agent service at scale.

Summary

Let’s do a quick recap. We all noticed there’s demand to run agents in the cloud because leaving a laptop half-open and walking around isn’t cool. It seems trivial to move local agents to a sandbox or VM, but that simplicity comes at a cost: dropped context, a single point of failure, no elasticity, and more.

Therefore, we choose to decouple agents into three components: the session store, the agent loop, and the execution layer. These decoupled services solve the problems above and are naturally scalable and cheaper.