Treat Sandboxes as Resources, Not an Agent’s Home

A sandbox should be a place an agent does work, not the place the agent permanently lives. Separate the agent’s durable context, records, and ongoing work from the machine used for a task. Then treat sandboxes as execution resources: use more capable compute for heavier work and lighter environments for simpler tasks.

This is a design boundary, not a rule that every task needs a new machine or that every sandbox must be stateless. The goal is to avoid tying the health of an agent system to the health and configuration of a growing set of individual machines.

When a VM fleet becomes hard to operate

Giving each agent its own VM can work at small scale. The agent has a place to run, its tools are nearby, and an operator can inspect the machine when something fails. As the fleet grows, that model can turn routine machine maintenance into ongoing agent maintenance.

In one account from the QM team, more than 50 Hermes agents ran in VMs. The team found the agents useful, but the fleet was hard to configure and manage. An operator had to SSH into individual instances to fix them, described as a whack-a-mole problem.

The problem was not simply the number of machines. The agent’s continuing work was tied to a particular machine’s state and configuration. When persistent context, operating records, and task execution all live together, each machine becomes an individual home that must stay healthy.

A cleaner boundary separates two things:

• Durable agent work: the context, records, and operating continuity an agent needs across tasks.
• Task execution: the compute environment used for one piece of work.

That separation does not remove operational work. It moves the durable center of the agent outside the task machine, so the platform can manage execution capacity as a pool of resources rather than as a collection of permanent homes.

What the QM example shows

QM described pulling the system’s “brain” out of the sandbox and putting its information in a database. In that model, a sandbox is not primarily where an agent lives. It is a resource the agent can use when needed.

This is one observed architecture for internal agent platforms, not proof that every platform should work this way. It does show why a team may want durable agent work to survive repair, replacement, or reassignment of a task environment.

The same account includes an important limit: QM still used a default sandbox allocated to the user the agent was serving. Separating durable work does not require removing defaults or provisioning a new environment for every task. A default can remain useful while the system can choose another environment when the work calls for it.

The key design question is: Which parts of an agent must persist outside a sandbox, and when should work run somewhere other than the default environment?

Match sandbox capacity to the task

Execution capacity should fit the work at hand. In the QM situation, an agent handling a heavier development workload could reach for a machine with more resources. For a simpler task, it could choose a less powerful sandbox.

That comparison matters because a fixed environment can fail in two directions:

• A platform may over-allocate by using its most capable environment for every task, even when simpler work does not need it.
• A platform may under-allocate by forcing every task into the same lightweight environment, even when heavier development work needs more capacity.

QM pushed the selection decision into the agent rather than the harness, the surrounding system that runs and coordinates the agent. The account describes that as a powerful approach. It should be treated as an observed approach, not a universal rule: the available evidence does not provide a scheduler policy, resource specifications, benchmarks, or a direct comparison with central selection.

For platform teams, the useful lesson is to make environment selection an explicit design choice rather than an accidental result of where an agent happens to be assigned.

Make selection bounded and observable

The following steps are design recommendations based on the observed architecture, not a description of the QM implementation.

Separate durable work before changing resource choices

First, identify what cannot disappear when a task environment needs repair, replacement, or reassignment. Keep that durable agent work outside the task machine.

This does not mean every sandbox is disposable. Some environments may remain allocated defaults, and some tasks may need continuity in one environment. The narrower goal is to avoid making one machine the only durable location for an agent’s operating life.

Offer a small set of environment options

Expose a small, understandable set of choices rather than an open-ended catalog of machines. That might include a default environment, a more capable option for heavier development work, and a less powerful option for simpler tasks.

A limited set makes choices easier to explain and review. It also keeps infrastructure selection from becoming an opaque decision based only on internal machine labels.

Decide who chooses the environment

Several selection models can be reasonable:

• Agent-directed selection: The agent chooses from allowed environments based on its understanding of the task. This reflects the QM approach.
• Platform-directed selection: The platform or harness applies centrally defined rules.
• Human-directed selection: A user or operator chooses when work has unusual cost, access, or operational risk.
• Hybrid selection: The agent proposes a choice from a bounded set, while the platform enforces limits and sends exceptions for review.

The source material does not show that one model works best in every setting. Agent-directed selection can be useful because the agent has task context, but the choice should not be unconstrained by default. A platform may prefer central rules for consistency, while human choice may fit work where a person needs to exercise judgment.

Record each environment decision

Record the task, choice, and outcome for each environment decision, including who or what made the choice. Those records make it possible to inspect recurring exceptions and judge whether resource choices are sensible.

The QM account notes that traces could in principle support this work, but that results were mixed. Records are a prerequisite for learning and governance; they do not guarantee that a platform will optimize itself.

Set permissions at the boundary

When durable context sits outside individual sandboxes, permissions matter more. The amount of information that can safely enter an agent’s durable context is limited by the quality of the permission system.

Set explicit access boundaries for both durable context and execution environments. Ask which tasks may read or change which records, and which environment choices create access or operational consequences that need additional approval.

QM described database access as mostly read-only and bulk updates as human-reviewed. That illustrates the value of separating ordinary access from higher-impact changes. It also noted that people can rubber-stamp reviewed actions, so a review step needs a clear decision, enough context, and a practical reason to intervene.

Reduce coupling without removing useful defaults

An agent can have durable continuity without being permanently attached to one machine. When a fleet becomes difficult to configure, inspect, and repair one instance at a time, separating durable work from task execution can reduce that coupling.

Keep a default user-allocated sandbox where it helps. Provide a small set of alternatives for work that needs more or less capacity. Make the selection bounded, observable, and permission-aware, then revisit it using recorded outcomes rather than assuming that either an agent or a scheduler will always choose correctly.

The QM account is a useful example of this operating model, not a benchmark or universal prescription. Its core lesson is straightforward: keep the agent’s durable work separate from the execution resources chosen for each task.