What is Claude Managed Agents?

1. The outcomes model: working until the job is done

The deepest conceptual shift in Managed Agents is the move from calls to outcomes. When you use the Claude API directly, you think in terms of requests and responses: you send a prompt, you get a completion. Each interaction is discrete. This is perfectly fine for many tasks, but it is a poor fit for work that takes multiple steps, requires back-and-forth with tools, or needs to continue across interruptions.

Managed Agents flips this model. You define the task and the success criteria upfront, give the agent the tools it needs, and Claude works until the job is done — iterating, using tools, storing intermediate results, and recovering from errors — without you needing to manage each step. From your application’s perspective, you submit a task and eventually get a result. What happens in between is the agent’s concern.

This is a more powerful abstraction but it requires a different mental model for developers. You are not writing prompt engineering code that gets executed once; you are defining an agent’s capabilities, constraints, and goals, and then trusting the runtime to execute them. The shift is analogous to the shift from writing bash scripts to writing declarative infrastructure as code: you describe the desired end state rather than the exact steps to get there.

The practical implication is that Managed Agents is particularly powerful for tasks that would otherwise require polling loops or chained API calls from your application code. Instead of calling Claude five times to break a task into subtasks, assigning those subtasks, collecting the results, merging them, and returning a final answer — you describe the task once and let the orchestration layer handle the decomposition.

2. Architecture deep dive: the four layers

Agent Sessions are the outermost container for a unit of work. A session tracks the task from submission to completion, including all intermediate steps, tool calls, memory reads and writes, and subagent invocations. Sessions can be long-running — persisting across hours or days if needed — or short-lived for quick tasks. The session layer handles retries when tools fail, provides a consistent identity for memory lookups, and exposes status and logs to your application.

Memory Stores exist at two levels. Working memory is the context window itself: the conversation history, tool call results, and intermediate reasoning within a single agent run. This is automatically managed by the session layer — you do not need to worry about how to pack information into the context window. Long-term memory is a managed key-value and vector store that persists across sessions. When an agent completes a task, it can write important findings to long-term memory. Future sessions can retrieve that information, enabling agents that genuinely learn and accumulate knowledge over time.

The Tool Runtime is the secure execution environment for agent actions. Tools come in two broad categories: integration tools (web search, file system, database queries, API calls via MCP) and computer use (browser control, desktop interaction). All of these run in sandboxed environments managed by Anthropic, with configurable permissions so you can grant your agent exactly the access it needs and no more. The MCP integration is particularly important: because MCP is a standard protocol, any MCP server — whether built by Anthropic, a third party, or your own team — becomes a tool your agent can use.

Multi-Agent Orchestration allows you to compose agents into networks. The most common pattern is an orchestrator-worker topology: a top-level orchestrator agent breaks a large task into subtasks, dispatches each subtask to a specialist worker agent, and aggregates the results. Worker agents can be specialized by function (a research agent, a coding agent, a review agent) or by domain knowledge. The orchestration layer handles the message passing between agents, ensures results are routed back correctly, and manages parallel execution of independent subtasks.

3. Computer use integration

Computer use changes what is possible for agents in a fundamental way. Most APIs and data sources in the world do not have an MCP server or a well-documented REST API. They have websites. Computer use lets your agent interact with any web-based system by operating a browser just as a human would: navigating to pages, clicking buttons, filling forms, reading content.

In the Managed Agents context, computer use sessions are fully managed and sandboxed. You do not need to provision a browser environment, handle screenshot capture, or manage session state. You configure computer use as a tool in your agent’s toolkit and the platform handles the rest. The agent can use computer use alongside API-based tools within the same session, making decisions about which approach is most efficient for each subtask.

The practical use cases are broad: scraping data from sites without APIs, operating legacy internal tools that only have web interfaces, automating form submissions, and testing web applications from a user’s perspective. Combined with long-term memory, an agent can remember what it learned from previous computer use sessions, avoiding redundant navigation and building up knowledge about site structure over time.

4. Choosing your Claude deployment model

The three options — raw Claude API, Claude Code, and Managed Agents — serve different needs. The raw API is the most flexible and cheapest option, appropriate whenever you control the orchestration logic yourself and do not need persistence. Claude Code targets developers and is optimized for coding workflows: it integrates with terminals, editors, and CI systems and has a UX designed around code navigation and modification. Managed Agents is the right choice when you are building a product that ships agents to users who are not themselves developers, or when the agent needs persistent memory, complex multi-step workflows, or computer use.

The decision also depends on your team’s engineering capacity. Managed Agents has a higher initial configuration cost than a simple API call, but that investment pays off quickly if your agent has complex state management needs. Teams that start with raw API calls and then need to add memory, retry logic, and multi-agent coordination often end up rebuilding a poor version of what Managed Agents provides — and spending significantly more time doing it.

🧠 Check your understanding

5 questions · your answers are saved in this browser only

1. 1. What does the 'outcomes model' in Managed Agents mean?

   Agents are billed per outcome rather than per token You define the task and success criteria once; the platform handles all the steps to completion Agents can only produce structured JSON outputs Managed Agents automatically validates that outputs meet quality standards

   The outcomes model means you submit a task and desired end state; the platform iterates, uses tools, manages memory, and works until the job is done — rather than requiring you to manage each individual step from your application code.

2. 2. What are the two levels of memory available in Managed Agents?

   RAM and disk storage Vector memory and relational memory Working memory (context window within a session) and long-term memory (persists across sessions) Public memory and private memory

   Managed Agents provides working memory — the context window managed within a session — and long-term memory, a persistent store that agents can write to and retrieve from across multiple sessions.

3. 3. In a multi-agent orchestrator-worker topology, what is the role of the orchestrator?

   Executing individual tool calls as efficiently as possible Breaking large tasks into subtasks, dispatching them to specialist workers, and aggregating results Monitoring agent sessions for errors and restarting them when they fail Translating between different MCP server protocols

   The orchestrator decomposes a large task into subtasks, delegates them to specialist worker agents, and aggregates the results. Workers are specialized by function or domain; the orchestrator handles coordination.

4. 4. Why is computer use significant within the Managed Agents platform?

   It is cheaper than using MCP tool integrations It lets agents interact with any web-based system even without an API, operating a browser as a human would It replaces the need for long-term memory It is required for all Managed Agents integrations

   Computer use lets agents interact with web-based systems that lack APIs or MCP servers — navigating pages, clicking, reading content — vastly expanding what agents can access. It runs in a sandboxed managed environment within Managed Agents.

5. 5. When is the raw Claude API a better choice than Managed Agents?

   When you need agents that operate across multiple sessions When you want to use computer use to interact with websites When the task is a single stateless generation — classify text, answer a question, generate a draft When you need multi-agent orchestration

   The raw API is optimal for stateless, single-step tasks. Managed Agents adds infrastructure overhead that only pays off for multi-step, stateful tasks that require persistence, tool use, or agent coordination.

Reset quiz

🛠️ Build it yourself

Follow these exact steps to reproduce it yourself

1. Write your task statement — Describe in one paragraph what your agent should be able to do. Be specific about inputs (what the agent receives), outputs (what it produces), and the scope of work in between.
2. Identify the state you need — List everything that needs to persist: user preferences, task history, domain knowledge your agent accumulates over time. This becomes your long-term memory schema.
3. List all tools your agent needs — For each external system your agent interacts with, classify it: does it have an MCP server or REST API (use integration tools), or does it only have a web interface (use computer use)?
4. Decide on orchestration pattern — Can one agent handle the full task, or does the workload naturally decompose into parallel subtasks handled by specialists? Draw a simple diagram of your agent topology.
5. Define success criteria — How will your agent (and your platform) know the task is done? Write explicit criteria that can be evaluated programmatically or by a review step.
6. Configure permissions minimally — Grant your agent only the tool access it actually needs. Start with the minimum viable set and add permissions as you confirm they are required.
7. Plan for failures — Think through the ways your agent might fail: tool errors, ambiguous tasks, rate limits. Decide which failures should trigger retries, which should surface to the user, and which should trigger a different agent strategy.