# Claude Managed Agents Claude Managed Agents is a fully managed [[AI Agent Harness]] from [[Anthropic]]. You send Claude a task; it figures out what needs to happen and runs the work inside isolated cloud containers that Anthropic hosts for you. The built-in tool loop, prompt caching, compaction, and server-sent event streaming are all handled. Write your agent once, start a session, and Claude plans, calls tools, and keeps going until the session goes idle. Launched in public beta on April 8, 2026. Since June 9, 2026, agents can also run on a cron schedule (scheduled deployments) and use API keys stored in vaults as environment variables, so you no longer need your own scheduler or secret store around it. It sits at the opposite end from the [[Claude API|Messages API]]. The Messages API hands you raw model access and you build the loop yourself; Managed Agents hands you the whole harness (agent loop, tool execution, sandboxed runtime, session history) as a service. Think of it as [[Claude Code]] reshaped into an API product with multi-tenant infrastructure. ## When to reach for it Managed Agents fit long-running jobs: work that runs for minutes or hours and burns through many tool calls. They shine for asynchronous, background agent work where you don't want to host a runtime yourself. You get secure sandboxed containers with pre-installed packages and network access out of the box. And because sessions are stateful, the filesystem and conversation history persist across interactions. Recurring work (a nightly sync, a weekly scan, a daily digest) now fits too, through scheduled deployments. Skip it when you need fine-grained control over the model loop. Use the [[Claude API|Messages API]] directly for that. Also skip it if you need Zero Data Retention or a HIPAA BAA: because sessions store history, sandbox state and outputs server-side, Managed Agents isn't eligible for either. You can delete sessions and uploaded files through the API at any time. ## Four core concepts | Concept | What it is | |---|---| | **Agent** | Reusable, versioned config: model + system prompt + tools + MCP servers + skills | | **Environment** | Where sessions run: an Anthropic-managed cloud sandbox (packages, networking rules, mounted files) or a self-hosted sandbox on your own infrastructure | | **Session** | A running agent instance in an environment; where the work actually happens | | **Events** | Typed messages flowing between your app and the agent (user turns, tool results, status updates) | Create agents and environments once, reference them by ID. Each session gets its own isolated container instance. Two supporting resources sit around these four: **deployments** (an agent plus an environment plus a cron schedule, which start sessions on their own) and **vaults** (per-user credentials, referenced by ID when a session starts). ## How a run works 1. Create an agent (model, system prompt, tools, MCP servers, skills) 2. Create an environment (cloud container config, networking, packages) 3. Start a session referencing both (and optionally vaults for MCP auth) 4. Send a `user.message` event; open the SSE stream 5. Claude plans, calls tools (bash, file ops, web, MCP), streams events back 6. Session emits `session.status_idle` when done You can steer a run mid-flight with more user events, or stop it with `user.interrupt`. Full flow: [[Claude Managed Agents Sessions]] and [[Claude Managed Agents Events]]. ## Scheduled deployments Announced on June 9, 2026 (public beta). A scheduled deployment runs an agent on a cron schedule: each time the schedule fires, it starts a brand new session and the agent does its task. No scheduler to build or host. Anthropic's examples: a nightly data sync, a weekly compliance scan, a daily digest. What you give a deployment: - The agent and the environment (required) - At least one initial event, a `user.message` or a `user.define_outcome`, that kicks off each session's work - A `schedule`: a standard POSIX cron `expression` plus an IANA `timezone`. The finest granularity is one minute - Optionally: files, a GitHub repository, memory stores, vaults, and a `budget` How it behaves: - **Jitter.** The response lists `schedule.upcoming_runs_at` with the exact fire times, but actual runs get jitter of up to 15% of the interval (minimum 5 seconds, maximum 9 minutes) to spread the load - **DST.** Cron matches wall-clock time. On a spring-forward day, times that don't exist (2 AM) don't fire; on a fall-back day, repeated times fire twice. Anthropic's advice: avoid the 1 to 3 AM local window, or use UTC - **Budget per run.** The `budget` is copied onto every session the deployment starts, so it caps each run separately (a `"2000"` cap means up to about $20 per run). It's NOT a cumulative ceiling. A run that hits its cap pauses with `budget_reached` - **Deployment runs.** Every trigger attempt writes a run record (with the `session_id` on success, or an `error` such as `environment_archived_error`, `agent_archived_error` or `session_rate_limited_error`). Rate-limited triggers aren't retried; the next occurrence tries again - **Lifecycle.** Pause (stops future triggers; running sessions continue; manual runs still allowed), unpause (resumes at the next occurrence; missed runs are NOT backfilled), archive (terminal). The `run` endpoint triggers a run on demand, which is handy to test before you trust the schedule - **Self-healing, sort of.** Archive or delete the agent and the deployment gets archived too. An archived environment, vault or subagent records a failed run and auto-pauses the deployment until you fix it - **Webhooks** fire on lifecycle changes and on each run's outcome, so you don't have to poll - **Limit:** 1,000 scheduled deployments per organization (contact support for more) With the `ant` CLI, a deployment is a Markdown file in `deployments/`: the frontmatter holds the config (name, agent, environment, schedule) and the prose below it becomes the `user.message` that starts each run. `ant apply` creates it; `ant beta:deployments pause|unpause|archive|run` and `ant beta:deployment-runs list --has-error` cover the rest. Customer examples from the launch post: Rakuten produces weekly or monthly reports and decks from spreadsheet data and watches production logs and metrics; Actively AI replaced the scheduling infrastructure it had built itself; Ando's agents watch channels for next steps, follow up when they're due and send meeting reminders. ## Vaults and environment variables Vaults are workspace-scoped collections of credentials, usually one per end user. You register credentials once and pass `vault_ids` when you create a session (or a deployment). That lets you manage your product at the agent level and your users at the session level, without running your own secret store. Two credential families: - **MCP credentials** (`mcp_oauth`, `static_bearer`), keyed by `mcp_server_url`. Injected automatically when the agent connects to that MCP server. With a `refresh` block, Anthropic refreshes OAuth tokens for you - **Environment variables** (`environment_variable`, new on June 9, 2026), keyed by `secret_name`. CLIs authenticate through these How environment variables work (and why it's clever): the sandbox only holds an opaque placeholder. When a CLI, SDK or `curl` sends a request, the placeholder is swapped for the real secret at the network boundary (egress), and only for hosts you allow. The agent NEVER sees the key, and the key can't leak to a domain you didn't approve. Anthropic names the Browserbase, KERNEL, Notion, Ramp and Sentry CLIs as working this way; Browserbase and KERNEL give Managed Agents browser capabilities for the first time. The knobs and the gotchas: - `networking.allowed_hosts` on the credential decides which hosts get the substitution (`limited` list, or `unrestricted`). The environment's own network rules must ALSO allow the host, or the request fails - `injection_location` decides where the swap happens: `header`, `body`, or both. Credentials created in the Console are header-only; a client that sends its token in the body (form-encoded token requests) gets the literal placeholder and an auth error. Header-only is the narrower, safer option, since request bodies are often built from content the agent handles - Substitution happens at egress, so anything that processes the secret locally breaks: clients that validate key format at startup, and request signing such as AWS SigV4 - Substitution is outbound only. If you use the secret to fetch a session token (OAuth client-credentials grant), that token lands in the sandbox in clear text. Do the exchange yourself and store the resulting token instead - Not supported yet on self-hosted sandboxes - Max 20 credentials per vault; `secret_name` and `mcp_server_url` are unique and immutable (archive and recreate to change them) - Rotation: update the secret in the vault and running sessions pick up the new value without a restart (credentials are re-resolved periodically) - Secret values are write-only; the API never returns them. Archiving purges the secret but keeps the record for audit; webhooks fire on archive, delete and OAuth refresh failures - Scope each API key to what the agent needs. The agent can do anything the key allows Customer examples from the launch post: Notion rolls out its CLI next to its MCP tools (adding file uploads) without handing API tokens to the model; Browserbase built its public catalog of browser skills with the `browse` CLI, validated by a scheduled deployment; KERNEL connects an agent to its usage databases to flag usage surges; Milana lets its agent call private APIs through a CLI against a customer's codebase. ## Self-hosted sandboxes By default, tool execution happens in Anthropic-managed containers. Self-hosted sandboxes (public beta) change that. The orchestration loop stays on Anthropic's infrastructure, but the actual tool execution moves into your own environment. Your sensitive files, packages, and internal services never leave your infrastructure, and you control the compute: resource sizing and the runtime image. Supported providers: - **Cloudflare**: MicroVMs with zero-trust secrets and customizable proxies - **Daytona**: full stateful computers built for long-running work - **Modal**: sub-second startup, GPU or CPU on demand - **Vercel**: VM-level security, millisecond startup, VPC peering This matters when you have compliance requirements, data you can't hand to a third-party cloud, or you simply want to own the compute layer. ## MCP tunnels A research-preview feature for reaching internal services (databases, APIs, knowledge bases, ticketing systems) without exposing them publicly. A lightweight gateway opens outbound, end-to-end encrypted connections, so there are no public endpoints to secure. The agent gets a path to your internal tooling; the open internet doesn't. Request access via the research-preview form (see References). ## Access and beta status - Public beta since April 2026; enabled by default on all API accounts - Every request needs the `anthropic-beta: managed-agents-2026-04-01` header (SDKs add it automatically) - [[Claude Managed Agents Memory Stores|Memory stores]] graduated to public beta on 2026-04-28. As of October 2026, the memory store endpoints use their own `agent-memory-2026-07-22` header INSTEAD of `managed-agents-2026-04-01` (sending both returns a 400); attaching a store to a session still uses the base header - Scheduled deployments and environment-variable vault credentials: public beta since June 9, 2026, under the base header - Self-hosted sandboxes are in public beta; MCP tunnels are research preview. Both work with existing Managed Agents primitives and are reachable through the [[Claude Console]] and the Platform APIs - [[Claude Managed Agents Outcomes|Outcomes]] and [[Claude Managed Agents Multi-Agent|multiagent orchestration]] were research preview at launch (extra `managed-agents-2026-04-01-research-preview` header and a form request). As of October 2026, the docs list them under the base `managed-agents-2026-04-01` header, and the overview only names MCP tunnels and dreaming as research preview (access by request) - [[Claude Managed Agents Dreams|Dreams]] are still research preview: form request plus an extra `dreaming-2026-04-21` header on top of the base one - Also available on [[Claude Platform on AWS]], with two session differences: an autonomous session (no user events) must be reauthenticated after 6 hours by sending any user event (first-party has no such limit), and sessions on self-hosted environments can't attach memory stores. MCP tunnels aren't available there ## Supported models All Claude 4.5 and later. Pass a model ID string (`"claude-opus-5-5"`) or an object that also accepts `speed`, `effort` and `inference_geo`: `{"id": "claude-opus-5", "speed": "fast"}` for fast mode (Opus 5.5, Opus 5 and Opus 4.8), `{"id": "claude-opus-5", "effort": "high"}` for the effort level. ## Rate limits Per organization (updated October 2026; the launch limits were 60 and 600): - 300 req/min on create endpoints (agents, sessions, environments, ...) - 1,200 req/min on read endpoints (retrieve, list, stream) - Organization spend limits and usage-tier rate limits still apply on top - Max 1,000 scheduled deployments per organization; max 20 credentials per vault ## Pricing Two dimensions: tokens and session runtime. - **Tokens** at standard model pricing; prompt caching multipliers apply. Web search inside a session costs the standard $10 per 1,000 searches. Fast mode premium applies when `speed` is `"fast"`; pinning `inference_geo` to `"us"` bills tokens at 1.1x - **Session runtime: $0.08 per session-hour**, metered to the millisecond, and ONLY while the session status is `running`. Time spent `idle` (waiting for your next message or a tool confirmation), `rescheduling` or `terminated` doesn't count. It replaces code-execution container-hour billing; you aren't charged both - No Batch API discount (sessions are stateful, there's no batch mode) - Anthropic's worked example: a one-hour Opus 5 session with 50,000 input and 15,000 output tokens costs $0.705 ($0.25 + $0.375 + $0.08); with 40,000 of those input tokens read from cache, $0.525 - **Session budgets** cap spend: an optional hard ceiling at list prices. When a session reaches it, it pauses (idle) instead of terminating, and raising or removing the budget resumes it. On a deployment, the budget applies to each run - On Claude Platform on AWS, token and runtime charges convert to Claude Consumption Units at the standard rate Translation: for most runs, the runtime fee is a rounding error next to the tokens. The model choice drives the bill. ## SDKs and tooling - Official SDKs: Python, TypeScript, Java, Go, C#, Ruby, PHP (`anthropic` package, beta namespace) - The [[Anthropic CLI (ant)|ant CLI]] (`brew install anthropics/tap/ant`, or `go install github.com/anthropics/anthropic-cli/cmd/ant@latest`) wraps the beta endpoints; handy for scripting and quick tests - `ant apply` (CLI 1.30.0+) manages agents, environments, skills, memory stores, deployments and vaults as files in your repository (vault files need 1.34.0+). Infrastructure as code for agents: files under `agents/`, `environments/`, `deployments/`, `vaults/`..., resources refer to each other by relative path, and a `claude-lock.json` you commit maps each file to its resource ID. It shows a plan and waits for approval; `--dry-run` only prints it - [[Claude Code]] can set the whole thing up for you. Its bundled `/claude-api` skill loads the Claude API and Managed Agents reference material for your project's language (with a `managed-agents-onboard` subcommand), and the `ant` CLI gives Claude an interface to the API. That's the point @ClaudeDevs made in the launch thread - Any HTTP client works via `https://api.anthropic.com/v1/{agents,environments,sessions,deployments,deployment_runs,vaults,memory_stores,...}` - Everything is managed from the [[Claude Console]], part of the broader [[Claude Platform]]. The Console has a deployments page with a cron expression helper ## Managed Agents vs Claude Code Routines vs the Agent SDK Three ways to get Claude to do agentic work without you sitting in front of it. They overlap more since scheduling landed, so here's how I'd pick: | | Claude Managed Agents | [[Claude Code Routines]] | [[Claude Code SDK\|Claude Agent SDK]] | |---|---|---|---| | What it is | Hosted agent harness, configured through the Claude API | A saved Claude Code cloud session (prompt, repos, environment, connectors) that runs on triggers | A Python/TypeScript library that runs the Claude Code binary inside your app | | Who runs it | Anthropic (or your self-hosted sandbox) | Anthropic's cloud | You, in a process you operate | | Billing | API: tokens + $0.08 per running session-hour | Subscription usage (Pro, Max, Team, Enterprise) plus hourly run limits; metered overage if usage credits are on | API tokens; your own compute | | Scheduling | Cron, down to the minute, with timezone | Cron, minimum interval of one hour; plus API and GitHub triggers | Bring your own scheduler | | Secrets | Vaults: MCP credentials and egress-substituted env vars the agent never sees | Environment variables visible to anyone using the environment; API credentials on Pro and Max | Whatever your runtime provides | | Status (Oct 2026) | Public beta | Research preview | A library you install (API key) | | Built for | Products that run agents for many end users | Personal and team automation around your repos | Embedding Claude Code's agent loop in your own software | My take: Routines are the quick win when the work is about YOUR repositories and you already pay for a Claude subscription. Managed Agents is what you reach for when the agent is part of a product, runs on behalf of other people (one vault per user), or needs minute-level schedules and real secret hygiene. And the Agent SDK is for when you want full control and are happy to own the infrastructure. ## Subtopics - [[Claude Managed Agents Sessions]]: session lifecycle, statuses, pinning agent versions - [[Claude Managed Agents Environments]]: containers, networking modes, package managers, runtimes - [[Claude Managed Agents Tools]]: `agent_toolset_20260401`, custom tools, MCP toolsets, skills - [[Claude Managed Agents Events]]: event types, SSE stream, steering, interrupts, tool confirmation - [[Claude Managed Agents Memory Stores]]: cross-session persistent memory; filesystem-backed, exportable, audit-logged (public beta) - [[Claude Managed Agents Dreams]]: Claude reflects on past sessions to clean up and reorganise a memory store; produces a new store, never mutates the input (research preview) - [[Claude Managed Agents Multi-Agent]]: callable agents and threads (beta; research preview at launch) - [[Claude Managed Agents Outcomes]]: rubric-based self-grading loops (beta; research preview at launch) ## Memory at a glance Memory stores let agents learn across sessions instead of starting cold every run. The implementation choice that matters: memory is **mounted as a filesystem inside the agent's container**, so Claude reads and writes it through the same bash and code-execution tools it already uses. No special API surface for the agent to learn. Memories are plain files, fully exportable, fully owned by you. What you get out of the box: - Scoped permissions (org-wide read-only stores; per-user read/write stores) - Audit log of every change, with version history, content rollback, and per-version redaction - Concurrent-safe writes via path preconditions - Shared memory across multiple agents, with different access levels per session Why it matters in practice (vendor-cited results from the announcement): - **Rakuten**: 97% fewer first-pass errors, 27% lower cost, 34% lower latency on long-running task agents - **Wisedocs**: 30% faster document verification by remembering recurring issues across sessions - **Netflix**: agents carry context across sessions without manual prompt updates - **Ando**: captures organizational interaction patterns without building custom memory infrastructure Detail and API: [[Claude Managed Agents Memory Stores]]. ## Branding Partners embedding Managed Agents can use "Claude Agent" or "{YourAgentName} Powered by Claude". Anthropic forbids calling the product "Claude Code" or "Claude Cowork", and forbids mimicking their ASCII art; those names are reserved. ## What the community said The April launch thread on Hacker News (169 points, 87 comments) mostly argued about lock-in. The most-replied comment called being tied to a single model provider a deal breaker for anything complex; another said the best orchestration mixes agents from different vendors. Others read it as Anthropic moving from "token pipeline" to platform, competing with agent SaaS products. I couldn't find an HN thread about the June scheduling and vaults launch. I think the lock-in point is fair (vaults, deployments, `ant apply` files: all of it is Anthropic-specific). But the vault design fixes a real problem: an agent that can read its API keys (in a prompt, a config file, an environment variable) can also leak them. Egress substitution means a prompt-injected agent can't exfiltrate a key it never had. ## References - @ClaudeDevs on X, June 11, 2026 (main post and follow-up about `/claude-api` and the `ant` CLI): https://x.com/ClaudeDevs/status/2065080005328249086 - Launch post, "New in Claude Managed Agents: run agents on a schedule and store environment variables in vaults" (June 9, 2026): https://claude.com/blog/whats-new-in-claude-managed-agents - Original launch post (April 8, 2026): https://claude.com/blog/claude-managed-agents - Overview: https://platform.claude.com/docs/en/managed-agents/overview - Scheduled deployments: https://platform.claude.com/docs/en/managed-agents/scheduled-deployments - Authenticate with vaults: https://platform.claude.com/docs/en/managed-agents/vaults - Session budgets: https://platform.claude.com/docs/en/managed-agents/budgets - Reference (rate limits, branding): https://platform.claude.com/docs/en/managed-agents/reference - Agent setup (models): https://platform.claude.com/docs/en/managed-agents/agent-setup - Memory stores (beta header): https://platform.claude.com/docs/en/managed-agents/memory - Dreams: https://platform.claude.com/docs/en/managed-agents/dreams - Pricing, Claude Managed Agents section: https://platform.claude.com/docs/en/about-claude/pricing#claude-managed-agents-pricing - Claude Platform on AWS, Managed Agents section: https://platform.claude.com/docs/en/build-with-claude/claude-platform-on-aws#claude-managed-agents - `ant apply`: https://platform.claude.com/docs/en/cli-sdks-libraries/cli/apply - `ant` CLI quickstart: https://platform.claude.com/docs/en/cli-sdks-libraries/cli/quickstart - Claude Code bundled skills (`/claude-api`): https://code.claude.com/docs/en/skills - Claude Code commands (`/claude-api` subcommands): https://code.claude.com/docs/en/commands - Claude Code Routines docs: https://code.claude.com/docs/en/routines - Agent SDK overview (SDK vs CLI vs Client SDK vs Managed Agents): https://code.claude.com/docs/en/agent-sdk/overview - Hacker News, "Claude Managed Agents" (April 8, 2026): https://news.ycombinator.com/item?id=47693047 - Quickstart: https://platform.claude.com/docs/en/managed-agents/quickstart - API reference: https://platform.claude.com/docs/en/api/beta/sessions - Request research preview access: https://claude.com/form/claude-managed-agents ## Related - [[OpenAI Agents API]] - [[Claude]] - [[Claude Code]] - [[Claude Code Routines]] - [[Claude Code SDK]] - [[cron]] - [[Claude Platform]] - [[Claude Platform on AWS]] - [[Claude Console]] - [[Claude API]] - [[Anthropic]] - [[Anthropic SDK]] - [[Anthropic CLI (ant)]] - [[AI Agents]] - [[AI Agent Harness]] - [[AI Agent Skills]] - [[AI SDKs]] - [[Model Context Protocol (MCP)]] - [[Large Language Models (LLMs)]] - [[TrueForge]]: open-source, vendor-neutral alternative (TrueFoundry)