Self-hosted Claude Managed Agents: the server is yours, and so are the failures that report nothing

On November 12, Anthropic launched self-hosted Claude Managed Agents. Before this you could move the sandboxes to your own machines and leave the rest with Anthropic. The whole service can move now: the API, the agent loop, and the storage for agents, sessions and session history. The server sends model calls to the Claude API by default, or to Amazon Bedrock, Google Cloud, Microsoft Foundry or a gateway you run.

I have not run it. The download is available on request through the account team, so this piece rests on the documentation as it read on November 13. The page to read first is “Differences from the hosted service”, and its best rows are the ones that end in “no error”.

What is self-hosted Claude Managed Agents?

It is the same Managed Agents API served by a program you run, cma-server, so the SDK and the ant CLI work against it unchanged. A deployment is one or more servers, PostgreSQL 16 or later, and workers that poll the server and run the agent’s shell and file tools in your sandboxes.

Two lines from the overview are worth knowing before anything else. The server also starts without a database; it then keeps everything in memory, and a restart erases it. And the bash tool is a real shell with the worker’s permissions. The worker does not isolate it, so isolation is whatever container or VM you put the worker in.

Which self-hosted Claude Managed Agents failures report nothing?

The Differences page names them. In each one the call you made succeeds, or stays quiet, and the work did not happen the way you asked:

• No worker is polling the environment. Model turns still run, and the first tool call “waits, with no error, until a worker runs it.” The same wait follows if your worker was meant to start on a webhook: the server sends none.
• The web tools are turned on, but the provider does not offer one. web_search works under anthropic, vertex and foundry, web_fetch only under anthropic and foundry. Under the others, the agent saves, runs and still lists the tool, and the model is never offered it.
• An image or document is sent by URL. The server accepts the block, and the model never sees it.
• A Git push is refused by your host. The server’s log says ok anyway.
• A safety classifier declines a request under the Claude API. Server-side fallback is on by default, so another Claude model, “possibly a less capable one”, answers. Anthropic picks it, no event reports the switch, and only the model ID in the session shows it. inference.model_fallback: false turns it off.

One more case is close: a custom tool result too large for the context window gets a 200, and the error arrives afterwards, as a session.error that ends the session. Each of these is documented. None of them shows up unless you go looking. I wrote about the same shape in Claude Code, where refused work ends with a success subtype: a clean exit is not the same as done work.

Which hosted features does self-hosted Claude Managed Agents lack?

Dreams, webhooks, scheduled deployments, the Files API, mcp_oauth vault credentials and the prebuilt docx, pdf, pptx and xlsx skills are all absent. Scheduled runs go to your own cron, files go in the worker’s directory, images go as base64, and an OAuth token becomes a static one you rotate by hand. Dreams have no replacement.

Orchestration shrinks the most. Dynamic workflows, the advisor and agents the model defines itself return 400; the server accepts only the coordinator type with 1 to 20 listed agents. So an agent that sets multiagent_20261001, the type in my dynamic workflows guide, is refused here, and the workflows do not carry over. Nothing else carries over either: agents, skills, vault credentials and memory stores are created again, and the MCP and Git host allowlists start empty.

What leaves your network with self-hosted Claude Managed Agents?

Every model call carries the conversation so far, tool inputs and results included, to the provider. Under the Claude API, three headers go with it: the session, agent and environment IDs. The IDs carry no names or content, but each encodes the time your server created it, and “No setting turns them off.”

Retention does change. Hosted Managed Agents is outside zero data retention, because Anthropic stores the transcripts until you delete them. Self-hosted, you store them. The model calls fall under your agreement with whichever provider serves them; when that is the Claude API, an existing ZDR arrangement covers them like other Messages API calls.

Self-hosted Claude Managed Agents or self-hosted sandboxes: which one fits?

The docs draw the line at two needs: agents, sessions and history stored on your infrastructure, or model calls sent to Bedrock, Google Cloud, Foundry or your own gateway. Without either, self-hosted sandboxes keep the tools in your network while Anthropic runs the service, with their own limits (no file or github_repository session resources, for one).

My read: what the full self-host buys is custody, of the transcripts and of the choice of provider. What it costs is that you now run the service, a database to back up, a server to keep patched, and the cases above where it reports nothing.

What should you check before the first self-hosted Claude Managed Agents session?

The silent cases, on purpose. Stop the worker and watch the session sit at a tool call. With the web tools on and the provider set to Bedrock, ask the agent to search. Send an image by URL. Allow a branch on the server, protect it on the host, push to it and compare the two logs. That is a suggestion, untested, but each step comes from a row in the docs.

One default I would change and one alarm I would add, by my reading. Set inference.model_fallback: false, or record the model ID of every session, because a model switch nobody records makes every later comparison of runs suspect. And alert when a session that should be working has produced no event for some minutes. The docs’ own advice for a push is the general rule: check the result on the system that holds it, not in the log of the system that sent it.