Claude Managed Agents explained: what B2B teams need to know before choosing managed or self-hosted

Claude Managed Agents are Anthropic's hosted orchestration infrastructure for running Claude-based AI agents. They handle agent routing, state management, and lifecycle without teams needing to build or maintain that layer themselves. The choice between managed and self-hosted orchestration is an infrastructure commitment that determines who owns operational complexity once the agent is live.

Graph Digital built Katelyn on Claude Managed Agents in production. The same team has designed self-hosted orchestration architectures for client builds. Both approaches work. Neither is universally correct. What follows is a practitioner account of the decision, not a product endorsement.

What Claude Managed Agents actually do — and what they don't

Claude Managed Agents provide three capabilities that self-hosted orchestration requires teams to build and maintain independently.

Agent runtime — the infrastructure that executes agent steps: receiving inputs, invoking tools, processing outputs, and managing the sequence of actions across a multi-step task. In self-hosted orchestration, this is custom code. In Claude Managed Agents, Anthropic operates it.

State management — maintains context across multi-step agent runs: tracking what the agent has done, what it knows, what decisions it has made, and where it is in a task sequence. Without state management, agents lose coherence between steps. Claude Managed Agents handle this at the infrastructure level.

Routing logic — directs tasks between agents or sub-agents in multi-agent systems: determining which agent handles which input and how control passes between them. In complex agent pipelines, routing is a non-trivial engineering problem. Claude Managed Agents abstract it.

What they do not provide: deep integration with proprietary enterprise systems via custom connectors, data residency guarantees across all regulatory jurisdictions, or full observability into agent execution for heavily regulated environments where audit trails must be internally controlled.

For CTOs and Heads of Technology: The decision is not "do we trust Anthropic?" It is "does managing this infrastructure layer ourselves produce better outcomes than delegating it?" That is a capacity question, not a trust question.

Gartner projects that fewer than 5% of enterprise workflows used AI agents in 2025, while 40% of enterprise AI deployments will involve task-specific agents by 2026. Teams building now are setting the infrastructure foundation for a deployment curve that will accelerate sharply. The orchestration decision made at this stage determines operational capacity at that scale. Teams that defer it typically rebuild from the foundation once agent deployment volume grows.

How Claude Managed Agents work: the orchestration layer explained

Claude Managed Agents are Anthropic's implementation of what the industry categorises as managed agentic runtime or hosted agent orchestration: the infrastructure layer that handles orchestration layer selection for teams building agentic systems architecture at production scale. This is the category context for the managed vs self-hosted decision that follows.

The orchestration layer sits above the model and below the application. The model (Claude) receives inputs and produces outputs. The application delivers value to users. The orchestration layer coordinates everything between the two: it decides what the agent does next, maintains state across steps, handles failures, routes to sub-agents when needed, and manages the lifecycle of a task from start to completion.

In a self-hosted architecture, the team writes and operates this layer. In Claude Managed Agents, Anthropic operates it.

The three-tier architecture

The architecture has three tiers:

1. Application tier — the product, workflow, or system that consumes the agent's output. The team always owns this.
2. Orchestration tier — runtime, state, routing, lifecycle management. Owned by Anthropic in managed mode; by the team in self-hosted mode.
3. Model tier — Claude itself. Anthropic always owns this regardless of orchestration model.

The choice between managed and self-hosted is a choice about who owns tier 2. It has no effect on the model, and it does not change what the application can do. It changes only how the orchestration layer is operated and where its failure points live.

What happens when an agent runs

When a Claude Managed Agent executes a task, the sequence is:

1. The application sends a task to Anthropic's managed orchestration layer.
2. The orchestration layer sequences the agent's steps, invokes tools, and maintains state across the run.
3. Claude processes each step within the orchestrated sequence.
4. Results return to the application via Anthropic's infrastructure.

In self-hosted orchestration, steps 2 and 4 are replaced by the team's own code. The model invocations remain the same, but everything that wraps them is custom infrastructure.

Managed vs self-hosted: the operational trade-off B2B teams actually face

The managed vs self-hosted choice determines where operational complexity lives in production and who absorbs it when things go wrong.

What managed orchestration removes from the team

Managed orchestration eliminates the need to build and maintain:

Retry and error handling — what happens when a tool call fails, when the model returns an unexpected output, or when a step times out. Managed infrastructure handles this. Self-hosted infrastructure requires it to be engineered.

State persistence — maintaining agent context across steps, storing intermediate outputs, recovering state when a run is interrupted. Managed infrastructure provides this. Self-hosted infrastructure must implement it.

Scaling infrastructure — what happens when multiple agents run concurrently, when load spikes, or when a deployment must handle more tasks than the initial design anticipated. Managed infrastructure absorbs the scaling problem. Self-hosted infrastructure requires the team to solve it.

Monitoring and failure detection — knowing when an agent has failed, why it failed, and what state it was in. Managed infrastructure provides this within its own visibility model. Self-hosted infrastructure requires the team to build it.

The operational cost of these capabilities in engineering time, infrastructure spend, and maintenance overhead is the primary argument for managed orchestration. For teams whose core capability is the agent's business logic rather than its infrastructure, managed orchestration directs engineering capacity to where value is created.

What managed orchestration introduces

Managed orchestration introduces three constraints that self-hosted does not carry.

Vendor dependency. The orchestration layer runs on Anthropic's infrastructure. If Anthropic's managed agent service changes its pricing, API, or operational model, the cost of adaptation falls on the team. Self-hosted orchestration is not immune to model changes, but the orchestration layer itself is under the team's control.

Reduced transparency. The managed layer operates within Anthropic's infrastructure. Logging, observability, and auditability are available, but through Anthropic's interfaces rather than directly in the team's own monitoring stack. For environments requiring internally controlled audit trails (financial services, healthcare, regulated manufacturing), this may be a hard constraint.

Integration friction. Enterprise agent deployments often require deep integration with internal systems: CRMs, ERPs, proprietary databases, internal APIs with non-standard authentication. Managed orchestration adds a vendor boundary between the agent and those systems. In complex integration environments, that boundary requires additional architecture.

McKinsey's research on agentic organisations notes that architectures must separate logic and data from vendors to avoid obsolescence. That is a direct argument for ensuring the orchestration choice does not create lock-in that prevents the architecture from evolving as agent technology matures.

When managed agents are the right production choice — and when they aren't

When to use Claude Managed Agents

Claude Managed Agents are the right production choice when:

The use case is well-bounded. The agent operates within a defined domain with clear inputs and outputs. Well-bounded use cases do not require deep integration with systems outside Anthropic's infrastructure model, and they do not generate the edge-case handling complexity that consumes disproportionate engineering time in self-hosted builds.

Orchestration complexity is high relative to team capacity. Multi-step, multi-agent workflows require significant engineering to orchestrate correctly. If the team's capacity is better directed at the agent's business logic than at the infrastructure that runs it, managed orchestration is the rational choice.

Enterprise integration requirements are manageable within Anthropic's infrastructure model. The integrations the agent needs: APIs, data sources, tool access, can be connected without requiring deep internal system access that a vendor boundary would constrain.

Speed to production matters more than infrastructure control. For teams validating an agent use case before committing to a full self-hosted build, managed orchestration enables faster deployment and faster learning at lower engineering overhead.

When to self-host

Self-hosted orchestration is the right choice when:

Data residency or compliance requirements restrict third-party orchestration. In financial services, healthcare, and sectors subject to data sovereignty regulation, routing agent execution through Anthropic's infrastructure may not be permissible. Self-hosted orchestration keeps the execution environment under direct organisational control.

Deep integration with enterprise systems is required. Agents that must read from and write to internal systems with low latency, custom authentication, or non-standard data models typically operate more effectively when the orchestration layer is co-located with the enterprise infrastructure it integrates with.

Full observability is a regulatory or operational requirement. Environments requiring internally controlled audit trails, where every agent action must be logged, attributed, and auditable within the organisation's own monitoring stack, cannot rely on managed orchestration's visibility model.

The team has the engineering capacity to own the orchestration layer. Self-hosted orchestration is a legitimate choice when the team's capacity can absorb it without crowding out the agent capability work it exists to serve.

What Graph Digital learned building Katelyn on Claude Managed Agents

Graph Digital chose managed orchestration for Katelyn after modelling the alternative. The decision criteria were capacity-first, not preference-first.

Katelyn runs multi-agent workflows continuously: research agents, analysis agents, writing agents, and review agents operating in coordinated pipelines. Building the orchestration layer that coordinates this — routing between agents, maintaining state across multi-step runs, handling failures, scaling across concurrent runs — would have required significant ongoing engineering investment. That investment would have come from the same pool as the investment in the agents' reasoning, tool use, commercial logic, and output quality.

The assessment was direct: the orchestration overhead did not produce Katelyn's value. The agents' capability did. Managed orchestration freed the capacity to build what mattered.

Since deployment: 50% increase in new users to high-intent pages, 440% increase in conversion rate. The platform operates continuously without an internal orchestration maintenance burden.

The same team has scoped self-hosted orchestration architectures for client builds where data residency requirements or deep enterprise integration needs made managed orchestration unsuitable. The decision framework was identical in both directions: what does production actually require from the orchestration layer, and which model best serves that requirement given the team's capacity?

The decision framework: evaluating managed vs self-hosted for your production context

Four questions determine the right choice for a specific production context.

1. What does the orchestration layer need to do? Map the specific orchestration requirements of the use case: how many steps, what tool calls, what state must persist, what failure modes require handling. The complexity of this map determines how much engineering the orchestration layer will consume in self-hosted mode, and whether managed orchestration covers the requirement adequately.

2. Where does compliance and data residency land? Assess whether the applicable regulatory or data sovereignty requirements permit routing agent execution through Anthropic's infrastructure. If not, self-hosted orchestration is not optional. It is mandatory.

3. What is the team's actual orchestration capacity? Not ideal capacity: actual capacity that will be available after the agent's business logic, integrations, testing, and monitoring have been resourced. The orchestration layer is not a one-time engineering investment. It is an ongoing maintenance commitment.

4. What are the enterprise integration requirements? Identify the systems the agent must interact with, the access models those systems require, and whether a vendor boundary between the agent and those systems is architecturally viable.

Common misconceptions

Misconception: Self-hosted orchestration gives the team full control of the agent. Reality: Self-hosted orchestration gives the team control of the orchestration layer. The model (Claude) is always operated by Anthropic. Full self-hosted orchestration does not change the team's relationship with the model — only with the infrastructure that coordinates it.

Misconception: Managed orchestration is only appropriate for simple use cases. Reality: Managed orchestration operates at enterprise scale. Deloitte deployed Claude to 470,000 employees in October 2025 using Anthropic's managed infrastructure. The distinction is not complexity or scale. It is whether the use case has integration, compliance, and observability requirements that a vendor boundary can accommodate.

Misconception: "We want control" is a sufficient reason to self-host. Reality: Control of the orchestration layer is valuable only if the team has the capacity to exercise it productively. Engineering capacity consumed by orchestration maintenance is capacity not directed at agent capability. The question is not whether control is desirable. It is whether the cost of ownership is justified by the specific requirements that make self-hosted orchestration necessary.

When specialist input matters

The decision framework above covers the primary variables for most production contexts. Where multi-agent architecture complexity, compliance specifics, or enterprise integration requirements introduce variables beyond the framework's scope, Graph Digital's readiness assessment maps your specific context before a line of code is written.

AI Agent Development — Readiness Assessment

Key takeaways

• Claude Managed Agents are Anthropic's hosted orchestration infrastructure, handling agent runtime, state management, and routing without teams needing to build or maintain that layer.
• The managed vs self-hosted choice is an infrastructure commitment that determines who owns operational complexity — runtime failures, state, and scaling — once the agent is live.
• Managed orchestration suits use cases that are well-bounded, have high orchestration complexity relative to team capacity, and do not require deep integration with internal systems behind a vendor boundary.
• Self-hosted orchestration is appropriate when data residency requirements restrict third-party execution, deep enterprise system integration is required, or full internal observability is mandated by regulation.
• Graph Digital built Katelyn on Claude Managed Agents in production. The same team has architected self-hosted solutions for client builds. The decision criterion is always the same: which model best serves production requirements given the team's actual capacity?
• "We want control" is not a sufficient decision criterion. The question is what the team will do with that control in production, and whether the cost of owning the orchestration layer is justified by the specific requirements that make self-hosted necessary.

Frequently asked questions

What are Claude Managed Agents?

Claude Managed Agents are Anthropic's hosted orchestration infrastructure for running Claude-based AI agents. They handle agent runtime, state management across multi-step runs, and routing logic between agents, without teams needing to build or maintain those components themselves.

How do Claude Managed Agents differ from self-hosted Claude orchestration?

In Claude Managed Agents, the orchestration layer — runtime, state, routing — is operated by Anthropic. In self-hosted orchestration, the team builds and maintains this layer. The model (Claude) is always operated by Anthropic in both cases.

When should a B2B team use Claude Managed Agents?

Claude Managed Agents suit use cases that are well-bounded, have high orchestration complexity relative to team capacity, and do not require deep integration with internal systems behind a vendor boundary. They are not appropriate when data residency requirements restrict third-party execution or when full internal observability is mandated by regulation.

What are the main risks of managed orchestration for enterprise B2B teams?

Vendor dependency (the orchestration layer is operated by Anthropic, not the team), reduced transparency into agent execution compared to self-hosted monitoring, and potential integration friction where enterprise systems require direct internal access that a vendor boundary complicates.

Does Graph Digital use Claude Managed Agents?

Graph Digital built Katelyn on Claude Managed Agents. The team chose managed orchestration after modelling the engineering overhead of self-hosting and determining that capacity freed by managed infrastructure was better directed at agent capability. Graph Digital has also designed self-hosted orchestration architectures for client builds where compliance or integration requirements made managed orchestration unsuitable.