Anthropic's "Brain and Hands" Split: What Agent Builders Should Examine

A Latent Space episode describes Anthropic's Managed Agents design as keeping the agent's harness and session log separate from the sandbox that executes code. That changes the failure boundary: a sandbox crash doesn't have to end the session. But the episode offers no measured reliability or latency numbers, so treat the architecture as a set of questions to test, not proof of better outcomes. ²

The useful distinction is between a model that reasons about what to do and the systems that decide what it's allowed to do, execute actions, preserve state, and handle failures. For teams evaluating managed AI agents, the real work is inspecting those boundaries: what persists, what's authorized, how the API behaves under load, and what the platform tells you when something breaks.

What "brain and hands" means for agent architecture

In the episode's framing, the "brain" is the model's reasoning. The "hands" are the harness and surrounding infrastructure: sandbox, credentials, proxies, and the external systems the agent acts through. Latent Space is describing Anthropic's Claude Platform and Managed Agents, not independently validating the results. ²

The design detail that matters: the session log and harness are described as separate from the sandbox that runs code. The harness can stay available while an execution environment is provisioned or replaced. ² In effect, the model is one stage in a control loop. It proposes actions, while other software decides which actions are allowed, where they run, what state survives, and how failures surface. That control-loop framing is a reading of the episode, not a claim that every agent should be built this way.

This separation matters because an agent isn't one component. A model can suggest a tool call; infrastructure or application policy still has to decide whether that call is permitted. Distinguishing the model's output from the permissions and execution paths that turn it into effects is the first thing a platform review should do. ²

AI agent reliability: what breaks when model and execution are tied together

The episode contrasts the separated design with an earlier approach in which the full coding agent ran inside a sandbox behind an API. Starting the environment and agent added latency before the first response, and losing the sandbox killed the running agent outright. ²

With a separate harness, a sandbox failure can instead become an execution failure the harness detects and handles. The harness persists while an execution environment is created on demand, so a failed sandbox doesn't necessarily end the session. ² What that doesn't tell you: whether state is restored correctly, whether retries are safe, or what the user sees during recovery. The source gives no retry behavior or recovery measurements. ²

What to check: Treat session survival as a hypothesis to verify under failure, not a guarantee. Ask the vendor to show what happens when execution stops mid-tool-call, when an environment can't be recreated, and when a retry risks repeating an external action (a payment, an email send, a database write). A preserved session log only helps if the platform also surfaces execution state and outcome clearly enough for your application to decide what to do next. Persisted state also carries its own risks; persistent agent memory needs an integrity model, not just a prompt filter.

The episode frames the separation as a path to lower latency and better reliability with isolated execution, but supplies no measured numbers for either. ² Push vendors for results tied to workloads like yours, including the conditions under which those results were measured.

Credentials, network access, and action control

The episode describes credentials as held separately and attached through a proxy, with controls over where sandbox traffic can go. Generated code running without a service credential reportedly can't read that credential from inside the sandbox. ² That's a meaningful boundary, but the episode doesn't specify the full control set or how customers configure it. ²

Turn the description into implementation questions:

• Which credentials can an agent request, and how are they scoped?
• Which proxy routes and external destinations are permitted?
• Can policies vary by session, organization, environment, or data type?
• What gets recorded when an action is permitted or denied?
• If a tool call fails, can the operator tell a policy denial apart from a network or execution failure?

These are diligence questions, not claims about the platform's full feature set. ² The underlying principle worth adopting regardless of vendor: separate model authorization from infrastructure authorization. The model proposes; a policy layer decides whether the action is allowed in context. The episode describes credential and traffic separation. It doesn't lay out a complete policy interface. ²

The same principle applies one layer up, at the point where your applications call models. An enterprise AI gateway such as Yelno's applies hard routing constraints (region, data policy, allowed providers and models) outside the model itself, which is one way to keep that decision out of the prompt.

Claude API scaling and cost

The episode says fast-growing usage made ordinary infrastructure choices, including CPU consumed per API call, strategically important. That puts API behavior inside the agent platform's scaling design rather than treating it as a thin transport layer. ² A related Latent Space episode lists a rebuild of the Messages API in Rust as a topic, with no implementation details or scaling numbers given. ¹

That's a signal about where engineering attention is going, not evidence of capacity. Neither source provides rate limits, capacity figures, latency results, or CPU costs. ¹² Before committing, ask how the service behaves with concurrent sessions, bursts of tool calls, growing context, retries, and execution-environment provisioning. You want enough detail to estimate queueing and recovery behavior for your own traffic pattern.

Cost deserves the same workload-specific scrutiny. The episode says Opus 5.5 costs less to run than its predecessor, with actual savings depending on workload and cached-context use. ² Don't generalize that into a cost forecast. Get pricing estimates run against representative prompts, context reuse patterns, tool-call volume, and your actual task-completion bar.

Managed agents vs. building the harness yourself

A managed platform can hand you a prebuilt boundary between session state, execution, credentials, and model calls. That means fewer components to assemble, but the platform's failure semantics, policy controls, and observability become the central procurement questions. ²

Building the harness yourself gives more direct control over state transitions, tool permissions, retries, evaluators, and deployment topology. The trade-off: you own those components, and you have to measure their behavior yourself. ² If you go this route and want to compare models across providers, a governed model catalog can keep that comparison in one place.

Worth flagging separately: the episode cautions against treating every discussed capability as shipped, since some items were future plans, not commitments. ² Ask vendors to separate what's generally available, what's limited or experimental, and what's still on a roadmap. For each, figure out what your application does if that capability changes or disappears.

What to measure before adopting managed agents

Start with task outcomes, not model quality in isolation. The episode describes a harness as an application that improves through setting a goal, measuring behavior, inspecting failures, and iterating. ² That's a useful evaluation loop, not a benchmark result.

Measure the full path, not just model responses:

• Time to first response, and time spent waiting on an execution environment.
• Tool-call success and task completion on representative work.
• State preservation and recovery after sandbox failure.
• Actions denied by policy, and whether the reason is visible to operators.
• User-visible behavior when a task can't complete.
• Cost and latency across the context and tool-call patterns your workload actually uses.

None of these are reported results in the sources. They're the measurements a serious evaluation needs. ² Your test set should also include ambiguous requests; tool-using agents need tests for users who leave things unsaid.

The episode also describes early-access customers evaluating models in their own harnesses, reporting unexpected behavior and sharing informal impressions. ² That's useful for designing your own tests, not a substitute for them. It discusses verifiers and parallel agents too, without comparative results. ² Test whether either actually improves your task outcomes enough to justify the added coordination and cost. Don't assume more agents means more reliability.

A diligence checklist for managed AI agents

Use the architecture to organize the review:

Area	Questions to answer
Control	Can you define allowed tools, destinations, credentials, models, and providers? Which decisions are enforced outside the model? The episode describes credential and traffic separation but doesn't enumerate a full policy interface. 2
Failure handling	What survives sandbox failure? Are retries safe? Can a session resume with its log and context intact? What error reaches the user? The episode explains why these questions matter, not the answers. 2
Scaling	How does the API behave as concurrent sessions and tool calls grow? What capacity, queueing, and rate-limit data is available? Both sources leave this open. 12
Change management	Can a new API requirement break an existing harness? The episode says preserving thinking blocks across turns is meant to protect reasoning from extraction for distillation, and separately notes that API changes can break customer harnesses. 2
Evidence	Which claims are measured, which come from customer reports, and which are roadmap ideas? Keep those three buckets separate in a purchase review. 2

One concrete next step: run a controlled pilot against representative tasks and deliberately inject failures. Stop execution mid-tool-call, deny a credential, force a retry path. Watch whether the session state stays legible, whether the platform distinguishes policy errors from infrastructure errors, and whether the task completes without duplicating side effects. This is a proposed test plan, not a result anyone has published.

The brain-and-hands split is useful mainly because it makes the execution boundary visible. It doesn't settle whether a managed agent is more reliable, faster, or cheaper for your company. Those answers come from controls, failure behavior, API capacity, and task-level evidence you still have to go get.

Sources

¹ "How Anthropic ships the #1 LLM in the World safely: Separating the Brain from the Hands," Latent Space

² "How Anthropic ships Claude with Claude: Separating the Brain from the Hands," Latent Space