Managed Agents

What it is

Managed Agents is the hosted end of Anthropic's agent stack. Instead of importing a library and running the loop in your own process, you create an agent over HTTP, give it a task, and Anthropic runs the turns — including the sandbox the agent's tools execute in. Your side of the line is a REST client and a webhook or polling loop, which is why the languages field says any: it is an API, not a package.

The pitch is narrow and worth stating plainly. It does not make the agent smarter. It removes the machinery you would otherwise build around one: containers that start and stop, session state that survives a deploy, work that continues while nobody's laptop is open.

How the loop works

You post a task and a configuration — instructions, which tools are available, limits — and the service holds the session. The agent works asynchronously: you are not holding a socket open for the twenty minutes it spends on a job. You read progress and results back out of the API, and the session can be resumed or inspected rather than existing only as a transcript in someone's terminal.

Because Anthropic operates the execution environment, tool calls run there rather than on your machine. That is the whole architectural difference from the Agent SDK, and it decides most of the trade-offs below. Exact endpoint names, configuration fields and limits change faster than this page does; treat the API reference as the authority rather than anything written here.

Isolation and permissions

The sandbox is the product. Code the agent writes and commands it runs execute inside Anthropic's environment, not next to your production credentials, and a runaway loop consumes budget rather than your filesystem. For a class of task — untrusted input, generated code, anything you would not run on a developer laptop — that is a genuinely better default than any of the local harnesses on this board.

The cost of that is reach. A sandbox in someone else's cloud cannot see your private repository, your internal package registry, or a database on a private network unless you deliberately expose them, and every mechanism for doing so — a scoped token, a tunnel, a remote MCP server — is a hole you have opened and now own. The threat model also inverts: you are no longer protecting your machine from the agent, you are deciding what data you are comfortable sending to a third-party execution environment. For regulated work that question is answered by your compliance team, not by this page.

Who it is for

Teams that want agents running on a schedule or in response to events, and do not want to become operators of session infrastructure to get there. It also suits shops with no Python or TypeScript service to host a library in — an HTTP call fits any stack. It is the wrong shape for interactive development at a keyboard, and the wrong shape for anything that must execute inside your own network.

Limits

• Claude only, hosted only. No self-hosting, no other model vendors, no fallback if the service has a bad day.
• Least portable option on this board. The API shape is Anthropic's. Moving off it later means rebuilding the orchestration you avoided building now.
• Reach is limited by design. Private resources need deliberate, auditable exposure.
• Cost visibility. Long autonomous sessions bill for every turn, and turns you did not watch are still turns. Set budgets at creation, not after the invoice.
• Young surface. Hosted agent APIs across the industry are changing month to month. Expect breaking changes and version your integration accordingly.

Alternatives on this board

• Claude Agent SDK — same loop, your infrastructure, full network reach, and the sandbox becomes your problem.
• Claude Code — the interactive surface, for work that wants a human in the loop.
• Hermes Agent — the self-hosted take on always-on: you run the box, you keep the data.
• LangGraph — if what you actually need is durable orchestration you control rather than a hosted agent.