One Environment per Task: Isolation Is the Foundation Everything Else Sits On

One environment per task is the boundary everything else enforces. Brex migrated gRPC client factories across 400+ services by giving every task its own Remote Developer Environment, an isolated workspace carrying the same toolchain its engineers use (Brex case study). That one decision let dozens of migrations run without an engineer relaying CI output, and it is the boundary the rest of this section is built on: sandboxing, images, egress, and credentials all enforce it, and the compliance case in Prove It Holds rests on it.

A shared environment fails on both ends at once. Agents trample each other's state, and nobody can say afterward what any one task touched.

Parallelism demands it first

Brex states the lesson plainly: "Running one agent on one task is easy. Running 50 in parallel, each iterating independently, requires thinking carefully about orchestration and environment isolation." An agent iterating in a shared workspace races every other agent for the same files, branches, and test state; per-task isolation is what removes the race. Each Brex agent runs in its own environment and manages its own feedback loop, which is why they report the pattern "scales cleanly." Fly.io makes the same point from the evaluation side: because each run gets its own isolated VM, you can launch many configurations simultaneously without them interfering with each other's state.

The environment is cattle, not a pet

Anthropic learned this by doing it wrong first. Their initial design put the session, harness, and sandbox in one container, and that container became what they call a pet: "if a container failed, the session was lost. If a container was unresponsive, we had to nurse it back to health." Debugging meant shelling into a container that also held user data, which "essentially meant we lacked the ability to debug" (Anthropic).

The fix was to make the environment disposable. The sandbox became a generic tool call, execute(name, input) → string; a dead container surfaces as a tool-call error and a new one is reinitialized with provision({resources}). The environment can only be disposable if nothing you need to keep lives inside it, which is why the session, the durable event log, sits outside every container. The payoff was measurable: provisioning sandboxes only when needed dropped Anthropic's p50 time-to-first-token roughly 60% and p95 over 90%.

No cross-environment communication is a compliance line

The boundary between tasks is enforcement, not an ops convenience. Fly.io enumerates what it enforces in practice: a private, ephemeral filesystem; outbound network blocked or routed through a logging proxy; an unprivileged process; capped CPU and memory. Their example trace shows the point: an attempted write to /etc/passwd comes back blocked, logged, with a reason. Without the boundary, that action "either succeeds in production or fails silently in a mock."

Anthropic adds the credential half. In the coupled design, model-generated code ran in the same container as tokens, so "a prompt injection only had to convince Claude to read its own environment." Brex's governance principle, "agents should only have access to the information they need," needs a unit of enforcement, and the per-task environment is that unit: scoped repo access, scoped secrets, nothing ambient, and no path from one task's data into another's. One environment per task is where least privilege and isolation stop being policy and become topology. That topology is what the auditor-facing isolation and residency property rests on.

Identical for the tenth task and the ten-thousandth

Reproducibility comes from booting every environment from a known-good snapshot rather than mutating a long-lived one. Fly.io's workflow is snapshot the baseline, run, restore, run again: "the same inputs produce the same starting conditions every time," which is also the honest answer to an auditor asking you to reproduce the conditions under which a change was made. Versioned images are the mechanism.

Boot speed is what makes per-task environments affordable. Fly's Sprites start in under a second, billed per second of actual consumption, so a batch of isolated runs does not require a fleet of always-on VMs. Wallfacer (disclosure: the sponsor of this guide) boots a fresh Firecracker or Tart VM pair per session in roughly 2 seconds from a known-good snapshot. Fly is also candid about the cost: for long-running agents with large memory footprints, snapshot and restore overhead "can become significant" and needs tuning.

Isolation contains the blast radius; it does not sanitize the input

The boundary bounds what an attack can reach, not whether it arrives. Identical starting conditions do not make the model deterministic; Fly notes that even with a fixed seed, some models differ across runs. Isolation does not stop prompt injection arriving through content the agent legitimately reads. That is the gap the rest of this section's threat work addresses, starting with the lethal trifecta.

The corpus is silent on marginal cost: none of the three sources publishes what one-environment-per-task costs per task at scale. Brex's evidence is indirect but real: dozens of migrations, "none of them required an engineer to spend an afternoon relaying CI output."

Sandbox isolation, production monitoring, and human review are complements, not substitutes. What the boundary itself is made of comes next: sandboxing.