Anthropic Managed Agents: Claude Runs the Loop for You
▶ Watch on YouTube & subscribe to The Stack Underflow
When you build an agent by hand, your application owns the loop: call the model, parse tool calls, execute them, feed results back, repeat until done. That is fine — it is explicit, debuggable, and fully under your control. Anthropic’s managed agents surface flips the ownership model: you send a request, and Anthropic’s infrastructure runs the loop, the tool sandbox, and the stateful session for you.
This page maps out exactly what that means, what moves server-side, and when you would choose managed over hand-rolled.
The one-sentence version: Managed agents let Anthropic run the agent loop, tool execution, and persistent state in their cloud so your app only has to send a request and receive results.
The Two-Layer Picture: Hand-Rolled vs. Managed
Both approaches use the same underlying Claude model — the difference is who owns the runtime.
Hand-Rolled (L4 of the stack)
┌────────────────────────────────────┐
│ Your App │
│ ┌──────────────────────────────┐ │
│ │ Agent Loop (your code) │ │
│ │ 1. messages.create(...) │ │
│ │ 2. parse tool_use blocks │ │
│ │ 3. run tools locally │ │
│ │ 4. append tool_result │ │
│ │ 5. repeat until stop │ │
│ └──────────────────────────────┘ │
└────────────────────────────────────┘
Managed (loop lives in Anthropic's cloud)
┌────────────────────────────────────┐
│ Your App │
│ POST /agents/{id}/sessions │ ──► Anthropic Cloud
│ ← final result │ ┌────────────────┐
└────────────────────────────────────┘ │ loop │
│ tool sandbox │
│ session state │
└────────────────┘
The API surface is the same platform and the same API key. One key authenticates both the standard messages.create calls at L1 and the managed resources — agents, sessions, memory stores, and vaults.
What Moves Server-Side
Three things that you would otherwise manage yourself now live inside Anthropic’s infrastructure:
| Resource | What it is | Who owns it |
|---|---|---|
| The loop | Call → tool → result → repeat | Anthropic’s runtime |
| Tool sandbox | Isolated execution environment for tools | Anthropic’s runtime |
| Persistent state | Sessions that can pause and resume | Anthropic’s runtime |
Agents vs. Sessions
The managed surface distinguishes two concepts that are easy to conflate:
- An agent is a recipe: a name, a model choice, and a system prompt template. Think of it as a class definition.
- A session is a running, resumable instance of that recipe. Think of it as an object instantiated from that class.
One agent definition can have many live sessions running simultaneously — “one recipe, many live timelines.” A session is stateful: you can pause it, come back later, and it resumes exactly where it left off. That is infrastructure Anthropic manages; you do not have to store conversation history yourself.
Memory Stores
A memory store is a small document folder scoped to your workspace. When a session starts, the store mounts as a directory inside the session’s sandbox. The agent reads and writes files in it using standard file tools.
The useful part: the same store remounts when a new session starts. That is how an agent carries knowledge across separate runs — preferences, conventions, past mistakes, user-specific facts. Without a memory store, each session starts cold. With one, it picks up context it wrote down last time.
Vaults
A vault holds an end user’s credentials, scoped to your workspace and addressed by a human-readable display name. A session references the vault by name to act on behalf of that user.
This matters for security hygiene: secrets are provisioned into the vault once and referenced by name at runtime. You do not hard-code credentials into agent configurations or pass them through your app code. The vault is the managed secret store.
The Beta Header
As of June 2026, every managed agents call requires one additional HTTP header:
Anthropic-Beta: managed-agents-2026401
This is the feature flag that routes requests to the managed surface. All other authentication is the same — your existing API key.
Picking the Right Model
The trade-off is straightforward:
| Hand-Rolled | Managed | |
|---|---|---|
| Code to write | More | Less |
| Control | Full | Partial |
| Persistence | You implement | Built-in |
| State management | You implement | Built-in |
| Sandbox | You manage | Provided |
Hand-rolled is the right default when you need tight control over retry logic, custom tool implementations, non-standard orchestration, or observability hooks you cannot add to a managed loop. Managed is the right default when persistence, sandboxing, and reduced boilerplate matter more than maximum control.
Neither is objectively better. Both sit on the same platform with the same API key.
Common Misconceptions
- “Managed agents use a different, more capable model.” No — it is the same model. The difference is who runs the loop around it, not the model itself.
- “Memory stores are a vector database.” No — a memory store is explicitly described as a small document folder. It is a file-system-style mount, not a semantic search index.
- “You need a separate API key for managed resources.” No — one API key authenticates both standard
messages.createcalls and all managed resources (agents, sessions, stores, vaults). - “Sessions are just conversation history.” Partially true but incomplete. Sessions are resumable, pauseable instances of an agent recipe that include tool state and sandbox state, not just message history.
Frequently Asked Questions
What happens to a managed session if I do not explicitly pause it? Sessions are stateful and designed to be pauseable and resumable, but the exact lifecycle (timeout, expiry) would depend on Anthropic’s platform policies. The key point from the video is that pause-and-resume is a first-class feature, not an afterthought.
Can one agent recipe be running in multiple sessions at once? Yes — that is precisely the point of the agent-versus-session distinction. An agent is a template; you can instantiate many live sessions from a single agent definition simultaneously.
Are memory stores shared across agents or per-agent? Memory stores are described as workspace-scoped. They mount into sessions by reference, meaning the same store can in principle be used by different sessions (and even different agent recipes) within a workspace.
Is the managed agents surface production-ready?
As of June 2026 it is behind a beta header (managed-agents-2026401), which signals it is not yet at the same stability tier as the core messages.create API. Beta headers in Anthropic’s API are used for features that are functional but may still change shape.
Where This Fits in the Series
This tutorial is part of How Claude Actually Works, a practical course that builds a layered mental model of the Claude platform — from raw token generation at L1 up through tool use, multi-agent orchestration, and reliability concerns. The managed agents surface sits at L4 of that stack, where agent loops live. The next topic in the series covers the reliability plane: how to make agents not hallucinate or fail silently in production.
Browse all tutorials in the series at /tutorials/.
Found this useful? The deep version lives on YouTube — new breakdowns of how AI dev tools actually work, weekly.
Subscribe on YouTube →