Claude Managed Agents: the harness is now a service

Title card reading The agent harness is now a service, with the Claude Managed Agents mark top left and a gold-outlined session window streaming glowing event rows around a loop, one key resting outside the frame.

If you run agents in production, you have probably written the same loop three times: call the model, execute the tool, append the result, repeat, plus a sandbox, a queue and a cron wrapper around it. Claude Managed Agents is Anthropic selling that loop as an API. Managed Agents hosts the agent harness, the tool execution and a per-session Linux sandbox, billed at model token rates plus $0.08 per session-hour, while your code keeps the credentials, the custom tools and the approvals. This post walks through what the beta actually ships, what a session costs, and the retention line that decides who should wait.

Anthropic runs the loop; a fresh container runs the tools

The overview states the pitch in one sentence: “Instead of building your own agent loop, tool execution, and runtime, you get a fully managed environment where Claude can read files, run commands, browse the web, and run code securely.” The platform splits into four objects. An agent is a persisted, versioned config holding the model, system prompt, tools, MCP servers and skills. An environment says where tool execution happens. A session is one running instance with its own filesystem and history, the unit you steer, interrupt and delete. Events are the wire: you send user messages, the service streams tool calls and results back over SSE, and the whole history is persisted server-side.

The session docs make versioning concrete: passing an agent ID as a string runs the latest version, passing {"type": "agent", "id": ..., "version": 1} pins one, so a prompt change cannot silently redefine a long-running agent mid-flight. That is the part of harness engineering most homegrown loops never get around to; we argued in the model is not the product that this scaffolding is where the engineering actually lives, and Anthropic has now productized a large slice of it.

Flow diagram splitting a Managed Agents session into your code, the hosted control plane running the loop, and the per-session sandbox running the tools, with cloud-sandbox secrets substituted at egress. — The ownership boundary: your code sends events and holds secrets, the hosted loop decides tool calls, the sandbox executes them.

Eight built-in tools ship enabled, and oversized outputs become files

The tools page lists the built-in toolset: bash, read, write, edit, glob, grep, web_search and web_fetch, all enabled by default once the toolset is on the agent. The web pair accepts domain lists, a cap on fetched content and a search location. One operational detail is worth knowing before you ship: when a tool output exceeds 100,000 characters (about 25,000 tokens), the platform writes it to a file in the sandbox and hands the model a truncated preview with the path. Your own loop probably truncates and loses the rest; this one spills to disk.

MCP support is first-class: the reference says sessions connect to remote servers over the protocol’s streamable HTTP transport, with an automatic fallback for servers still on the deprecated SSE transport, and private servers reachable through MCP tunnels. The harness also runs prompt caching and context compaction for you, which is two fewer failure modes to own, and two fewer levers you can reach when they misbehave. What the harness does not do is vet the servers you connect: the attack classes and the controls that stay yours are in MCP security in production.

How to access Claude Managed Agents

Access is simpler than most Anthropic betas: per the overview, Managed Agents is in beta, every endpoint requires the managed-agents-2026-04-01 header, the SDKs set it automatically, and access is enabled by default for all API accounts. A standard API key is the whole prerequisite. Anthropic announced the public beta on April 8, 2026 as “composable APIs for building and deploying cloud-hosted agents at scale”. Two sub-features sit behind a request form in a more limited research preview: MCP tunnels and dreaming. Plan around the org-wide rate limits in the reference: create endpoints (agents, sessions, environments) allow 300 requests per minute, read endpoints (retrieve, list, stream) 1,200 requests per minute, with your usage-tier limits on top. For a fleet of short sessions, the create limit is the one you will hit first.

The bill is tokens plus $0.08 per session-hour

Anthropic’s pricing page, the one behind the intro’s figure, bills Managed Agents on two dimensions: tokens at standard model rates, and session runtime at $0.08 per session-hour, metered to the millisecond and accruing only while the session’s status is running. Idle time, including waiting for your next message or a tool approval, costs nothing, and runtime replaces the old code-execution container-hour billing. The page’s worked example prices a one-hour Claude Opus 5.5 session at 50,000 input and 15,000 output tokens: $0.20 plus $0.30 plus $0.08, $0.58 total, falling to $0.428 when 40,000 of those input tokens are cache reads. Web search inside a session stays at $10 per 1,000 searches, there is no batch discount, and pinning inference to the US multiplies token rates by 1.1x.

The companion to the meter is the session budget, a hard spend ceiling priced continuously at public list rates. Amounts are strings in whole US cents, so "125" caps a session at $1.25:

curl https://api.anthropic.com/v1/sessions \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: managed-agents-2026-04-01" \
  -d '{
    "agent": "'"$AGENT_ID"'",
    "environment_id": "'"$ENVIRONMENT_ID"'",
    "budget": {"type": "limit", "max_list_cost":
      {"amount": "125", "currency": "USD"}}
  }'

The enforcement is between model requests, not mid-request: “The request in flight when the cap is crossed still finishes, so the final list cost can land a fraction past the budget.” A capped session goes idle with stop_reason: budget_reached instead of dying, and updating or removing the budget resumes the paused work. That is a kinder failure mode than most self-built kill switches, which tend to terminate and lose the state.

Scheduled deployments are cron for agents

A scheduled deployment attaches a POSIX cron expression and a timezone to an agent and starts sessions on that cadence, down to minute granularity, which turns a background agent into a platform object instead of a crontab entry on a box someone forgets to patch. Each firing writes a deployment run record, so successes and failures are trackable independently of the sessions themselves. The lifecycle details are sensible: pausing suppresses future triggers while running sessions finish, unpausing does not backfill missed triggers, and an unrecoverable creation error, say an archived environment, records a failed run and auto-pauses the deployment with the error type mirrored on paused_reason. Deployments accept the same budget object and apply it to each session they start, which caps a runaway schedule at a price you chose in advance.

Your code keeps the secrets, the custom tools and the sandbox if you want it

What stays on your side is the more interesting list. Credentials live in vaults: MCP tokens are injected when the agent connects to the matching server URL, and environment_variable credentials sit in the sandbox as opaque placeholders that are substituted with the real secret at egress, so the agent never sees the value. Custom tools stay yours by construction. The tools page is explicit: “Claude does not run a custom tool itself. It emits a structured request, your code runs the operation, and you return the result to the session.”

For the sandbox you choose an environment: a cloud environment gives each session its own fresh Linux container on Anthropic’s infrastructure, or a self-hosted sandbox moves tool execution onto your machines, where a worker process you run claims each bash and file call from a work queue and posts results back. Read the boundary honestly before calling that private. The docs put it plainly: “Claude still runs on Anthropic’s side and decides which tool to call next.” Conversation history and tool results still flow through the managed service, web search and web fetch still run on Anthropic’s side, and self-hosting gives up environment-variable credentials and the pre-installed runtimes. Self-hosting moves the sandbox, not the state.

Statefulness is the point, and it costs you ZDR and HIPAA eligibility

The reason Managed Agents is useful is the same reason compliance teams will stop you at the door. Sessions are long-running, resume after pauses, and store conversation history, sandbox state and outputs server-side. Anthropic’s data retention page marks Managed Agents ineligible for both Zero Data Retention and HIPAA BAA coverage: “Sessions are stateful resources; transcripts persist until you delete them.” The exclusion applies to all sub-features, self-hosted sandboxes included, and under HIPAA readiness the API blocks these endpoints outright with a 400, while a ZDR org that uses them is choosing to step outside its arrangement for that data. You keep delete rights: sessions, and separately any uploaded files, can be removed through the API at any time.

The trap: a self-hosted sandbox sounds like the compliance fix, and it is not. The docs say neither environment option changes the compliance coverage or how long conversation history is kept. If ZDR or a BAA is a hard requirement today, the Messages API with your own loop is still your lane.

What running unattended agents taught us, and where this lands

We publish to this site with scheduled agents, six runs a week plus weekly and twice-monthly jobs, each opening a pull request that a gate reviews before anything merges. Running those taught us three rules that map directly onto what Anthropic just productized. A silent worker is replaced on a ceiling, never waited on, in our case 30 minutes before a sub-agent is killed and respawned once; a session budget’s budget_reached pause is that ceiling with the state kept. Every run leaves a record a human can audit the morning after; deployment runs are that record. And the agent proves its work through hard gates rather than trust, which is the half no platform can host for you: Managed Agents will run your session on schedule and under budget, but the evals and merge gates that decide whether its output ships remain your code and your judgment. We priced the switch the same way we priced moving models: the sticker is the easy part, the behavior under failure is the decision.

The takeaway

Claude Managed Agents turns the agent loop, the sandbox and the scheduler into a billed service: tokens plus $0.08 per session-hour, a hard budget that pauses instead of kills, cron-fired deployments with run records, and credentials substituted at egress so the model never reads a secret. You still own the custom tools, the approvals and every quality gate, and you cannot bring ZDR or HIPAA workloads to it today. If your agents are deep, long-running workers and your compliance surface allows stateful sessions, the beta is worth a real evaluation; if your edge is a custom harness, the Messages API remains the sharper tool.