Claude Managed Agents is Anthropic product for running sessions of Claude that carry memory, tools and schedules instead of one chat turn. This guide explains the primitives shown during the AI Engineer World's Fair 2026 workshop in San Francisco, and separates the parts you can rely on in production from Dreaming, which remains a research preview.
What Claude Managed Agents actually ships
Claude Managed Agents runs Claude sessions as managed infrastructure rather than a terminal session you babysit. The documented building blocks are agents, sessions, deployments, memory stores, tools, skills and workspaces. Everything is API-driven so you can compose your own harness on top. The Claude Managed Agents documentation is the canonical reference for current endpoints and limits.
The product is not Claude Code wrapped in a server. Anthropic engineers Priyanka Phatak and Gabe Cemaj said at the AI Engineer World's Fair 2026 in San Francisco that they took the Claude Code harness as an inspiration, then built for API consumers who bring their own context and capabilities. Claude Code remains the terminal product with its own defaults.
One naming detail matters for anyone reading older material. Anthropic own engineering post calls the split "the brain from the hands" and describes decoupling the model from the execution layer so sessions can scale independently. That is architecture vocabulary, not a second product name.
What you do not get yet is stated just as plainly:
- Role-based access control beyond workspaces is on the road map.
- On-premises deployment is under consideration without a shareable plan.
- Dreaming is a research preview.
- There is no built-in OpenTelemetry export.
- Only Anthropic models are supported.
Deployments: agent, schedule and resources
A deployment runs one agent on a schedule and gives that run its starting messages and resources. Anthropic demo configured a research desk agent with a weekly memo instruction, a schedule of the first of the month, and attached resources such as memory stores, files or a repository. Each firing creates a session; the memory store persists across sessions because it is an independent entity you attach, not a property of the deployment.
The distinction between a deployment and a snapshot came up directly in the Q&A. A deployment is not a frozen moment in time for all agents; it is a recurring way to run sessions for a specific agent, so you choose which session sees which memory store. A concrete example from the stage: tell the research desk agent to research NVIDIA once every quarter, and it creates a session each quarter that produces the report. Memory state persists across all of those sessions because you attach the store to the session.
Deployments are created and triggered through the API and the SDK, with the console as a convenience layer. Anthropic position is that custom interfaces and workflows are expected: you list, search and start deployments programmatically, then present whatever UI your users need. There is no pod count, Horizontal Pod Autoscaler or timeout parameter to set, and no scaling parameter for "I need 10,000 pods." Anthropic manages the capacity behind the session API, and the only limit you will meet is a rate limit.
In the recorded demo one batch of scheduled runs failed and the presenter said he would ask the agent about it later. Treat that as a fair warning: schedule reliability is something you should monitor in your own error handling rather than assume.
Multi-session fan-out with a custom tool
Fan-out means one request spawns a session per item, and Anthropic implements it with a custom tool rather than a graph editor. In the demo, the agent was asked to analyze Google and Microsoft. It first checked whether it had the information, then called a tool named for dispatching analysis twice, once per ticker, and each call kicked off its own session with its own multi-agent work inside. The parent session decides how many children to create, which is why the team frames the session as the unit of work for builders.
Inside each child session, sub-agents collaborate, and outcomes give the run a stopping condition. An outcome is a rubric the agent is steered toward, with a maximum iteration count so it keeps working until the rubric is satisfied. The separate verifier agent that Gabe Cemaj described is part of that loop rather than a feature you configure independently.
Asked directly whether a graph or topology layer exists, the answer was "not yet." The stated reason is a design position: humans tend to over-constrain how Claude decomposes work, and the team keeps removing those guardrails as models improve. Their claim from the stage is that Claude own choice of topology outperforms a fixed one you impose. Treat that as an Anthropic vendor claim, not an independent benchmark.
So the practical fan-out pattern today is a tool plus sessions plus outcomes. You write the tool, you decide what the parent sees, and you accept that the child topology is chosen at runtime. If you want agent A to delegate to B and C, you do it with sub-agents and instructions rather than a wiring diagram.
Dreaming: what the research preview does
Dreaming is an Anthropic research preview that replays past sessions to improve a memory store. You select a memory store, choose a model, optionally add custom instructions, and point the analysis at a window such as the last 30 days. It then spins up its own session with sub-agents that read the transcripts and ask whether the memory store encoded what was needed, whether sessions hit problems, and whether a problem repeated often enough to fix at the source.
In the demo the analysis found gaps in how a skill had been written and updated the memory store with additional guidance rather than editing the skill itself. The team framed that as the current scope, with skills, agent prompts and sub-agent prompts listed as possible future targets. Those are stated ambitions, not shipped behavior.
Anthropic stated deployment model for Dreaming is deliberately hedged. On stage in October 2026 the team said they run evals internally to check that Dreaming improves outcomes, and that customers have seen significant eval improvement after adopting the resulting memory store. They called the feature early and experimental and referred to general uplift rather than publishing a figure.
That is vendor-reported evidence from a research preview. If you plan to depend on it, keep your own eval suite and compare the new memory store against the old one. An audience member raised the obvious risk: ten sessions may agree that something is wrong while one says it is right, and relying on Dreaming alone can miss the outliers. Evals are how you decide which direction to keep.
Sessions, compaction and the ten-hour reality
Anthropic runs compaction for you so long sessions keep working, and the stage example was users running ten-hour sessions in production. The important word is sessions: the durable pattern for recurring work is a deployment that creates a fresh session per run with persistent memory, not one process left running for six months. When an attendee asked about keeping a daily task alive for months, the answer pointed back to that model.
Context and session state are what Anthropic means by a harness in this product. The team defined it narrowly as the tool loop, context management and session state that let an agent do its work, and noted that most builders use the word to mean coordination of multiple agents into a larger topology. Both readings are legitimate; only one is Anthropic own description.
Memory stores are the persistence boundary and are attached per session, which means you can deliberately keep two workflows from contaminating each other's state, or deliberately share one store so a weekly and a quarterly job learn from the same history. An attendee described harvesting the JSON session files directly and experimenting with managing memories that way; the session abstraction is meant to replace that hand-rolled work.
Observability, evals and exports
Every event in a session is exposed, and the split view is a rendering of that event stream rather than the limit of it. In the console the transcript view is the readable layer; the debug view shows each event with model call start and finish timestamps, which is where latency figures come from. The API returns the same events so you can filter and store them yourself.
Asked whether telemetry is native configuration, the answer was that Anthropic does not predefine what you should observe. You receive everything and choose the filters, and feature requests for missing signals go back to the team. Asked whether an OpenTelemetry (OTEL) export exists, the response was that it does not, but that everything is API calls and a connector is not hard to build. That is a do-it-yourself integration today.
| What you might expect | What Claude Managed Agents gives you |
|---|---|
| Predefined telemetry schema | All raw events, filtered on your side |
| Built-in OpenTelemetry export | No native export; build the connector against the API |
| Native dashboards for your signals | Console transcript and debug views |
| Managed autoscaling parameters | No pod count, HPA or timeout to set |
The recommended way to know whether an agent performs as expected is to run evals on your own task types. Outcomes extend that by letting you write a rubric and an iteration cap so the agent works toward a defined result. Anthropic advice to evaluate after each model release is honest about the cost: it is repetitive work, and skills are their current answer for packaging guidance that survives model changes.
Workspaces, tenancy and the RBAC gap
Workspaces are the tenancy and access boundary in Claude Managed Agents today. Each workspace holds a set of agents, and access is granted per workspace to specific users, so a group can reach everything inside its workspace and nothing outside it. Anthropic engineers described this as the clean primitive available now and acknowledged the gap for finer controls.
For multi-tenant products the guidance was specific: avoid bring-your-own-key designs, because the customer's key means the traffic runs under their credentials and you lose observability. Two patterns were offered instead:
- Share one workspace and keep your own mapping from agent to customer.
- Create a workspace per customer and accept that agents must be recreated in each one.
Role-based access control inside a workspace does not exist yet. Anthropic everything in a workspace is visible to everyone in it and that finer controls are on the road map, so an additional authorization layer in your own application is the practical workaround today. Nothing here is a compliance guarantee; it is an access partition you still have to design around.
Model choice is also constrained. Claude Managed Agents runs Anthropic models, and the platform is available through the Anthropic console and through Claude Platform on AWS rather than through Amazon Bedrock. An attendee reported that a workshop QR link did not resolve, so a direct documentation link is the better citation until the recording's assets are confirmed.
Skills, Claude Code and choosing between them
Skills and multi-agent setups solve different problems, and Anthropic team declined to declare a permanent winner. A skill packages instructions and information the model can load when relevant; multi-agent coordination divides work across sessions toward a larger task. The framing offered was "thick skills, thin harness," which the team expects to thin out further as models improve.
The split between products is about audience. Claude Code is an out-of-the-box terminal product for coding work, while Claude Managed Agents is an API for teams shipping agents to colleagues or customers. Anthropic provides a managed agents skill for Claude Code so you can build your first agent in natural language, and the team suggested translating an existing Claude Code setup by handing the agent both the old configuration and that skill.
There is also a production proof point worth naming: Notion external agents are built on Claude Managed Agents, and the same infrastructure powers Jira integrations with Atlassian. If you are sizing up whether the platform is real, that is the evidence to weigh against the road-map items.
The recommendation for anyone tired of re-evaluating framework choices each model release was blunt: run evals and decide per task. Vendor positions on thick versus thin harnesses have changed before and will change again.
FAQ: Claude Managed Agents questions
Can Claude Managed Agents run an agent indefinitely?
No single session is meant to run for months. Anthropic runs compaction so sessions can last for days, with users reporting ten-hour sessions in production, and the durable pattern for recurring work is a deployment that creates a new session per run against a persistent memory store.
Is Dreaming production-ready?
Dreaming is an Anthropic research preview, and the team described it as early and experimental on stage in October 2026. It can rewrite a memory store from analyzed sessions, but Anthropic reported only general uplift and said customers saw eval improvement, so treat the gain as unverified until your own evals confirm it on your tasks.
Does Claude Managed Agents include RBAC inside a workspace?
Not at the time of the workshop. Workspaces are the access boundary, and Anthropic everything inside a workspace is visible to everyone in it, with finer controls on the road map. Any role-based access control has to be implemented in your own application layer.
Can I use non-Anthropic models?
No. The platform runs Anthropic models, and the September 2025 announcement framed Claude Managed Agents as an Anthropic-model service available through the Anthropic console and Claude Platform on AWS, not Amazon Bedrock.
How do I know my agent is working as expected?
Define your own evals for the task types you care about, then use outcomes with an explicit rubric and iteration cap to steer the agent toward a verifiable result. This is what Anthropic engineers recommended when asked directly, and they tied it to Dreaming evaluation.
What is a harness in Claude Managed Agents?
Anthropic uses harness to mean the tool loop, context handling and session state that let an agent act. Many builders use the same word for coordinating multiple agents into a topology, which Claude Managed Agents leaves to you with the session as the primitive.
Can I export telemetry to OpenTelemetry?
There is no built-in OpenTelemetry export. Every event in a session is available through the API, so a connector is straightforward to write, and Anthropic welcomes feature requests for additional signals.
Is Claude Managed Agents built on Claude Code?
Anthropic describes the Claude Code harness as an inspiration rather than the implementation, and positions Claude Code as a terminal product while Claude Managed Agents is an API and infrastructure layer for teams shipping agents. The team said the API product is meant to scale and be reliable where the terminal tool targets individual workflows.
Does an end user need a paid console account?
No. An Anthropic console account is free to create, and it is where you generate the API key. Billing is based on token usage, and end users of a product you build interact with your interface rather than the Anthropic console.
What can I deploy with MCP channels?
The stage comparison was to MCP channels that expose Claude through a chat-style surface. The distinction is what you control: with a managed session you spawn a server per project and call into it, while the session itself is the abstraction you compose around. Both patterns coexist, and which one you pick depends on whether your users need a chat interface or a task that runs to an outcome.
How Skalablog turns this kind of talk into an article
This workshop packed fan-out, deployments, Dreaming, tenancy and a candid road map into a single recorded session, and the value for a reader comes from separating what ships from what is promised. If you have recordings, interviews or internal walkthroughs holding that same kind of operational knowledge, Skalablog is built for this exact conversion: paste a YouTube URL, let it transcribe the video and generate a structured article you can edit and publish.
The workflow is straightforward. Bring the video link to Skalablog, review the transcript it produces, and shape the draft around the decisions your audience actually faces. You can try the flow at Skala Blog, and the same approach fits Portuguese-language content such as the work shared through Crazystack and communities like Crazystack Typescript.
Gustavo Dev Doido and the Bootcamp do Dev Doido show that Brazilian developers are producing plenty of technical material on video. Skalablog exists to help that material reach people who would rather read than watch.