learnaiwithrafa
ClaudeAgents

Managed Agents: Anthropic Now Runs the Loop, Not Just the Model

Claude Managed Agents moves the agent loop, the sandbox and the session state onto Anthropic's infrastructure. The line nobody reads: it isn't eligible for Zero Data Retention or a HIPAA BAA — and self-hosting the sandbox doesn't buy that back.

5 min read6 sources
  • #managed-agents
  • #claude-platform
  • #sandbox
  • #architecture

The headline feature of Claude Managed Agents is not the agent. It's that Anthropic now owns the while loop, the container it runs in, and the log of everything that happened. If you already operate an agent in production, that is a migration question, not a launch announcement — and the sentence that should decide it sits in a grey note near the bottom of the overview page: because sessions keep conversation history, sandbox state and outputs on the server, Managed Agents is not currently eligible for Zero Data Retention or HIPAA BAA coverage.

Read that first, then read the features.

What you're handing over

The product is four resources. An agent is the model, system prompt, tools, MCP servers and skills. An environment says where sessions run. A session is one running instance of that agent doing a task. Events are the messages moving between your app and the agent. You create the first two once, then start sessions against them; everything behind the managed-agents-2026-04-01 beta header.

What disappears from your codebase is the agent loop, the tool-execution layer and the runtime. Claude arrives with Bash, file read/write/edit/glob/grep, web search and fetch, and MCP servers already wired. Cloud sandboxes are Ubuntu 22.04 on x86_64 with up to 8 GB of memory and 10 GB of disk, Python 3.12+, Node 20+, Go, Rust, Java, Ruby and PHP preinstalled, plus SQLite locally and psql/redis-cli for talking to databases elsewhere. Nobody on your team maintains that image.

The architecture is the trade-off

Anthropic's own engineering write-up frames the design as decoupling the brain from the hands. Inference and orchestration live in a harness; the sandbox is called as a stateless tool; the session is a durable event log that sits outside both. The payoff is real — a dead container no longer kills a run, and because sandboxes are provisioned when a tool is actually invoked rather than up front, time-to-first-token fell roughly 60% at P50 and over 90% at P95.

Now read the same sentence as an EM: the durable event log is the product, and it is theirs.

Self-hosting the sandbox is not self-hosting the loop

This is where most people will get the mental model wrong. Self-hosted sandboxes exist, and they move tool execution to infrastructure you control — the filesystem the agent touches, the processes it spawns, the network it can reach. But the docs are explicit that orchestration stays on Anthropic's side, and that tool inputs and outputs still travel to Anthropic's control plane so the model can decide what to do next.

So self-hosting answers "our source code and our internal services never leave the network". It does not answer "nothing about this run is stored outside our boundary". Two different compliance conversations. Pick the right one before you promise your security team anything.

What's genuinely hard to rebuild

Three capabilities shipped on top of the harness. Outcomes (public beta) lets you define success as a rubric and puts a grader in a context window of its own, so the evaluation isn't coloured by the agent's own reasoning; Anthropic reports up to 10 percentage points on task success, and +8.4% and +10.1% on docx and pptx generation. Multiagent orchestration (public beta) has a lead agent delegate to specialists that each carry a different model, prompt and toolset, working in parallel on shared storage. Dreaming (research preview, access on request) runs a scheduled pass over past sessions and memory stores and curates what the agent keeps, with automatic or manual approval of the changes.

Of the three, the grader is the one I'd think twice about rebuilding. Everyone writes their own orchestrator eventually; almost nobody gets around to building a judge that runs outside the agent's context.

The decision rule

Keep your own loop when the loop is the product: custom control flow you can prove, your own eval and tracing hooks, an orchestrator your team already trusts, or a ZDR/BAA obligation you can't renegotiate. The Messages API is still the documented path for fine-grained control.

Take Managed Agents when the loop is undifferentiated plumbing and the work is long-running and asynchronous — minutes to hours, many tool calls, nobody watching.

My rule of thumb: if you can't name one decision your loop makes that Anthropic's harness wouldn't, you're paying an engineer to maintain a commodity.

Do this today

Take the one background job in your stack you'd be least uncomfortable losing control of — a nightly report, a doc generator, a data-cleanup script. Rebuild it as one agent, one cloud environment, and one session seeded with initial_events so it starts working in a single call. Then open that session in the Console and read the event list end to end.

That log is the honest test. If you're happy for it to live on Anthropic's side, migrate more. If reading it makes you uneasy, you just learned that your loop was never the undifferentiated part.

Sources