Claude Managed Agents Explained: How They Work and Where They Fit in Your SDLC

Key takeaways

• Claude Managed Agents provide a managed agent harness. Anthropic runs the infrastructure an agent needs, so you only decide what the agent does and what it can reach.
• For a single agent it is excellent. A job can run for hours, survive a dropped connection, and reach real systems safely with nobody watching it. All of that applies to one agent doing one job on its own.
• Running several agents in one process needs a layer above them that connects the steps, keeps a human in the loop, and tracks the whole run. That layer is the AI software factory, and platform teams build it on top.

What are Claude Managed Agents?

Claude Managed Agents is a hosted runtime for agents built on Claude, and it has been in public beta on the Claude Platform since April 8, 2026.

Agents need much more than a model, because something has to decide when to reach for a tool, run the resulting code somewhere isolated, hold the credentials for the systems it touches, keep track of a task that runs for hours, and recover when a step fails partway through.

This is the agent harness, and building it was most of the work in shipping an agent until Anthropic stepped up, and supplied that harness and infrastructure as a managed service.

Now, when building an agent, all that is left for you to decide is:

1. What the agent does
2. Which tools and data it can reach
3. What it can do on its own, and what needs a person
4. When it runs

Everything besides that is operated for you.

But the challenge arrives around the fourth or fifth agent, when you try to get several of them working on one business process and find that nobody hosts that part for you, we’ll explore how enterprises are handling it in this blog.

{{from_manual_to_autonomous_engineering}}

How do Claude managed agents work?

Anthropic describes the design as decoupling the brain from the hands, and it comes down to three pieces.

The harness is the brain. It runs the loop, deciding what to do next, which tool to call, and when the job is done.

The sandbox is the hands. It is the isolated machine where the agent runs commands and writes files, and it attaches only when the agent actually needs it. Since May it can be a sandbox you run yourself, which keeps the agent's processes and network traffic inside your own boundary.

The session is the memory that ties them together. It is a durable log of everything that happened, held outside the model's context window, which is why a session survives a dropped connection or a pause of several hours and carries on where it stopped.

The vault holds the credentials, and it sits outside the sandbox. Anything the agent generates runs somewhere the tokens cannot be reached, so a prompt injection cannot talk the agent into reading its own secrets.

Around those pieces you get scoped permissions per agent, MCP servers attached per agent, session budgets that cap what one session can spend, scheduled runs on a cron, and a trace in the Console of every tool call and decision.

Alternatives for Claude managed agents

The market sorted itself into three groups during 2026, and the choice usually follows the cloud and the models you are already committed to.

Model provider platforms. Claude Managed Agents sits here, alongside OpenAI Frontier and the cloud agents that coding tools like Cursor now run for you. The provider hosts the agent and you work inside their stack.

Cloud provider runtimes. AWS Bedrock AgentCore, Google's Agent Runtime, and Azure AI Foundry Agent Service. You get the runtime in the cloud you already buy from, with a choice of model providers.

Self-hosted harnesses. The Claude Agent SDK gives you the same harness on your own hosts. LangGraph and Temporal take a different angle, giving you durable execution and an orchestration layer you own outright. You keep the sandbox, the credentials, and the scaling.

Sandbox runtimes like E2B, Modal, and Daytona are a separate category. They run code safely and nothing else, so you bring your own harness.

The challenge: How do several Claude agents work as one process?

One managed agent is excellent. The difficulty starts when a business process runs across several of them, with predictable steps in between and people who have to approve at certain points. Getting a bug fixed runs from ticket to code to review to deploy to verification, crossing several agents and several people on the way, and that is where it gets complicated:

• How does work move from one step to the next? A session ends and returns its output. Deciding what runs next, passing the result to the agent or the person who takes the following step, and confirming it worked is all still yours to arrange.
• How do you keep a human in the loop between steps? Some steps need someone to approve before the work carries on, like a production deploy or a change to a regulated service. That approval sits between two agents, so it belongs to neither of them.
• How do you track the process end to end? The Console traces a single session in real detail. Following one ticket through the four agents and two people who handled it is a different question, and no single session answers it.
• Who is accountable when an agent gets it wrong? An agent definition holds a model, its tools, and its permissions, and no field records the team responsible for it. That answer sits with whoever built it until they move on.
• What about the steps that do not run on Claude? The same teams run agents on Bedrock, inside Cursor, and on the Agent SDK, so a process built only around Managed Agents covers part of the line.

This is why the most advanced organizations are building an AI software factory. They connect the agents at each step into one business process, and they build a platform that orchestrates that process, carries the context about how the organization is put together, and keeps a human in the loop where it matters.

Scaling Claude Managed Agents with an AI software factory

An AI software factory is the platform layer that connects your agents into one business process, which is the same shape Anthropic describes in its AI-native SDLC playbook, where each stage commits an artifact and that commit starts the next stage. It defines the steps and the order they run in, gives every agent the same context about your organization, holds the approval points where a person decides, and keeps the record of what happened. Agents from any vendor plug into it, so a Claude managed agent, a Bedrock agent, and one running in Cursor are all steps on the same line.

Anthropic built a top-tier harness for a single agent. It decides when that agent reaches for a tool, what it keeps in context, and how it recovers, all inside the boundary of one session.

Port is the agentic SDLC platform teams use to build the layer above that. It finds the agents your teams have already built, wherever they run, gives all of them the same picture of your services and who owns them, and runs them as steps inside workflows with people approving the parts that need judgment. Concretely you get:

• A workflow orchestrator that defines the line itself, meaning the business process each piece of work travels through and which agent or person handles each step
• An agent registry of every agent, MCP server, and skill that is part of the factory, with the owner, access boundaries, and lifecycle state of each one, wherever it runs
• A Context Lake as the shared source of truth about services, owners, and dependencies, so an agent reads the context it needs instead of guessing at it
• Human in the loop on the steps where a person needs to step in, so an approval belongs to the process rather than to any single agent
• Governance and metrics covering scoped permissions, an audit trail of every agent action, and the cost and outcome of the work, so you can tell whether the line is running the way you expect

A typical example we like to use is incident remediation.

The checkout service starts returning server errors and an alert fires. Port starts a triage agent and gives it the service, its owner, its recent deployments and its dependencies. The agent finds the change that caused it and writes up what it found. Port then starts a coding agent on that write-up, which opens a pull request with the fix. Because checkout is production-critical, the service owner approves before anything merges. Both agents run on Claude Managed Agents, and swapping either one for an agent on another runtime does not change the process, the approval, or the record.

See how Port connects to Claude Managed Agents on our Claude integration page.

FAQ

Can managed agents run in a self-hosted sandbox?

Yes, since May 2026. Orchestration stays on Anthropic's side and tool execution moves to infrastructure you run, so the agent's filesystem, its processes, and its network egress stay inside your boundary. Tool inputs and outputs still reach Anthropic's control plane, because that is where the model works out the next step. Vercel Sandbox, Daytona, and Modal are supported.

Are Claude Managed Agents suitable for regulated industries?

Partly, and the limits are documented rather than guessed at. Because sessions are stateful and stored server-side, Managed Agents is not currently eligible for Zero Data Retention or for HIPAA Business Associate Agreement coverage. Self-hosted sandboxes keep execution inside your network and inference geo pinning fixes where model requests run, which covers a lot of residency requirements. The record of which agents exist and who approved them stays yours to keep.

What happens if you later move off Anthropic infrastructure?

Agent definitions, tool configurations, and MCP connections move with you. The runtime does not, so you would rebuild the sandbox, the credential handling, and session persistence, or adopt another provider's version. Keeping the registry and governance layer independent of any one vendor makes that decision easier.

Do managed agents work with existing MCP servers?

Yes. Servers are declared per agent, so each definition names the tools that agent may use, and credentials are supplied at session level. Declaring only the servers an agent genuinely needs is one of the more practical ways to keep its reach narrow.

Do you need an AI software factory to use Claude Managed Agents?

No. One agent doing one bounded job works fine on its own, and that is where most teams start. The factory matters once several agents handle different steps of the same process, because that is when nobody can say which agents exist, who owns them, or how work passes between them. We wrote about what that looks like when it is missing.

How does Port work with Claude Managed Agents?

Port discovers your managed agents alongside agents on other runtimes and holds each one in an agent registry with its owner and access boundaries. Workflows trigger agent sessions as steps in a process, the Context Lake supplies the service and ownership data the agent needs, and approvals and audit sit at the workflow level rather than inside any single agent.

{{from_manual_to_autonomous_engineering}}