Anthropic Launches Self-Hosted Claude Managed Agents

By Rebecca Stone

Anthropic launched self-hosted Claude Managed Agents on November 12, 2026, allowing customers to run the full service and its sandboxes in their own cloud account or on-premises data center.

Customers can place agents, sessions and session history on that infrastructure and direct model requests to a chosen inference provider. The release extends customer control to the Managed Agents API, the agent loop and session storage.

For Anthropic customers, the policy stakes are data location and operator access. Anthropic says agent state and tool execution can remain in a customer deployment, while each model conversation still goes to the inference provider the customer selects.

Anthropic’s earlier self-hosted sandboxes moved tool execution onto customer systems while Anthropic continued running the agent. Tool inputs and outputs still flowed to Anthropic, which also stored skills and memory stores. The new release covers the API, agent loop and session storage as well.

The result is a split operating model. Anthropic operates its hosted service; self-hosted customers assume responsibilities Anthropic holds for that service.

What runs on the customer’s infrastructure?

At the center is cma-server. Anthropic says it serves the Managed Agents API, runs the agent loop, stores agents, sessions and their histories, and calls the inference provider configured for the deployment. Separate workers execute shell and file tools inside customer sandboxes. The server itself never runs those tools.

This division keeps direct command execution out of the API server. Anthropic assigns shell and file operations to workers in the customer’s sandboxes, while cma-server coordinates the loop, maintains state and calls the configured inference provider.

The customer-run server exposes the same Managed Agents API as Anthropic’s hosted service, apart from documented feature differences. The Claude SDK and ant CLI can connect to it.

Three operating conditions define persistence and release handling:

• A persistent deployment requires PostgreSQL 16 or later.
• Without a database, cma-server retains data only in memory. A restart erases that data.
• Customers must contact their Anthropic account team to request the download and install each release themselves.

Anthropic’s security documentation states: “the server connects to Anthropic only when the Claude API is that provider.” The same document says Anthropic has no remote access to the customer-run server or its log. That boundary depends on the provider setting described below.

Where do model calls go?

Model calls go to the Claude API by default. Customers can instead select:

• Amazon Bedrock.
• Claude Models on Google Cloud (Google managed).
• Microsoft Foundry.
• A model gateway they operate through the server’s provider settings.

Agents continue to name models by their Claude API IDs. For providers that serve those models, cma-server translates the IDs, allowing an agent definition to work unchanged.

Each model call sends the conversation so far to the selected inference provider. That payload includes prompts, tool inputs and tool results. Self-hosting the service therefore does not, by itself, keep model traffic inside the customer’s network.

Unlike the local session store, the inference path has no location fixed by cma-server; its destination follows provider configuration. A customer-operated model gateway remains an inference provider, even though the customer controls that gateway.

With the Claude API selected, cma-server connects to Anthropic for inference. With another provider, that network path goes elsewhere. The customer controls the destination through provider settings, but the transfer of conversation contents remains.

What must customers migrate?

Anthropic’s migration guidance says:

“nothing is copied from Anthropic’s hosted service, including session history.”

Customers must recreate agents, skills, vault credentials and memory stores on their own server. The guidance does not provide a transfer path for hosted session history.

This is not an in-place conversion from Anthropic’s hosted Managed Agents. Customers must build the equivalent agent state, credentials and stores on the new system and account for any hosted capability they previously used but cannot retain.

Organizations already running self-hosted sandboxes can connect the same worker software to the new server. The self-hosted server sends no webhooks, so workers triggered by webhooks will not operate.

Who operates and isolates the deployment?

Customers assume operating duties that Anthropic handles for the hosted service. Anthropic lists the following responsibilities for self-hosted operators:

• Securing the server.
• Hosting memory stores.
• Detecting unusual usage.
• Installing releases.

Each deployment serves one tenant at one trust level. Separate tenants, or workloads with different trust levels, require separate deployments with their own databases, server API keys and workers.

That restriction makes tenant isolation an architecture requirement, not a configuration choice within one shared installation. Each separate deployment needs its own database, server API key and worker set, according to Anthropic’s guidance.

Which hosted features are missing?

Some hosted-service features do not exist in the self-hosted release:

• Scheduled deployments.
• Dreams.
• Webhooks.

Web search and web fetch remain off until a customer explicitly enables them. Their availability then depends on the inference provider.

Anthropic lists the following provider support:

• Web search works with the Claude API, Claude Models on Google Cloud (Google managed) and Microsoft Foundry.
• Web fetch works with the Claude API and Microsoft Foundry.

The support matrix makes provider selection part of feature testing. Enabling web search or web fetch does not guarantee access when the selected inference provider does not support the tool, and the self-hosted release cannot send webhook-driven jobs because it sends no webhooks.

How long does customer session data remain?

Session retention is customer-managed. Sessions and their histories remain in the customer database until the customer deletes them. They do not expire by age.

Deletion removes sessions from that database, but it does not remove copies in backups, exported logs and traces, memory stores or, on Kubernetes, the session’s workspace volume. The documented deletion path therefore does not cover every stored copy of session data.

That makes deletion policy a continuing operating responsibility for self-hosted customers. Because sessions do not age out automatically, customers must decide when to remove them and must track copies that a database deletion does not reach.

The final boundary remains twofold: agent state and execution can stay within the customer’s deployment, while every conversation still reaches the chosen inference provider. For adopters, the test now sits with operators: secure cma-server, install every release, isolate trust levels and select a provider whose data handling fits the deployment. Anthropic has made a self-hosted agent path possible; it has not made inference local by default.