Claude Managed Agents: what it is, what it costs and when to use it

Claude Managed Agents is Anthropic's answer to a problem every team building agents runs into: the model is the easy part, the infrastructure around it is not. You need a loop that calls tools, a sandbox where the agent can run code without touching your servers, state that survives a pause, a way to stop it mid-task, and logs of what it did. Managed Agents gives you that as a hosted service.

This guide covers what it is, how the pieces fit together, what it costs, how permissions work, and what a European company should check before putting real data through it. Facts are from Anthropic's documentation as of October 2026. The product is in beta, so verify the details against the official docs before you build on them.

What Claude Managed Agents is

Anthropic offers two ways to build with Claude on the API. The Messages API gives you direct model access: you send a prompt, get a response, and build any agent loop yourself. Claude Managed Agents is a pre-built, configurable agent harness that runs in Anthropic's infrastructure and is aimed at long-running and asynchronous work.

In practice that means Claude can read and write files, run shell commands, search and fetch from the web, and call MCP servers, inside a sandbox, for minutes or hours, while your application streams the events and can steer or interrupt it. The harness handles prompt caching and compaction (summarising old context so long sessions keep fitting in the window) for you.

It is in beta. Every request needs the managed-agents-2026-04-01 beta header (the SDKs set it automatically), and access is enabled by default for API accounts. It is also available on Claude Platform on AWS, with some differences in features.

The four core concepts

The flow is: create an agent, create an environment, start a session that references both, send a user message, and read the event stream as Claude works. You can send more messages mid-run to redirect it, or interrupt it. Sessions are stateful: the filesystem and conversation history persist, so a session can pause for hours and pick up where it left off.

Anthropic also lists scheduled deployments for running an agent on a cron schedule, and multiagent sessions where a coordinator delegates work to other agents.

Built-in tools and MCP servers

The built-in toolset is called agent_toolset_20260401 and contains:

All are on by default. You can switch individual tools off, or start with everything off and enable only what the job needs:

{
  "type": "agent_toolset_20260401",
  "default_config": { "enabled": false },
  "configs": [
    { "name": "read", "enabled": true },
    { "name": "grep", "enabled": true }
  ]
}

web_search and web_fetch accept allowed_domains or blocked_domains, up to 64 domains per list. That is the only way to restrict them in Managed Agents. The organisation-level web settings in the Console apply to the Messages API, not to Managed Agents sessions.

MCP servers are declared on the agent by name and URL (remote servers only, up to 20 per agent). Credentials are not part of the agent definition. They live in vaults, which you attach when you start a session with vault_ids. Vaults support static bearer tokens and MCP OAuth. Keeping secrets out of the agent definition is the right design: the same agent can run for different teams with different credentials. You can also limit an MCP toolset to the specific tools you have reviewed, which is worth doing for servers that expose dozens of tools. For background on MCP itself, see our MCP guide.

You can add custom tools as well. Claude emits a structured call, your application runs it and sends back the result. Permission policies do not apply to custom tools, because your code decides whether to run them.

Permission policies: who approves what

This is the part that matters most for production use. Every server-executed tool, built-in or MCP, has a permission policy:

The defaults are deliberately different. The built-in toolset defaults to always_allow. MCP toolsets default to always_ask, so a tool that a server operator adds later does not start running in your environment without anyone noticing.

When a call needs approval, the session goes idle with stop_reason.type: "requires_action", and you answer with a user.tool_confirmation event (allow or deny, optionally with a deny_message explaining why). Webhooks can notify you when a session is waiting. Idle time while waiting does not count as billable runtime.

Two details from Anthropic's documentation are worth taking literally:

• auto is not a human checkpoint. If the server judges a call safe, it runs before anyone sees it. For anything irreversible (deleting data, sending email, writing to production), use always_ask.
• User messages count as intent. Under auto, what you post in user.message can lead the server to allow a call it would otherwise deny. Tool results and fetched pages do not count. If you forward untrusted end-user input as user messages, that input can get calls approved. Put always_ask on the tools you would not let that end user run unreviewed.

Every tool-use event carries evaluated_permission (allow, ask or deny) and an evaluation object recording which policy decided. Store those in your audit log, since they show why each call ran.

A sensible starting point for a business agent: the agent toolset on always_allow with bash on always_ask, MCP servers on always_ask with only reviewed tools enabled, and web tools limited to an allowlist.

What Claude Managed Agents costs

Pricing has two parts.

Tokens at normal Claude API rates. Prompt caching multipliers apply. The Batch API discount does not, because sessions are interactive. Web search costs $10 per 1,000 searches.

Session runtime at $0.08 per session-hour, measured to the millisecond, and only while the session status is running. Time spent idle (waiting for your next message or a tool confirmation), rescheduling or terminated is free. Runtime replaces the container-hour billing of the code execution tool, so you are not charged twice.

Anthropic's own worked example: a one-hour coding session on Claude Opus 5 with 50,000 input tokens and 15,000 output tokens.

With 40,000 of the input tokens served from cache, the total drops to about $0.53.

The takeaway: runtime is rarely the cost driver. Tokens are, and they grow with how much context the agent reads, how many tool calls it makes and which model it runs on. A session that reads large files or web pages on Opus can cost many times the example. The usual levers apply: a smaller model where it is good enough, prompt caching, max_content_tokens on web_fetch, and a budget per agent that someone actually watches. We cover the same levers for Claude Code in Claude Code pricing and cost control.

Managed Agents, the Agent SDK or the Messages API?

Rule of thumb: if the agent's job takes minutes or hours, needs a filesystem, and you would rather not operate sandboxes, Managed Agents saves real engineering time. If the agent handles regulated data, has to run in a specific region, or must sit behind your existing controls, the SDK or the Messages API through an EU cloud region gives you more control today. For a framework-neutral walkthrough of building an agent, see How to build AI agents.

Where the data lives: what EU companies should check

This is where Managed Agents is weakest for European companies right now, and it is easy to miss because the docs spread it across several pages.

• Inference geo: only us and global are available. You can pin an agent's inference_geo to us (at 1.1× token price), but there is no EU option.
• Workspace geo, where data is stored at rest: currently only us.
• Zero Data Retention: Managed Agents is not eligible, because sessions store conversation history, sandbox state and outputs server-side. You can delete sessions and uploaded files through the API.
• Self-hosted sandboxes: tool execution and the sandbox filesystem stay on infrastructure you control. Model calls and session history still go through Anthropic, and attached memory stores stay with Anthropic and are copied to your sandbox.

None of this rules Managed Agents out. An agent that works on public documentation or open-source code may have no personal data in it at all. But for an agent that reads customer tickets, HR records or invoices, the question "where is this processed and stored, and under which agreement?" needs a clear answer from your DPO before go-live, the same as for any other processor. Our AI governance guide covers how to set up that review without stalling every project.

A production checklist

Before a Managed Agents session touches real systems:

1. One narrow job per agent, with a written definition of done and a test set of real cases.
2. Least privilege: only the tools the job needs, MCP tools limited to the reviewed list, web tools on an allowlist.
3. always_ask on anything irreversible, not auto.
4. Credentials in vaults, scoped per team or customer, rotated on a schedule.
5. Audit log: store every tool-use event with evaluated_permission and the evaluation reason.
6. Budget and alerting per agent, on tokens, not only on runtime.
7. Data classification: decide which data the agent may see, given US inference and storage in the beta.
8. An owner: one named person accountable for each agent, as for any system with write access.

Where to go next

• What is agentic AI?: the concepts behind agents.
• How to build AI agents: the decisions in the right order, whatever the platform.
• What is an MCP gateway?: one control point for many agents and MCP servers.
• MCP security best practices: what to lock down before agents get tools.

If your agents need to run with EU inference, budgets per team and one log across Claude, Codex and approved MCP servers, inside your own Azure tenant, see the Walma AI Hub or our custom solutions.