Artificial Intelligence
Anthropic split the inference loop, the execution sandbox, and the session log apart. The architecture solves problems agents actually hit in production.
Anyone who has run an LLM agent in production knows the pattern. The container dies halfway through a long task, the session is lost, the client gets a half-finished answer, and the team spends the night reconstructing what happened from the logs. Anthropic published an engineering post this week describing how the team built Claude Managed Agents to attack exactly that problem. The architectural choice they made is the most interesting part of the announcement.
In the classic infrastructure analogy, servers are treated either as pets (unique, named, hand-fed) or as cattle (fungible, numbered, cullable). Most LLM agents in production today are built as pets: one container runs the inference loop, the session logs, the tool calls, and the model-generated code, all together. If the container goes down, everything goes down with it.
The Anthropic team (Lance Martin, Gabe Cemaj, and Michael Cohen) describes the decision to virtualize three elements separately: the session, an append-only log of events; the harness, the inference loop that talks to Claude; and the sandbox, the environment that runs the tools. Each becomes cattle. Each can be restarted, replaced, or scaled independently.
If you work on distributed systems, that should sound familiar. It is the same lesson the Kubernetes world learned a decade ago, applied to the new domain of agents.
The session is the source of truth. Instead of irreversibly compressing or truncating context as it grows, the harness persists every event (prompt, tool call, response, error) to a durable log. When the model needs context, it does not depend on whatever survived in the container's memory. It calls getEvents() and asks for exactly the slice it cares about. The post captures the idea well: "it's hard to know which tokens future turns will need". Moving the log into external storage removes the guesswork.
The harness is stateless. Because the session lives outside the process, any worker can pick up a session where it left off. The API is simple: wake(sessionId). That gives you transparent restarts, zero-downtime deploys and, more to the point, lets the harness evolve (new models, new loops) without rewriting history.
The sandbox is disposable. If the container where Claude is running code fails, the result is not a system incident. It is a tool call error that goes back to Claude like any other error, and the model decides whether to retry, change strategy, or ask for help. Infrastructure failure becomes raw material for the reasoning loop.
Each sandbox is exposed to the model as a single tool: execute(name, input) → string. Claude can route work across multiple environments (one sandbox for Python code, another for data analysis in a different VPC, a remote MCP server) without knowing or caring where each one runs.
Anthropic reports two improvements that help explain why the architecture is worth the work.
Time-to-first-token dropped around 60% at p50 and more than 90% at p95. The reason is simple: containers are no longer provisioned up front for every session. They come up when Claude actually calls a tool. Short sessions, which dominated the cost under the old model, pay almost no cold-start time.
Credentials never reach the sandbox. OAuth tokens, API keys, and git credentials stay in a vault, injected through a proxy or bound to resources at startup. The code Claude writes never sees the secrets. If you accept that a model running arbitrary code inside a container is, by definition, an insider risk vector, this is the change that counts most.
One passage in the post deserves to be quoted in every discussion about agents. The team observed that the same harness started behaving worse when it moved from Claude Sonnet 4.5 to Opus 4.5. Sonnet 4.5 had what they called "context anxiety": it scaled back the ambition of the task as the context limit approached. The harness was designed to compensate for that anxiety. Opus 4.5 does not behave the same way, and the compensations turned into sabotage.
The conclusion is blunt: harnesses encode assumptions about what the model cannot do on its own. Every new model version makes a slice of those assumptions obsolete. If harness and model are tied into the same binary, you pay that cost in silent regressions at every upgrade. If they are decoupled, you can test, roll back, or adapt the harness without touching the session or the sandbox.
For anyone building enterprise agents, that is the part that matters most. The point is not optimizing TTFT in a lab. It is being able to update the model without rebuilding your integrations.
Three practical implications:
First, stop treating context as something that fits in a window. If your agent has to compact history to fit the prompt, you are treating context as RAM when you should be treating it as disk. Structured session logs, queryable on demand, are the pattern that will win. Anyone building on tools that hide the log behind opaque abstractions will hit the same ceiling Anthropic hit before the rewrite.
Second, separate credentials from the execution environment from day one. This is not paranoia. It is the only way to run model-generated code without creating security debt that comes back at audit time. The vault-and-proxy pattern Anthropic describes can be built with mature tools (HashiCorp Vault, AWS Secrets Manager with IAM roles), and it should be the baseline.
Third, treat the harness as infrastructure software, not disposable glue. It needs its own tests, versioning, and observability. And it has to be decoupled enough to survive three or four model swaps without a rewrite. If your current approach is "a Python script with a while loop", you are building debt.
Most companies that ask us to build an agent start with the wrong question: "which model should I use?". The question that matters is a different one: how does this agent survive six model upgrades over the next twelve months without becoming an operational nightmare? What Anthropic published is the blueprint for that answer, and it confirms decisions we were already making on enterprise agent projects: a durable session outside the container, a stateless harness with wake semantics, a sandbox treated as ephemeral, secrets out of the model's reach.
Not every company needs to reimplement Managed Agents in house. But anyone about to run a serious agent in production needs to understand why this architecture exists, and to ask which layer of their own stack is still stuck in a pet container waiting to fall over.
Worth reading in full on Anthropic's engineering blog: Claude Managed Agents: Decoupling Architecture.
Read also: How AI is transforming business operations