On April 8, 2026, Anthropic launched Claude Managed Agents in public beta. It is a hosted runtime for AI agents – the missing piece between building an agent and operating one at scale. This article covers what it is, how it differs from previous Anthropic offerings, and what it means for governance platforms like WorkingAgents.
What Claude Managed Agents Is
A hosted execution environment for long-running AI agents, accessible through the Claude Platform at platform.claude.com. Anthropic runs the containers, persistence, sandboxing, and authentication. You define what the agent does. Anthropic handles the operations.
The product sits inside a stack Anthropic has been building for two years:
- Models – Claude Opus, Sonnet, Haiku (the brains)
- Protocols – MCP for tools, Agent Skills as an open standard
- Developer tools – Claude Code, Claude Agent SDK (the loop, as a library)
- End-user agent products – Claude Cowork
- Enterprise runtime – Claude Managed Agents (the new piece)
Until now, if you wanted to deploy a Claude-powered agent into production, you had two options. You could build directly against the Messages API and write your own loop, your own tool dispatcher, your own session persistence, your own sandbox. Or you could use the Claude Agent SDK – the same loop that powers Claude Code, packaged as a Python or TypeScript library. Either way, you were responsible for hosting, scaling, monitoring, secrets management, and recovery.
Managed Agents removes that operational layer. You define an agent and call an API. Anthropic runs the containers, manages credentials, persists sessions, and streams events back to your application.
The Architecture
Anthropic’s engineering blog describes the architecture as three decoupled pieces:
Session – an append-only log of everything that happened in the conversation. Lives outside the harness. Survives restarts. You can wake a session by ID and pick up where it left off. This is the durable state of your agent.
Harness – the loop that calls Claude, parses tool requests, and routes them to infrastructure. This is the part that decides “the agent wants to run a bash command, send it to the sandbox” or “the agent wants to read a file, fetch it from the persistent volume.”
Sandbox – a secure execution container with pre-installed runtimes (Python, Node.js, Go), file system access, network controls, and the ability to run shell commands. Each session runs inside its own sandbox.
This decoupling matters because it lets Anthropic optimize each piece independently. They report that the new architecture cut p50 time-to-first-token by 60% and p95 by over 90% compared to what Claude Code’s original loop achieved. Sessions can be paused and resumed without losing state. Sandboxes can be replaced without breaking the conversation history.
What You Get Out of the Box
The runtime includes a substantial set of built-in capabilities:
Tools:
- Bash and shell command execution
- File operations (read, write, edit, glob, grep)
- Web search and web fetch
- MCP server connections to external tools
- The full Claude Code toolset, available without configuration
Infrastructure:
- Sandboxed code execution with pre-installed languages
- Configurable network access rules
- Persistent file systems across interactions
- Server-sent-events streaming of tool results and status updates
- Mid-execution steering – you can interrupt the agent with new instructions
- Server-side event-history persistence with full retrieval
- Built-in prompt caching and context compaction
- Durable sessions that survive harness restarts
- OAuth credential vaulting with an MCP proxy pattern – Anthropic specifically notes that “credentials are never reachable from the sandbox where Claude’s generated code runs”
- Scoped permissions, identity management, execution tracing
- Session analytics in the Claude Console
Research preview features (gated):
- Outcomes (self-evaluation and iteration)
- Multi-agent coordination
- Persistent memory
These are behind a separate waitlist and not generally available.
Pricing
Consumption-based, layered on top of standard token costs:
- Standard Claude API token rates for model usage (no change)
- + $0.08 per session-hour of active runtime, billed in milliseconds
- + $10 per 1,000 web searches when the web-search tool is used
This is significantly cheaper than running your own Kubernetes cluster with autoscaling, secrets management, and observability tooling, especially for sporadic agent workloads.
How It Compares
| Messages API | Agent SDK | Managed Agents | |
|---|---|---|---|
| Model access | Yes | Yes | Yes |
| Agent loop | DIY | Library | Managed |
| Sandbox | DIY | DIY | Managed |
| Session persistence | DIY | DIY | Managed |
| Secret management | DIY | DIY | Managed |
| Tool dispatch | DIY | Library | Managed |
| Hosting | Self | Self | Anthropic |
| Speed to production | Slowest | Fast | Fastest |
| Operational control | Highest | High | Limited |
| Compliance requirements | DIY | DIY | Anthropic-managed |
The trade-off is the classic build vs. buy decision. Managed Agents gets you to production in days. Self-hosting gives you complete control over every aspect of the runtime, which matters for regulated industries with data residency requirements.
Early Adopters
Anthropic’s launch named several enterprise customers already in production:
- Notion – Custom Agents for document automation (private alpha)
- Rakuten – cross-department enterprise agents
- Asana – AI Teammates for project management
- Vibecode – automated app deployment
- Sentry – debugging and patch generation
The branding rules in the developer docs are telling. Partners are expected to embed Managed Agents inside their own products with phrasing like “{YourAgentName} Powered by Claude.” Anthropic is positioning Managed Agents as the OEM infrastructure other companies build on top of, while keeping Claude Code and Claude Cowork as their own first-party brands. This is the same playbook Microsoft used with Azure OpenAI Service: provide the runtime, let customers brand the experience.
What This Means for WorkingAgents
WorkingAgents is a governance platform. It sits between AI agents and the systems they interact with – enforcing permissions, auditing tool calls, managing credentials, and providing the policy layer that organizations need before they can deploy autonomous agents at scale.
Claude Managed Agents is a runtime. It executes agents. It does not, by design, govern them across an organization.
These two systems operate at different layers. Understanding the relationship is essential for organizations deciding how to deploy agents responsibly.
Where Managed Agents Stops
Anthropic’s offering provides:
- Sandboxing of the agent’s execution environment
- Credential isolation from the sandbox itself
- Per-session identity and authentication
- Network access rules at the container level
- Audit logs of tool calls within a session
What it does not provide:
- Cross-agent governance – if you run 50 agents for 50 teams, Managed Agents doesn’t enforce policies that span them
- Organization-wide permission management – there’s no concept of “the marketing team can access these MCP tools, the engineering team can access those”
- Tool catalog governance – Managed Agents executes whatever MCP tools you connect, with no central registry of approved tools
- Multi-tenant access control – each session is its own context, not part of a broader user or role hierarchy
- Compliance reporting at the organization level – per-session traces exist but aggregating them into compliance evidence is on you
- Approval workflows for high-risk actions – the runtime can execute anything its tools allow, with no human-in-the-loop policy enforcement
- Cost attribution per user, team, or department – billing is per-session, not per-organizational-unit
These are not gaps in Anthropic’s design. They are the layer above the runtime, and that layer is exactly where governance platforms operate.
Where WorkingAgents Sits
WorkingAgents provides:
- Permission keys per module – each integrated service (Drive, Sheets, Gmail, NIS CRM) has its own permission key, and users only see tools they’re authorized to call
- Permission-aware MCP gateway – agents connecting to WorkingAgents see only the tools their identity allows
- Real-time permission revocation – when access is removed, the next tool call is blocked, regardless of whether the agent is mid-conversation
- Audit logging at the application layer – every tool call is captured with the user identity, arguments, result, and timestamp
- Cross-tool governance – a workflow can chain Drive + Sheets + Pushover and the entire flow is governed under a single policy
- Approval gates – workflow steps can pause and require human approval before proceeding
- Module ownership – each integrated service owns its data, its permissions, and its lifecycle, with no cross-contamination
WorkingAgents is designed around the principle that the agent runtime is a separate concern from the agent governance layer. The two should be replaceable.
The Combination
For organizations deploying Claude-powered agents at scale, the two systems are complementary. A practical architecture:
- Claude Managed Agents runs the agent itself – the loop, the sandbox, the session
- WorkingAgents provides the MCP server that the agent connects to for tool access
- The agent’s MCP connection in the Managed Agents config points to a WorkingAgents instance
- Every tool call from the agent passes through WorkingAgents’ permission layer
- WorkingAgents enforces the policy, logs the action, and either permits or denies the call
- Approved calls reach the underlying service (Google Drive, internal API, database)
- Denied calls return a structured error to the agent
This gives you the speed-to-production of Managed Agents with the organizational governance of WorkingAgents. Anthropic handles the runtime so your team doesn’t have to. WorkingAgents handles the policy so you can prove to security, legal, and compliance that the agent is operating within bounds.
What Managed Agents Does Not Replace
For organizations evaluating whether they still need a governance layer after adopting Managed Agents, here are the questions to ask:
Can a security auditor reconstruct exactly what every agent in our organization did over the past 90 days, broken down by user and department?
Managed Agents alone: per-session logs exist, but aggregating them across hundreds of sessions and mapping them to organizational identities is on you. WorkingAgents: every tool call is logged with the user identity at the gateway level, queryable from a single audit log.
When we revoke an employee’s access, does every running agent immediately stop being able to act on their behalf?
Managed Agents alone: depends on how you’ve structured authentication tokens. If the agent has a long-lived OAuth token in its credential vault, it may continue operating. WorkingAgents: permission revocation takes effect on the next tool call, no grace period.
Can different teams in our organization use different subsets of tools, with central governance over who can access what?
Managed Agents alone: each session can be configured with different tool sets, but managing that across hundreds of sessions and dozens of teams becomes operational overhead. WorkingAgents: permission keys define exactly which modules each user can access, applied uniformly across every session, every framework, every transport.
When an agent attempts a high-risk action (delete a record, send an external email, transfer money), can we require human approval?
Managed Agents alone: not built in – you’d need to handle this in your tool implementations. WorkingAgents: workflow approval steps pause execution until a human authorizes the next step, with notifications via Pushover, WhatsApp, or email.
Can we enforce that certain kinds of data never leave certain perimeters, regardless of which agent is running?
Managed Agents alone: network rules are per-container. Cross-cutting data classification policies are not built in. WorkingAgents: permissions and audit logs run at the application layer, so policies like “the marketing agent cannot read salary data” are enforced regardless of which model or framework is in use.
These are not theoretical concerns. They are the questions that show up when an enterprise security team reviews an AI agent deployment. Managed Agents solves the runtime problem. The governance problem requires a separate layer.
The Strategic Picture
Anthropic’s launch of Claude Managed Agents validates a thesis that governance platforms have been operating on for the past year: the runtime is becoming a commodity. Every major model provider will eventually offer hosted agent execution. The differentiation will move up the stack – to the policies, the integrations, the audit trails, the compliance evidence, and the workflows that turn an isolated agent into part of a coordinated business operation.
For WorkingAgents, this is good news. The emergence of standardized agent runtimes makes the governance layer more important, not less. When the runtime is no longer the hard part, the question becomes: how do you make sure the agent does the right thing? That question is exactly what governance platforms exist to answer.
Managed Agents is a powerful tool for organizations that want to deploy Claude-powered agents quickly. WorkingAgents is the policy layer that makes those agents safe to deploy at scale, across teams, with the audit trails and access controls that real businesses require.
You need both.