Claude Managed Agents is Anthropic's hosted agent harness: instead of building your own agent loop and sandbox, you define an agent, and Anthropic runs the loop with a managed container per session. The multiagent capability extends that model — one coordinator agent can delegate tasks to other agents within a single session, so a "research lead" can hand subtasks to a "code reviewer" and a "report writer," each configured differently, without you orchestrating anything between them. Everything below applies to the Managed Agents beta, which requires the managed-agents-2026-04-01 beta header and is available on the first-party Claude API and Claude Platform on AWS only — not Bedrock, Vertex AI, or Foundry.
How a coordinator is declared
Multiagent is configured on the agent object itself, not in the tools list. The coordinator agent carries a top-level multiagent field of the form {"type": "coordinator", "agents": [...]}, where the roster entries are other agent IDs, version-pinned references ({"type": "agent", "id": ..., "version": ...}), or {"type": "self"} — meaning the coordinator can spawn copies of its own configuration. Because Managed Agents treats agents as persistent, versioned resources, the roster is stable configuration you create once, not something assembled per request; pinning versions gives you reproducible delegation behavior even as roster agents evolve.
The documented limits: up to 20 unique roster agents (multiple copies of the same agent are allowed), a maximum of 25 concurrent threads, and — importantly — one level of delegation only. A roster agent that itself declares a multiagent roster does not get a sub-roster at runtime; depth greater than one is ignored. If your design calls for delegation trees, flatten them: put every specialist on the coordinator's roster directly.
Shared workspace, isolated minds
The isolation model is the part worth internalizing. All agents in the session share the same container and filesystem — the coordinator can write /workspace/brief.md and a roster agent can read it, which makes plain files the natural hand-off mechanism for large artifacts. But each agent runs in its own persistent thread with an isolated conversation history and its own model, system prompt, tools, MCP servers, and skills, exactly as defined on that agent's object.
| Shared across agents | Isolated per agent (thread) |
|---|---|
| Container and filesystem | Conversation history |
| The session and its lifecycle | Model choice and system prompt |
| Session resources (mounted files, repos) | Tools, MCP servers, and skills |
This split is what makes specialist rosters economical and safe at once: a cheap, fast model can handle mechanical subtasks while the coordinator runs a stronger model, and a roster agent with no MCP servers configured simply cannot call the coordinator's — capability boundaries are per-agent configuration, not prompt-level promises.
One stream to watch
Operationally, multiagent sessions stay pleasantly single-threaded from the client's perspective. Per-thread endpoints exist under /v1/sessions/{session_id}/threads/... (list, retrieve, archive, and list or stream a thread's events) when you want to inspect a specific specialist's transcript, and the session's status aggregates the statuses of its threads. But the design assumption is that clients watch the primary session stream: when a roster agent needs a tool confirmation (a permission policy of always_ask) or requests a custom client-side tool, that request is cross-posted to the primary thread tagged with a session_thread_id. Your application answers on the session stream as usual — no juggling of per-thread SSE connections just to keep subagents unblocked.
When to reach for it
Use multiagent coordination when subtasks genuinely benefit from different configurations (models, tools, skill sets) or from clean, separate contexts — long research-and-produce pipelines, review gates, parallel fan-out over independent work items within the 25-thread ceiling. Skip it when a single agent with a good system prompt would do; every roster agent is another versioned resource to manage. And since some of the finer behaviors above are beta-stage details, verify current limits against the official documentation before you commit an architecture to them.
Where to go next
New to Managed Agents? Start with Agent SDK vs. Managed Agents for the build-vs-host decision, then sessions and their lifecycle and vaults for MCP credentials — both apply unchanged to multiagent sessions.