Anthropic Managed Agents: Claude Runs the Loop for You

June 23, 2026 · updated June 25, 2026 · How Claude Actually Works (part 19)

▶ Watch on YouTube & subscribe to The Stack Underflow

Every agent you have built so far — whether a hand-rolled loop in Python or a workflow wired through the Claude Agent SDK — has one thing in common: your infrastructure owns the runtime. Your code calls the model, parses tool calls, executes them, feeds results back, and decides when to stop. That is fine engineering. It is also a lot of plumbing that regenerates across every project: state persistence, sandbox isolation, pause-and-resume, multi-agent delegation.

Anthropic’s managed agents surface, launched in public beta on April 8, 2026, flips that ownership model. You provision three kinds of assets — agents, memory stores, and vaults — and Anthropic’s infrastructure handles the loop, the sandbox, and the persistent state. You stop babysitting a while-loop and start describing what you want to run.

The one-sentence version: Managed agents let Anthropic run the agent loop, tool execution, and persistent session state in their cloud — you provision assets instead of owning the runtime.

The Ownership Flip: Hand-Rolled vs. Managed

Both approaches use the same underlying Claude model. The difference is purely about who owns the runtime around it.

HAND-ROLLED (Agent SDK / your own loop)
┌─────────────────────────────────────────────┐
│  Your Application                           │
│  ┌───────────────────────────────────────┐  │
│  │  Agent Loop (your code)               │  │
│  │  1. client.messages.create(...)       │  │
│  │  2. parse stop_reason == "tool_use"   │  │
│  │  3. execute tools locally             │  │
│  │  4. append tool_result to messages    │  │
│  │  5. repeat until stop_reason=="end_turn" │
│  └───────────────────────────────────────┘  │
│  You own: state, sandbox, retries, pause    │
└─────────────────────────────────────────────┘

MANAGED (loop lives in Anthropic's cloud)
┌─────────────────────────────────────────────┐
│  Your Application                           │
│  POST /v1/sessions  ──────────────────────► Anthropic Cloud
│  ← session_id                              │  ┌──────────────────────┐
│  GET  /v1/sessions/{id}/await_completion ──► │  harness (the loop)  │
│  ← final result + outputs                  │  │  sandbox (container) │
└─────────────────────────────────────────────┘  │  session log (state) │
                                                 └──────────────────────┘

Anthropic’s engineering blog describes the internal architecture as “decoupling the brain from the hands” (2026). The session is an append-only log of everything that happened. The harness is the loop that calls Claude and routes its tool calls. The sandbox is the execution environment where Claude runs code and edits files. Containers provision only when a tool call requires them — inference starts immediately off the session log, which cut p50 time-to-first-token roughly 60% and p95 over 90% compared to pre-provisioned containers.

The Three Assets You Provision

Managed agents replaces a loop you write with three declarative resources you create once and reference at runtime.

One agent definition can spawn many live sessions simultaneously — “one recipe, many running timelines.” Sessions are stateful: they pause and resume cleanly, preserving conversation history, sandbox state, and outputs server-side. You do not implement any of that persistence yourself.

Asset 1: Agents and Sessions

An agent is the recipe. It carries a name, a model ID (for example claude-opus-4-8 for complex long-horizon work, or claude-sonnet-4-6 for speed-sensitive tasks), a system prompt template, and the set of tools the session can use.

A session is the running instance. When you start a session against an agent definition, Anthropic’s harness begins the loop. You can:

• Poll for completion
• Stream partial results as they arrive
• Pause the session mid-run and resume it later
• Inspect the full session log for debugging

Agent Definition (created once)
  name: "research-assistant"
  model: "claude-opus-4-8"
  system: "You are a research assistant..."
  tools: [web_search, file_read, file_write]
         │
         ▼
Session A (user: alice) ──► running, sandbox active
Session B (user: bob)   ──► paused at tool call, awaiting resume
Session C (user: alice) ──► completed, log archived

Billing adds a runtime layer: as of the April 2026 public beta launch, managed sessions cost $0.08 per runtime hour on top of standard model token charges. That is the price of not owning the sandbox and harness yourself.

Asset 2: Memory Stores

A memory store is a workspace-scoped collection of small text documents. When a session starts with a store attached, the store mounts as a filesystem directory inside the sandbox. The agent reads and writes it using the ordinary file tools — no special memory API, just file I/O.

The critical property: the same store re-mounts when a new session starts. That is how an agent carries knowledge across separate runs — user preferences, hard-won conventions, past mistakes, factual corrections. Without a store, each session starts cold. With one, it picks up whatever it wrote last time.

Session 1 (Monday)
  ┌─────────────────────────────────┐
  │  sandbox/                       │
  │  └─ memory/                     │
  │     └─ user_prefs.txt  ◄── agent writes: "prefers metric units"
  └─────────────────────────────────┘
            │ store persists
            ▼
Session 2 (Friday)
  ┌─────────────────────────────────┐
  │  sandbox/                       │
  │  └─ memory/                     │
  │     └─ user_prefs.txt  ◄── agent reads: "prefers metric units"
  └─────────────────────────────────┘

Every mutation to a memory document produces an immutable memory version (prefixed memver_), giving you a full audit trail and point-in-time rollback. This is the mechanism the Anthropic engineering announcement calls “persistent memory” — structured, versioned, filesystem-accessible state, not a black-box embedding index.

Asset 3: Vaults

A vault stores credentials an agent needs to act on behalf of a user — MCP server tokens, OAuth credentials with auto-refresh, or static bearer tokens. Vault entries are workspace-scoped and referenced by a human-readable display name; the session receives a placeholder, and the actual secret is substituted at the network boundary when the agent makes an outbound request.

Agent config references: vault_id = "rakuten-sheets-oauth"
                                  │
              ┌───────────────────┘
              ▼
  Vault entry (stored server-side)
  ┌──────────────────────────────────┐
  │  type: mcp_oauth                 │
  │  mcp_server_url: sheets.api/...  │
  │  access_token: [opaque]          │
  │  refresh_token: [opaque]         │
  │  expires_at: 2026-09-01T00:00Z   │
  └──────────────────────────────────┘
              │ substituted at egress only
              ▼
  Agent sandbox never sees the raw token.
  Even a successful prompt injection cannot exfiltrate it.

Three vault credential categories exist as of June 2026: mcp_oauth (OAuth with auto-refresh, keyed by MCP server URL), static_bearer (fixed token, keyed by MCP server URL), and environment_variable (opaque placeholder substituted at egress, keyed by secret name). Secrets are provisioned into the vault once and referenced by name — you never pass credentials through your application code or bake them into agent configurations.

The Beta Header and Same API Key

As of June 2026, every managed agents call requires one additional HTTP header:

anthropic-beta: managed-agents-2026-04-01

The TypeScript and Python SDKs set this automatically on all client.beta calls to the managed surface. All authentication uses your existing API key — the same key that authenticates messages.create at L1 also authenticates agents, sessions, memory stores, vaults, and cron schedules. One platform, one key, additional resource families.

Cron scheduling — attaching an agent to a firing schedule so it starts a new session automatically — was added to the beta in June 2026 (announced at Code with Claude Tokyo). Each schedule fire starts a fresh session; customers can pause, resume, archive, or trigger extra on-demand runs through the same API.

When to Choose Managed Over Hand-Rolled

The choice is a control/convenience trade-off, not a capability difference. The model is identical.

Hand-rolled is the right default when you need tight custom retry logic, non-standard orchestration (fan-out, voting ensembles, conditional branching), deep observability hooks at every step, or tool implementations that cannot be expressed as MCP servers. The Agent SDK tutorial covers that path in depth.

Managed is the right default when persistence, sandboxing, multi-agent delegation, scheduled runs, and reduced boilerplate matter more than maximum control — especially when your tooling is already MCP-compatible.

Common Misconceptions

“Managed agents use a smarter or different model.” No. It is the same claude-opus-4-8 or claude-sonnet-4-6 you use in messages.create. The difference is who runs the harness and sandbox around the model call, not the model itself.

“Memory stores are a vector database or semantic search index.” No. Memory stores are explicitly a workspace-scoped document folder mounted into the sandbox as a filesystem directory. The agent reads and writes files with standard file tools. There is no embedding layer; it is structured text persistence, not RAG.

“You need a separate API key or account for managed agents.” No. Your existing API key authenticates both the core messages.create surface and every managed resource — agents, sessions, memory stores, vaults, and cron schedules. One platform, one key.

“Sessions are just conversation history.” Partially right but incomplete. Sessions are resumable, pauseable instances that preserve not only message history but also sandbox filesystem state, tool execution state, and session outputs — all server-side. Pause-and-resume is a first-class platform feature, not an afterthought you implement with a database.

Frequently Asked Questions

What happens to a session if I do not explicitly close it? Sessions are designed to be long-running and resumable. The platform stores the session log, sandbox state, and outputs server-side. Exact timeout and expiry policies follow Anthropic’s platform terms for the beta. The operationally important point is that pausing and resuming is the intended pattern — you do not need to keep a long-lived connection open.

Can one agent definition run in multiple sessions simultaneously? Yes — that is the central point of the agent-versus-session distinction. An agent is a template; you instantiate as many live sessions from it as you need. Multi-tenant workloads give each user their own session (with their own vault reference for credentials) while sharing a single agent definition.

Are memory stores shared across agent definitions or per-agent? Memory stores are workspace-scoped, not agent-scoped. You attach a store to a session by reference (resources: [{ type: "memory_store", id: "..." }]). Multiple sessions — even sessions from different agent definitions — can mount the same store, giving you a shared knowledge layer across an entire workspace if you want it.

Is the managed agents surface production-ready? As of June 2026 it is in public beta behind the managed-agents-2026-04-01 header. Anthropic’s beta headers signal that the feature is functional and available but may still change API shape before a stable release. For production workloads you should pin the beta header version and watch the changelog — the same discipline you apply to any versioned API.

What does the runtime hour charge cover? The $0.08/runtime hour fee (as of the April 2026 launch) covers the harness, sandbox container, and session persistence infrastructure. Token costs for model calls are billed separately at the standard per-token rate for whichever model your agent uses. Short sessions that spend most of their time in model inference rather than tool execution will be dominated by token costs; long-running sessions with heavy code execution or file I/O will see the runtime hour charge become more significant.

Can managed agents work with custom MCP servers? Yes. The agent’s mcp_servers array declares each server by type, name, and URL — no auth inline. Credentials for those servers live in vaults and are attached to the session via vault_ids. Anthropic’s proxy intercepts MCP calls, fetches the relevant credential from the vault, and substitutes it at the network boundary, so the model’s context never sees the raw secret.

Where This Fits in the Series

Managed agents sit at Layer 4 of the Claude Stack — the most hands-off way to deploy the same infrastructure you have been building across this series. To understand what Anthropic’s harness is doing on your behalf, revisit how the agent loop works under Claude Code and how Claude uses tools — those are the mechanics the managed harness wraps. If you are choosing between the Agent SDK and managed agents for a new project, the Agent SDK tutorial covers the hand-rolled path in depth.

The next episode in the series moves down a different axis: Claude Code in CI/CD — headless mode, where a single claude -p command becomes the agent surface. Browse all tutorials to follow the full series.