Anthropic separates agent brain and hands to shield credentials in the Claude Platform
In an episode of the Latent Space podcast recorded in October 2026, Anthropic executives detail how the Claude Platform separates an agent's reasoning from code execution, a pattern that reduces latency and isolates credentials.

- Reading
- 6 min
- Code
- 1
In an episode of the Latent Space podcast recorded in October 2026, Anthropic executives detail how the Claude Platform separates an agent's reasoning from code execution, a pattern that reduces latency and isolates credentials.
In the Latent Space podcast episode published on October 27, 2026, Katelyn Lesse (engineering) and Angela Jiang (product), both from Anthropic, detailed an architecture pattern the company uses to build its own agent products: separating an agent's "brain" from its "hands." The conversation, recorded the day after the Opus 5.5 launch, uses that model as a backdrop, but the central subject is different: how the Claude Platform (the API and infrastructure layer underlying Claude Code, Anthropic's copilots, and customer products) is built to withstand long-running agents without compromising security or latency.
The concept comes from a feature called Managed Agents, described in Anthropic's technical piece "Scaling Managed Agents: Decoupling the brain from the hands," cited in the episode. The central idea: the session history and the harness (the "brain," which decides what to do) are kept separate from the sandbox that executes code (the "hands"). A sandbox that crashes doesn't need to take down the agent's entire session.
Why separate the harness from the sandbox
According to the guests, the previous approach placed the entire coding agent inside a sandbox, behind an API. That meant that, to respond to the first message, the execution environment had to be initialized first, and only then the agent itself. If the sandbox went down, the agent went down with it, even if the problem was only in running a single command.
With the brain and hands decoupled, the harness persists as an independent process. The sandbox is created on demand, when there's actually code to run, and can be recreated without the session losing context. In practice, this tackles two problems at once: latency (there's no need to spin up a full execution environment just for the agent to decide its next step) and resilience (an infrastructure failure becomes an isolated event, not a product incident).
The security gain is a side effect of the architecture
The separation also solves an attack-surface problem that normally requires extra layers of protection. If the code generated by an agent runs in a sandbox that never receives a service credential, there's no credential there for that code to leak, even if the agent is compromised or the generated code is malicious.
In the design discussed in the episode, credentials stay outside the sandbox and are attached via proxy, with controls over where the sandbox's traffic can go. Anthropic documents this broader set of isolation and network controls in the material "How Anthropic contains Claude across products," also cited as a reference in the episode's show notes.
For those designing agent runtimes, the pattern suggests a simple checklist before designing the next version of a harness:
- What needs to survive an execution failure, and what can be disposable?
- Which part of the system executes untrusted code, whether from the model itself or from external input?
- Which secrets really need to exist in the same process that runs that code?
Editor's note: the code in this section was not executed in a real environment. Validate before using in production.
A simple way to visualize the design (illustrative, not Anthropic's actual code):
# harness: processo de longa duração, guarda estado e decide ações
# sandbox: efêmero, sem credenciais, só recebe comandos a executar
harness.on_tool_call(acao):
sandbox = pool.obter_ou_criar(sessao_id)
resultado = sandbox.executar(acao, credenciais=None)
harness.registrar(resultado) # sobrevive mesmo se sandbox morrer depoisMemory as a primitive, not a standalone feature
One of the most interesting uses of Managed Agents, according to the episode, is an internal feature the pair calls "dreaming": an agent inspects another agent's previous work and writes memories back for future use. It's not a separate memory module, it's simply another agent operating on the same session and sandbox primitives.
This detail matters more than it seems. Instead of building a memory feature as a special case, Anthropic treats memory, verification, and agent parallelism as compositions of the same basic infrastructure. The guests describe the product strategy as keeping the base harness relatively simple and letting external developers compose verifiers, parallel agents, and other strategies on top of it, rather than embedding all of that into the platform.
One caveat is worth noting: the ideas mentioned about the platform's future capabilities are plans discussed in an interview, not features already shipped. The priority roadmap itself shifted over the course of the year. The pair reports that more of the team's attention moved toward security as model releases became harder to evaluate, which pushed memory and learning to a more distant horizon than initially planned.
The Opus 5.5 launch was also an API launch
The conversation ties the agent architecture to a concrete change made alongside the Opus 5.5 launch (which, according to the episode, had already been treated for about a month as the most capable model available on the market). Besides price cuts and reduced verbosity, Anthropic tightened protection against chain-of-thought extraction for distillation purposes, preserving reasoning blocks across turns more strictly.
This matters for anyone integrating directly with the API, because the same adjustment that makes distillation by third parties harder can break harnesses that relied on the previous behavior of reusing reasoning tokens. In the episode, the decision is described as a difficult tradeoff between developer experience and protection against mass extraction, prompted by the responsible disclosure, by external researchers, of the technique described in the paper "Stealing Reasoning Traces from Proprietary LLMs," cited by name in the conversation (though without mentioning the authors' names).
What's left out
The episode also mentions, without detailing, a rewrite of the Messages API in Rust as part of the effort to scale the Claude Platform under CPU constraints, a topic covered around the midpoint of the conversation (timestamp 56:05 out of a total of 104 minutes), according to the podcast's timestamps. The source includes no latency or throughput figures tied to this migration, so it's best treated as an engineering direction mentioned, not a measured result.
The biggest blind spot for anyone who only looks at the Opus 5.5 announcement is exactly this: the visible part of the launch is the model and the pricing, but the part that underpins products like Claude Code is the architectural decision about where each part of an agent runs and which secrets it carries. For teams building production agents, the practical lesson from the episode isn't to copy Anthropic's Managed Agents, it's to ask the same three questions about their own runtime before a compromised sandbox turns into a credential incident.
Translated from the Brazilian Portuguese original · Read the original
Ai2 study shows LLMs fail to judge whether a research idea is original
A study from the Allen Institute for AI tested six models as





