Placement: The Brain Need Not Run Where the Code Runs

Placement is where the agent's environment physically sits, and the decision that makes every later placement choice possible is that the brain (the agent loop that decides) need not run where the hands (the ephemeral sandbox that runs code) run. Anthropic's Managed Agents decoupled the two so the harness "called the container the way it called any other tool: execute(name, input) -> string," and the harness "doesn't know whether the sandbox is a container, a phone, or a Pokémon emulator." Shopify reached the same separation independently: "The harness lives outside the sandbox. The agent doesn't live where the code lives" (Shopify case study). Once the brain reaches the hands through a generic interface, where each one runs becomes an independent deployment choice instead of a property baked into the system. That is what sandboxing and versioned images leave open: sandboxing decides how strong the box is and versioned images decide what boots inside it, while placement decides where it boots and what follows from that. The handbook is funded by Wallfacer Technologies, named once below as one implementation and graded on its published documentation.

Placement follows from the brain/hands/session split. The four things that fall out of it once the components can run on different infrastructure: blast-radius isolation, scaling, regional placement and data residency, and scheduling near a task's data or its snapshot.

Coupled placement made the customer's perimeter the harness's problem

Anthropic's first design put the harness, session, and sandbox in one container, and that single placement decision became a customer-facing constraint. "The harness assumed that whatever Claude worked on lived in the container with it. When customers asked us to connect Claude to their virtual private cloud, they had to either peer their network with ours, or run our harness in their own environment" (Anthropic). Both options are expensive. Peering is the change a security team litigates for a quarter; hosting the vendor's harness means you now operate their software. The location of one component dictated the location of all three.

Decoupling dissolved the constraint. Once the brain reaches the hands through execute(name, input) -> string, the harness makes no assumption about where the sandbox lives, so the hands "can be a container inside the customer's VPC while the brain runs elsewhere" follows directly from the interface (Anthropic). No peering, no operating the vendor's software. The same decoupling paid for itself in latency, because sessions stopped paying container provisioning cost they did not need: "our p50 TTFT dropped roughly 60% and p95 dropped over 90%." Those are percentage reductions, the figures Anthropic publishes; it states no absolute seconds.

The harness sits outside the sandbox's failure domain, by placement

Splitting the brain from the hands puts the agent loop outside the blast radius of the code it runs, and that is a placement property, not a code property. Shopify states the payoff in one line: because "the agent doesn't live where the code lives," "the agent loop is not in the same blast radius as rm -rf" (Shopify case study). When the model's generated code (untrusted by construction) runs in a sandbox the brain is not inside, a runaway rm -rf, a prompt injection, or an infinite loop is bounded by the hands and cannot take the agent loop or the session log with it. Stripe expresses the same boundary as a property of where the agent runs: each minion runs in a quarantined devbox "isolated from production resources and the internet," so "any mistakes an agent might make are confined to the limited blast radius of one devbox" (Stripe case study).

Scaling falls out of the same separation. A stateless harness holds no irreplaceable state, so brains and hands scale on separate axes: a pool of harnesses that lazily attach a sandbox only when one is needed. Anthropic's words for it: "Scaling to many brains just meant starting many stateless harnesses, and connecting them to hands only if needed" (Anthropic). Shopify runs the resilience side of this directly. When a session goes idle the process exits, and the next interaction spawns a fresh "session cell," possibly on another host, rehydrated from Postgres (Shopify case study). The host that runs a task is not pinned to the task; the placement is free to move because the durable state is off the machine.

Residency becomes a topology, not a clause

Brain/hands separation turns the strongest residency claim a customer can make into a deployment diagram. The data-sensitive components (the repo checkout, the build artifacts, the secrets) all live in the hands. Place the hands inside your VPC or your chosen region and your code never crosses the boundary, regardless of where the vendor runs its reasoning loop. What crosses the boundary is tool calls and their string results, plus the session log, whose storage location is its own placement question to ask separately.

A clause says the vendor will not move your data; a topology removes the code path that would move the repo checkout, build artifacts, and secrets out of the approved boundary. That distinction is why residency is best treated as a property you can point to in a deployment diagram rather than a sentence in a contract. The same property answers the auditor-facing isolation and residency property: one environment per task, placed where the data is allowed to be, with the audit record placed deliberately too.

Residency matters because the location decision in an agentic system happens at runtime, not at deployment. The IAPP's Keivan Navaie frames the GDPR problem precisely: "When an AI agent rewrites its plan mid-run and calls an API never included in your DPIA, static controls collapse," and residency evidence "lives in the runtime trajectory of every AI agent execution," not the pre-deployment inventory (IAPP, Oct 8, 2025). ARMO states the same shift more bluntly: "AI agents make residency decisions at inference time, not deployment" (ARMO, 2026). A placement that pins the hands and the session log to an approved region is what keeps those runtime decisions inside the boundary your GDPR, HIPAA, and EU AI Act obligations require, instead of leaving residency to wherever a mid-run tool call lands.

Anthropic published the architecture, not a residency product. Regions are never named, and the auditor-facing grading in this guide's isolation and residency property finds that not one of the six graded platforms documents a region selector for task execution or session data. The architecture makes the claim possible; nobody has yet put a region selector in writing. Absence of documentation is not evidence of absence: a platform may place workloads better than its docs say, but a control you cannot cite in writing is a control you cannot put in an audit.

Scheduling places a task near its data or its snapshot

Where a task lands is not only a residency answer; it is a throughput one. Two placement levers decide whether per-task ephemerality costs the user a cold start.

Warm pools. Pre-provision boxes so a fresh-per-task environment does not pay setup cost on the critical path. Stripe pre-warms a pool so a devbox "can be spun up in 10 seconds, with Stripe code and services pre-loaded" (Stripe case study). Kubernetes Agent Sandbox makes the pattern a primitive: a SandboxWarmPool keeps pre-provisioned sandboxes ready because roughly one second of pod startup is enough to break an interactive agent's continuity (Kubernetes blog, March 2026). The warm pool has to live somewhere, so where you pre-warm is itself a placement decision: pre-warm in the regions and zones your tasks will actually run.

Snapshot-cache locality. A task boots fastest where its snapshot is already cached. The image side of this is versioned images, which boots each task from a named snapshot rather than rebuilding; the placement side is scheduling the task onto a host or region that already holds that snapshot, so restore is a local read rather than a cross-region fetch. Ramp's Inspect rebuilds filesystem snapshots every 30 minutes so a fresh sandbox is at most 30 minutes out of date, and its head of applied AI, Rahul Sengottuvelu, names startup time as the constraint the whole design optimizes: "We've tried to design Inspect to as close to the speed of a local agent as possible. Sandbox startup times are a huge part of that" (Modal case study, Feb 19, 2026). Placing the task near the snapshot is how that startup target survives going multi-region.

A managed substrate can frame scheduling and snapshot-cache locality as first-class controls. Wallfacer (disclosure: the sponsor of this guide) boots a fresh VM pair per session from a versioned snapshot and zones its server fleet at the infrastructure layer, which is the shape a snapshot-locality scheduler takes. The Wallfacer case study carries no public security or compliance documentation, so its placement and residency cells are undocumented rather than partial, and zoning a fleet is not yet a published residency control a buyer can hold.

Placement questions no vendor's docs answer, so ask in writing

The published record specifies how to isolate and what to boot, and goes quiet on where. Put these to any vendor and treat a missing answer as no until it is in writing:

• In which regions does task execution (the hands) run, and can we pin it?
• Can the hands run inside our VPC without network peering, or only via self-hosted workers?
• Where is the session log stored, and is its region pinnable separately from execution?
• Where do artifacts land, and in which region?
• Does scheduling place a task near its snapshot, and does that ever cross a region boundary you have not approved?

A vendor built on brain/hands separation can answer all of these with a diagram, because each component's location is an independent parameter. A vendor that co-locates reasoning and execution answers with a promise. Placement closes The Machine: sandboxing set the boundary, versioned images set its contents, and placement sets where it runs. Once the environment is placed where the data is allowed to be, one environment per task is the boundary that keeps parallel tasks from colliding, and the isolation and residency property is satisfied by construction rather than by clause.