Claude Managed Agents: The Local/Hosted Line a Model Company Drew Itself

TL;DR. Claude Managed Agents is where the model company itself split the local plane and the hosted plane into two distinct governance planes. Public beta on 2026-04-08; enabled by default for every API account via the managed-agents-2026-04-01 beta header; standard token pricing + $0.08/session-hour. Run it alongside the local Claude stack and seven conflicts surface immediately — agent definition, permissions, memory, audit, trust boundary, key blast radius, and a three-way crossover with Claude Platform on AWS. Where AWS Agent Registry is friction between different vendors, here one vendor drew the line between the hosted plane and the local plane with its own hand. Three things — single source of truth, auth/permission coherence, and lifecycle — break in the hosted plane the same way. And the single-source decision breaks first precisely where coherence should be highest: at the same vendor.

Why This Matters Now

This quarter, every team running the local Claude stack is forced into a local-vs-hosted governance decision — not as an option, but because it's already switched on. Claude Managed Agents shipped in public beta on 2026-04-08, and although the managed-agents-2026-04-01 beta header is required on every endpoint, the SDK sets it automatically, so it's enabled by default for every API account. Price isn't a barrier either — standard Claude API token rates plus just $0.08/session-hour. Among the "two major clouds, two major model companies entering at once in April 2026" laid out in the governance index, this piece covers the model company's own answer.

What Claude Managed Agents Is

Claude Managed Agents is a hosted agent runtime that delegates the agent loop, sandboxing, tool execution, and session persistence to Anthropic's infrastructure. It's built from four core concepts.

The core operating model is simple — create an agent once, get an ID, and reference that ID per session. The agent definition is sealed; a session merely points at the seal. The model is one of Sonnet 4.6 / Opus 4.6 / Haiku 4.5.

This is about who hosts agent execution and persistence — a different question from who registers, discovers, and approves agents (the surface AWS Agent Registry covers). Different faces of the same governance terrain.

The Five Core Features

1. Hosted harness. Anthropic runs the agent loop, sandbox, tool execution, and session persistence on your behalf. No need to operate your own orchestration infrastructure. The sandbox is sealed by triple isolation: gVisor userspace syscall interception + a process manager + a network firewall.
2. Vault credential proxy. Secrets never enter the sandbox — they're injected server-side at the moment of a tool call. So the path for exfiltrating credentials via prompt injection is closed structurally. The catch: tokens hardcoded into env vars, the system prompt, or a mounted file bypass this proxy.
3. Append-only event log. App↔agent messages accumulate append-only outside the container, surviving even a harness restart. The audit record is decoupled from the lifespan of the execution environment.
4. Permission asymmetry. The eight built-in tools (agent_toolset_20260401: bash · read · write · edit · glob · grep · web_search · web_fetch) run automatically under a default of always_allow, while MCP tools default to always_ask and require approval on every call. Trust splits in two.
5. Concurrent availability on Claude Platform on AWS. The same feature is also offered on Claude Platform on AWS — though feature and session behavior differ.

Seven Conflicts When Run Alongside the Local Claude Stack

Anthropic's official docs already lay out the marketing-grade upsides well, so this analysis concentrates on the friction that is structurally inevitable when you run it next to the local Claude stack — not observed from running both side by side, but read off both planes' docs, definitions, and permission models to mark where they collide by design.

1. The source of truth for the agent definition splits into two places. The local plane scatters the definition across AGENTS.md, .claude/skills, local MCP, and the Memory tool, and assumes immediate editing. The hosted plane bundles model · system prompt · tools · MCP servers · skills once, seals it under an agent ID, and a session merely points at the seal. Put the same agent on both sides and there's no answer to which definition is canonical — fix one side and the other doesn't know. That this isn't speculation is proven by the boundary the same company drew itself. Anthropic's branding guidelines permit "Claude Agent" but prohibit the "Claude Code" and "Claude Cowork" names, their ASCII, and imitation of their visual elements — the same vendor explicitly drawing product boundaries is a signal it has no intention of merging the two planes into one. The single source of truth breaks first at the very place that should be coherent: the same vendor.
2. The permission gate operates on a different model per plane. The eight hosted built-in tools (agent_toolset_20260401) run automatically, without confirmation under a default permission_policy: always_allow, while MCP tools default to always_ask. Local Claude Code gates via the allow/deny lists in settings.json plus user confirmation. Wire the same MCP server into both sides and a permission decision passes through two separate models — an action denied locally may be always_allow in the hosted plane, and the difference isn't visible until call time. When two permission models overlap on one call path, things slip through.
3. The source of truth for cross-session learning also accumulates in two places. The local plane builds up state via the Memory tool and session learning. The hosted plane builds up state in a server-side persisted session filesystem and append-only events. Run the same agent on both sides and learning accumulates separately in two stores, and which one is currently canonical is once again undecided. This isn't a new problem — it's the "single source of truth for memory" breakage that the agent memory category dissected, reproduced verbatim one more time in the same vendor's hosted plane.
4. Audit is too persistent and the definition is too volatile. The append-only event log accumulates outside the container and survives a harness restart, so an audit record comes for free. But delete permanently erases event history — the only exit is deletion, and that deletion destroys the compliance record itself. At the same time, changing an agent-by-ID definition changes the behavior of every session referencing that ID wholesale, whereas local assumes the exact opposite — immediate editing. If AWS Agent Registry's "edit → revert to DRAFT → re-approve" bound the lifecycle too tightly, this is the opposite pole — hosted is too persistent (deletion is the only exit) and local is too volatile, so running both at once means no coherent change lifecycle holds.
5. Where the trust boundary is drawn differs per plane. The hosted vault credential proxy keeps secrets out of the sandbox and injects them server-side at tool-call time — a strength that structurally closes the prompt-injection theft path. Yet in the same plane, MCP sits outside Anthropic's security perimeter, so "your application is the trust boundary," and egress runs through a JWT auth proxy + TLS inspection, where even in limited mode six Anthropic infrastructure hosts (sentry.io, staging, etc.) are silently injected into the egress JWT — a compliance team can't document the actual egress scope without reverse-engineering the JWT. The local stack controls egress directly, so the boundary is in one place. The location and visibility of the trust boundary differ per plane — when the same call moves between planes, the trust boundary moves invisibly.
6. The unit of "who has the right to kill or see what" is drawn differently per plane. The local stack can split keys per project and per user, finely dividing who can see and kill which scope of sessions. The hosted plane is the opposite — a single org-level API key accesses every session and the entire event history with no fine-grained role separation, so the permission boundary for audit and observability is drawn only as one undivided org-wide block. Who looks into which session and kills it where — the granularity of audit/observability rights — is drawn differently per plane. The point is that the same vendor drew that boundary with its own hand: splittable for local, unsplittable for hosted. A key leak blasting its radius across the entire org is a byproduct of this asymmetry, not the essence — the essence is that the granularity of audit/observability rights differs by plane.
7. The Claude Platform on AWS crossover makes it a three-way plane split. Managed Agents is also offered on Claude Platform on AWS (with feature and session behavior differences). The moment you run it on AWS, the governance planes number three — AWS Agent Registry + Anthropic Managed Agents + the local Claude stack. Here the friction of AWS Agent Registry — single-choice auth model, naming collisions, lifecycle reversion, and the rest — meets this hosted plane's conflicts head-on. Registration/discovery friction and hosting-side fragmentation cross over on the same resource, and friction between different vendors and a split one vendor drew with its own hand land on a single call path at once.

All seven are variations on the same pattern — the model company itself assumes a multi-source local plane and a single-source hosted plane, and split the two into different API planes. If AWS Agent Registry's friction was a collision of assumptions between different vendors, here the cause of the collision is a boundary the same vendor drew with its own hand — which is why the single-source decision breaks first, and deepest, at the very place that should be most coherent: the same vendor.

Synthesis

The governance index narrowed next quarter's operating question down to which plane do you treat as the single source of truth. AWS Agent Registry is the cross-vendor version of that question — cloud Registry or local stack as canonical — and this is the intra-vendor version. And the intra-vendor version is the heavier one. Cross-vendor fragmentation is explained by different vendors, different assumptions, but here the same company drew the boundary between the local plane and the hosted plane with the same hand. The branding guideline spelling out the product boundary as "don't call this Claude Code" is the evidence — a signal of no intent to merge — and so stitching the two planes into one source of truth is not something the vendor will do for you. The single-source decision falls wholesale onto the operator.

The crux is that this decision is not a deferrable option. Because the SDK sets the beta header automatically, Managed Agents is already on for every API account — a team running the local stack automatically enters a state of running both planes at once without deciding anything. Defer the decision and the next governance layer forces it for you — the conclusion from AWS Agent Registry sharpens one notch further here: in the intra-vendor seat, that layer has already arrived and is switched on by default. The very choice to defer is itself a decision to promote the hosted plane to an implicit shadow source of truth — definition, permissions, memory, and audit split across two places, operated with no one declaring which is canonical. The worst form of governance fragmentation is not the fragmentation itself but running it without realizing you're fragmented, and enabled-by-default makes exactly that the default state.

One-line recommendation. Teams for whom long-running, async workloads are the whole point, and for whom the value of delegating orchestration/sandbox/session-persistence infrastructure exceeds the price of accepting an org-level key blast radius, should move to hosted and demote the local definition to a mirror. Teams that must control key blast radius per project and per user, must document and control egress scope themselves, or whose workflow's essence is the immediate-edit loop should stay local and not use hosted. Keeping both while declaring neither canonical is the one wrong answer.

References

• Claude Managed Agents — Overview (Anthropic Platform Docs)
• Inside Claude Managed Agents (Pluto Security)
• What Is Anthropic Managed Agents (MindStudio)
• Claude Managed Agents: What It Actually Offers — The Honest Pros and Cons (Medium, unicodeveloper)
• Agent Governance category index — the 4-axis · 3-breakpoint frame
• AWS Agent Registry — the cross-vendor version of the same question
• Agent Memory series — where the single-source-of-truth-for-memory breakage reproduces in the hosted plane
• MCP series — the starting point of "the remaining problem is operations," and where the hosted plane is the model company's own answer to that operations problem
• ECC — the adjacent movement of AgentShield security scanning (security hardening at the metaframe plane)