- Isabella He from Anthropic's Applied AI team walks through Claude Managed Agents, the first harness that handles scaling, sandboxing, observability, and tool runtime for production-ready agents, so developers focus only on tasks, tools, and agent configuration.
- In a hands-on workshop, attendees build a site reliability (SRE) incident-response agent step by step from four primitives: agent definition, environment, session, and local tools — running the agent loop server-side with full persistence.
- The session explains key design decisions like decoupling the agent's "brains" from its "hands" (cutting P95 time-to-first-token by over 90%), event-based sessions, state management, and previews advanced features: sub-agents, memory, dreaming, outcomes, and vaults.
Ship your first Managed Agent
- Claude Managed Agents is the latest step after the Messages API (2023, raw model access where developers built every primitive themselves) and the Agent SDK (programmatic Claude Code, but developers still managed hosting and scaling). Managed Agents handles scaling and production components with a purpose-built harness, sandboxing, observability, tool runtime, and managed infrastructure.
- Teams have shipped to production 10–15 times faster with Managed Agents because harnesses should evolve alongside agents — for example, Sonnet 4.5's "context anxiety" (stopping tasks early) required harness mitigations that became obsolete once Opus 4.5 removed the behavior.
- Three primary resources build an agent: the agent endpoint (the persona/capabilities — model, system prompt, MCP servers, skills — the "brain"), the environment (the container where actions happen — the "hands"), and sessions (which bind an agent instance to an environment and stream events).
- A key design decision decouples the agent loop from tool execution (separating "hands" from "brains"), improving credential security via sandboxing and cutting P95 time-to-first-token by over 90%, since containers no longer spin up per session for the loop.
- The workshop builds an SRE agent: defining an agent with Claude Opus 4.7 plus a simple system prompt and tools (get metrics, recent deploys, get diff, fetch logs), attaching logs via the files API, binding everything in a session, streaming events to the UI, implementing local tools, and supporting session deletion for security.
- Sessions speak in events (user messages, tool calls, agent responses) rather than request/response tokens, which makes them logged for observability, resumable, and reliable — if a container goes down it can be restarted without restarting the whole agent loop.
- Everything persists in the cloud: hard-refreshing the page retains all sessions and conversation state without managing a database, and session states (idle, running, rescheduling, terminated) enable resumability and webhook-triggered actions.
- Beyond the basics, Managed Agents offers sub-agents (orchestrator spinning up parallel context windows), memory with a dreaming service for self-improving agents, outcomes (defining a rubric the agent works toward), vaults (encrypted per-user/per-session credential storage), webhooks, fine-grained permissions, MCP tunnels, and a console agent builder with observability dashboards.
Claude Managed Agents — Anthropic's first harness that handles scaling, sandboxing, observability, and tool runtime so developers focus on agent configuration and custom logic.
Harness — The infrastructure layer around a model that manages primitives like context management, the agent loop, compaction, and caching.
Agent endpoint — The agent's persona and capabilities (model, system prompt, MCP servers, skills) — the "brain" of the agent.
Environment — The container where an agent takes actions — the "hands" of the agent.
Session — A binding of an agent instance to an environment that streams events and enables resumability.
Time to first token (TTFT) — A latency metric; decoupling the agent loop from tool execution cut P95 TTFT by over 90%.
Context anxiety — A Sonnet 4.5 behavior of wrapping up tasks early even with context to spare, later removed in Opus 4.5.
Dreaming — A service for Managed Agents that lets Claude review its own memory logs to decide what to keep, enabling self-improving agents.
Outcomes — A feature letting you define a rubric the agent works toward rather than just executing tool calls.
Vaults — Encrypted, per-user/per-session credential storage built into Managed Agents.
Hello everyone. It's great to see you all here today for our session on shipping your first managed agent. My name is Isabella He. I'm a member of technical staff at Anthropic on the Applied AI team. The Applied AI team at Anthropic sits at the intersection of products, research, and our customers, which means that I get to contribute internally to products at Anthropic like Claude Code and our Claude harnesses, as well as work externally with our customers that are building on top of Claude and on top of our harnesses. So my goal today is to get you all hands-on with actually building on top of managed agents, understanding how the harness works under the hood, and getting you ready to actually ship your first incident response agent.
The quick overview of today's agenda: we're going to cover first a quick refresher of Claude managed agents. I want to talk you through a little bit about how this harness works under the hood and what makes it so special. Our team put a lot of thought into the architectural design of Claude managed agents to make sure that it runs ready and reliably for production-ready agents. Then we transition to the second portion, which is the hands-on workshop, where you'll actually understand what each of the primitives you're building actually means for your agents under the hood. For the majority of today's session, I want you all to actually have your laptops open, building alongside me, actually working inside of a repository, and getting you ready to spin up a working incident response agent. Lastly, we'll talk a little bit about "beyond the basics." Today's session is the first of a couple of others that will build on top of this on Claude managed agents. Specifically, right after this one, there's another session on dreaming, which is one of my favorite new features with Claude managed agents for self-improving agents and memory built into the harness.
So let's first touch on how we got here with Claude managed agents. When we first released the very first Claude back in 2023, we released a Messages API alongside access to Claude. This provided raw model access to all Claude models. This became the very first way that people could programmatically build on top of Claude and essentially gave a way for people to access tokens in and tokens out via our Claude models. This also meant that for everyone building on top of Claude models, they had to implement all the various primitives themselves — things like context management, the actual agent loop, compaction, etc. All the primitives that come alongside making the agent work. When models were less intelligent back in the early days of, let's say, 2023, some of these primitives were much simpler because agents could simply do less. But as we evolved into now with higher model intelligence, and as agents are able to take on more complex tasks and actually take actions within environments and come to do entire tasks for humans, the primitives that come alongside context management and managing an agent's ability to execute API calls and tool calls become much more complex.
So that's when we moved to the Agent SDK, which became a harness that allows you to programmatically call Claude Code, one of our agents at Anthropic. So Claude Code is something where an agent has access to a computer and takes actions within a file system. The Agent SDK became a way for you to make Claude much more powerful by leveraging the power of Claude Code within a harness. The main thing here, though, is that with the Agent SDK, developers still had to manage hosting and scaling on their own and making sure that the Agent SDK would be safe to run within their containers. That's only then evolved into Claude managed agents, which is the first harness to be able to handle scaling and production-ready components for you by Anthropic, providing things like a purpose-built harness, sandboxing, observability, tool runtime, all within a managed infrastructure system. This means that developers can focus on task and agent configuration, custom tool logic, the things that actually matter for bringing domain expertise and customizability to your agents, where you're handing off the rest of all the primitives and core compute of essentially managing the basics of agent running to Anthropic.
So that brings me to managed agents as the fastest way to build production-ready agents on Claude. We've seen people build 10 to 15 times faster to production with Claude managed agents by leveraging our purpose-built harness. Part of the reason why we built Claude managed agents is because harnesses should evolve alongside your agents. For example, back when we were building ourselves on top of models like Sonnet 4.5, we noticed that Sonnet 4.5 emitted a particular behavior called context anxiety. This meant that with Sonnet 4.5, Claude started wrapping up tasks early even when it still had room to spare in its context window. To manage that in our harness, we then added some mitigations to combat against this early stopping behavior. But when Opus 4.5 then came out, we actually saw this behavior go away, making all that work we had done inside the harness essentially obsolete because Claude had evolved beyond that behavior. So the takeaway there is that it's a lot of work to maintain harnesses and make sure that they actually evolve alongside your agents, which is why with Claude managed agents, we want to make it really easy for Claude and Anthropic to handle all the complexities that come with compaction, caching, things like context anxiety, all these various primitives that come with actually making agents production-ready and getting the most out of Claude.
So three primary resources go into building on Claude managed agents. First is the agent's endpoint, which is the persona and capabilities. This is the core system prompt that powers your agent. Essentially here, you're defining the model, the MCP servers, the skills, the various components that your agent can actually leverage when it's able to run in that agent loop. The next is the environments. You can think of this as the hands of the agent, where the previous one is the brain of the agent where the agent is thinking through what to execute, and then it's using an environment to actually have a space and a container to take action on your behalf. Sessions are next — the way to tie together agents and environments. A single session has a spun-up agent instance within an environment. So you can connect the two together and actually stream events back to your user and start to take action on behalf of your humans as part of a Claude-powered agent. A key thing here is that Claude managed agents has the agent loop run server-side. This means that a lot of the complexities that come with managing hosting and scaling are abstracted away. And when you close your laptop or you hit hard refresh on your agent, everything is maintained and you don't have to worry about durability, reliability, all these various aspects that usually come to bite you when you're trying to turn your agent from a prototype into production.
And lastly here, before we dive into the hands-on portion, I want to talk you through a key design decision that went into Claude managed agents. Previously, with a lot of agent harnesses, we saw the agent loop coupled tightly with tool execution. This design pattern made sense and still makes sense for some agents because you want to give the agent powerful abilities to take action within the environment. For instance, with Claude Code, we want the agent to be able to access various files on your computer, take action within a file system, and therefore it makes sense for the agent to have access to all those tools spun up on every container. But we also realized there are some constraints for this, especially with some agents where you essentially want to be able to decouple the hands from the brains of the agents. For instance, credentials and security became a huge concern. With the ability to have the agent access your file system, you can actually add very distinct sandboxing by decoupling these two components, where the agent is no longer able to access the actual credentials without encryption. The other aspect is you can see huge benefits by doing this decoupling on things like time to first token and latency. Previously, with the agent loop and execution in the same box, you had to spin up containers for every single session, which contributed to additional latency from a time-to-first-token perspective. But with this now decoupled, our teams actually saw reductions in time to first token along the lines of over 90% reduction in TTFT for our P95 metrics on latency. So here you can start to see the power of this design decision coming through from the perspective of safety, reliability, latency, and everything else that you care about when it comes to building production-ready agents.
All right, so now it's time for the exciting part, which is where I want you all to open up your laptops and go to this URL to actually clone a repository, and let's start to feel the magic of everything that I just talked through. Here are some additional commands that I want you all to run to make sure this is all set up on your computers. Take that repository, hit the URL, git clone it, and then CD into the specific repository for the session, which is "ship your first managed agent." If you're on Mac, you'll see those two commands on the side, the Python and the source (there's a command for Windows as well). You'll install the requirements, copy over the environment key into your .env file — here you'll put in the Anthropic API key that hopefully all of you also received from the QR code for free credits earlier. And lastly, we'll just run the app. If you go into the repository in the link and then go to "ship your first managed agents," scroll down on the readme, you'll see all the setup instructions here.
So once you run streamlit run app.py, you should be able to see a URL that looks like this and a page that looks like this. What we're doing here is we're going to be simulating an agent interaction where we have an incident that's going to come up. A lot of you who might be software engineers in the room will be intimately familiar with the pain that comes alongside incident response. If you are a software engineer, you might be woken up at, let's say, 3 a.m. in the morning when you're on call, and this is usually a very painful portion of a software engineer's life, because when you're on call, it means that if a server goes down or a service goes down, you have to be immediately the one there to respond and tackle the incident. Usually for a human, this means diving into metrics and logs and deployments. And so what we're going to do is we're going to now have an agent run on Claude managed agents to do all this for us. So that when we get woken up by 3 a.m., we can hand it off to an agent, or maybe we don't even get woken up at all if Claude is able to do everything for us.
Let's now dive into the code here. What we're going to open up is we have the agent.py file on the left and the agent complete on the right. If you want to challenge yourself, you can of course try to implement everything yourself with Claude. But what we're going to do, just for simplicity's sake, is just copy over various elements from the completed file onto the incomplete file one by one. So you can see how these primitives compose our agent one piece at a time. Let's start off with this very first part, which is the agent. We mentioned before that the agent is the one that defines the persona and the capabilities — that's model, the system prompts, and the tools in our case. We're defining the SRE agent. We're going to use Claude Opus 4.7 here. And I've preconfigured a system prompt and tools for the agent. For the system prompt, you can see that it's actually extremely simple for the agent that we're defining today. We're just telling it that it's an SRE agent. It's responsible for coming in and debugging incidents, and it has access to various tools like metrics, recent deployments, get diff. These are tools that you would want as a developer if you're actually managing an incident response as well, like the ability to fetch logs so you can see exactly what's going wrong. So that's step one. Now let's move on to step two, which is the environment where the agent is going to actually do work in.
All of you here were very lucky for those of you who were able to come yesterday as well to Code with Claude London. We actually just released yesterday the ability to bring your own containers and your own compute to Claude Managed Agents, which means that you can actually execute the agent's tools and the actual ability for the agent's actions to work within your own infrastructure and not just Anthropic's managed infrastructure. We're defining our SRE agent to work within the Anthropic cloud, and here we're just giving it unrestricted access from a networking perspective. We've made Claude Managed Agents very composable and very customizable. So this networking list here is actually an allowed list. If you want your agent to only be able to access specific sites and URLs, you can restrict this down as much as you would like. We also released Claude MCP tunnels, which gives you the ability to run MCP servers within a private environment instead of on the public network. So here we have a unique identifier for an agent and an environment.
The next thing that we have to do is actually give our agent the ability to look at logs. With Claude Code, that is one of the first times where we realized the power of giving the agent access to files and a file system. Here with Claude Managed Agents, we're leveraging essentially the files API by uploading the metrics and logs to the agent, so the agent can start to run code and process through those files. The key takeaway is: as much data as you're able to give the agent is what makes it so powerful. Context engineering is a huge portion that comes to actually making an agent powerful. This is where we see the developers spending the majority of their time working on top of primitives like Claude Managed Agents — managing context and managing what types of files are uploaded, how the agent processes those files.
Now let's define the session. The session is going to bind the agent and the environment and also mount the log. So you can see we're passing in the agent ID, the environment ID, and the resources that we're giving to the agent. What we want to do is now also give the ability for the agent to come in and stream responses to me as we go along. The key portion here is that when our Claude Managed Agents runs within a single session, instead of responding in tokens in and tokens out, it actually works in units of events. Events here are things like user messages or agent tool calls, agent responses, so that every event can be logged from an observability perspective, as well as streamed back to the user for the user to see the agent responding as it calls tools and as it starts to populate responses. This is crucial for both a user experience perspective and from an observability perspective, and Claude Managed Agents actually has a very neat console built in for looking at everything the agent is doing.
If I send something like "hi" to the agent, it can respond, but it doesn't actually have the ability to call the various tools that we want it to yet, because we haven't connected that locally. The agent is ready and defined on the server side already. The missing piece here is just to finally give it our local tools so the agent can start to take action on my computer or my infrastructure. Now the agent is going to be able to start to call get metrics, get recent deploys, get diffs, so it can truly start to take action in terms of helping us debug this incident. The last thing I'm going to do here is also make sure I give my agent the ability to delete sessions. This is crucial from a security perspective — if you want to make sure that nothing is being retained for sessions that you don't want on the cloud or on your infrastructure, you can actually just come in and proactively manage how sessions are deleted. And once they're deleted, they will be also removed from every single log aspect, so that you can truly make sure that whatever data you want managed is managed actively and proactively.
So with that all set up, let's give our agent a test run. I'm going to click the new session here, and ask the agent to debug my incident for me. You can see here that because we gave the agent access to tools like sandboxing and bash, and get recent deploys, the agent is starting to take powerful actions on my behalf. It's run the sandbox command. We can see that it's actually coming in and looking at what the logs were added to. It's then called this tool called get recent deploys, which is returning results like what the recent deployments look like, the metrics. And again, we can start to see the magic of that streaming come through, because we saw these tools come in as they were being called from the agent. We saw the user prompt come in as soon as I prompted it, and the agent is actually streaming responses to me as it comes through with more token response and outputs.
We can see here that the incident is that there's something going wrong with our P99 latency that seems to be 10 times above the baseline. The agent is coming in and debugging everything for us. Some of the major design decisions that come in here when you're designing a real site reliability / incident response agent for your systems is to think deeply about the various components, MCP servers, and skills that you want to give your agent. Here we've defined a very simple agent, but for lots of the SRE agents that we build, we actually also think about things like how can we give the agent a skill to execute and run runbooks. Runbooks are things where, as teams debug incidents, they note down and document how they debug that incident so that they can do it again for a future session or incident. You want to give the agent the same access to the materials that you would have as a human developer.
Let me start a new session here. Let's say "debug my incident for me." Is anyone able to get it working on their laptops better than I have on the screen? Okay, we got some success in the room. Looks like we are streaming. The agent is checking logs, debugging everything. The data that's being passed in for our agent here is all local just for our purposes for our demo workshop today. But with the ability for you to run your agents within a container and infrastructure, you can start to see how things like your get metrics tool that are currently pulling from JSON can be easily moved to something like DataDog or other production systems. Oh, there we go. Success. So the agent has come in. If we scroll through all the tool calls, everything is persisted in the cloud from a logs perspective. All of this will also be logged in the observability console. And then the agent has come back to us with the incident response. It says that this seems to be caused by a database pool exhaustion. Seems like a commit that someone added from Alice to refactor the order summary builder introduced a query that then caused the pool resources to be exhausted. So it's giving us everything that went wrong from all the metrics it was able to call. It ruled out various other causes, and then it's giving us recommended actions to take.
Another key component here in a lot of other incident response management agents that we built is actually giving the agent the ability to go ahead and fix everything that it's been able to find. By giving the agent access to something like Claude Code, for instance, you can imagine this agent can then go into your code base, suggest fixes, put up a PR, and essentially do everything that it needs to do to help you go from initial incident all the way to fixing the root cause. For demo purposes, we're stopping at just the agent giving us the recommended actions, but I want you all to imagine the possibilities if we give our agent more tools, more ability to take actions, access to your code base, ability to put up PRs, so that you as a human developer can just become the oversight and watch over the agents as they take action.
Another key component of what we've built here on Claude Managed Agents is session persistence. So when I hit hard refresh on the screen, we're seeing that the agent is listing the sessions and everything is retained from all the sessions that we just ran. Everything is retained in the cloud, and we didn't have to deal with things like database and deployment of our agent and moving it from our laptops to production. Everything is already maintained server-side. We can also see the ability to delete sessions. Another thing to take note of is the states of the session. Here we can see that the sessions are now idle — just now as they were running, they were in a running state. We have the sessions managed by state here as part of that same durability and maintenance and reliability of the session. So when I come in and ask the agent something else like "Who are you?", I was able to easily resume the session and execute within that same session window. So state management here is really important to how managed agents works under the hood.
Now if we take a quick step back and look through everything we were able to accomplish: we started with an empty agent built on a couple of primitives. We then defined the agent definition, the persona, the capabilities. We gave the agent an environment. We gave the agent data and context to operate over. We then gave the agent sessions combining the agent definitions to an environment so the agent can think through which tools to call from an agent-loop perspective. And then it can actually call those tools and take action on our behalf. We then streamed the responses to the user into our logs, implemented some local tools as well as the ability to delete sessions. And within this Streamlit app, we saw how that actually affected from a front-end perspective how our agent was presented to our users by adding all of these primitives together.
Let's talk through some of the lessons of what we learned about how Claude Managed Agents works under the hood. The first thing we saw is that sessions speak in events and not responses in and tokens out from a request/response perspective like we see typically with things like Messages API. With Claude Managed Agents, instead of just having a request/response, we have events appended to the logs. This is a huge portion of why Claude Managed Agents is so reliable and secure, because events are coming through and just added into existing session logs, so that it's easy to resume a session and kick back off where you left off. This is also really important from a reliability perspective when we separate the hands from the brain of the agent. If a container goes down, we can just spin that container back up again, and we don't have to restart the entire agent loop alongside that container.
The next thing is that we saw the ability to implement local tools, defined in JSON and loading them in via our local files. We were then able to see how, with our Claude Managed Agents harness, the execution of the agent is completely separate from the agent loop. We defined everything that executed locally on our laptops and our scripts, and our agent loop ran on the cloud inside of Anthropic's managed infrastructure. Especially with what we just released with bring your own compute and bring your own sandboxing, you can swap out where you want that agent to execute its tools — in your own infrastructure or on Anthropic-managed infrastructure. Moving from things like loading our tools in from JSON into anywhere you want, like a DataDog client using the same wire protocol, makes it very easy to go from initially building the agent to producing and deploying it on production-ready infrastructure.
As we think about how sessions are controlled in Claude Managed Agents, you can think about the state as being something very powerful when you can start to take action on behalf of events. We saw a couple of key states for sessions in CMA (Claude Managed Agents): we went from idle to running, rescheduling if the agent needs to retry anything, or terminated if any of the sessions fail. The agent is able to restart from a reliability and resumability perspective, but it can also do some very powerful things. For instance, you can have a webhook run, and when an event happens from a webhook, the agent receives that webhook and can then do something like resume a session or kickstart a specific state based on external events. So this powerful form of having events and sessions be the core concepts means that you can make it very easy to compose your agent however you want it to, and have the agent listen for things that happen both internally and externally via webhooks. And everything lives in the cloud from the agent loop's perspective. The conversation is persisted.
Lastly, we just built the very basic form of Claude managed agents. Already there we were able to have something that would usually take us a lot of time to spin up from a production perspective. All of compaction, caching, tool calling, all of that was handled for us via Claude managed agents. And even if we wanted to go beyond that to make our agent much more powerful, we can do things like add in skills, add in sub-agents, add in memory, add in outcomes. Sub-agents or multi-agents is a way for you to have an orchestrator agent spin up context with other agents so that you can manage it from a context-engineering perspective, where sub-agents can handle tasks and have their own context windows and contribute back to the main agent. Memory is something always very important. I hear a lot of questions about how you can build self-improving agents or agents that learn from user corrections, agents that start to remember user preferences. That's where we're offering memory and a dreaming service for Claude managed agents out of the box. What dreaming means for managed agents is that Claude can actually come in and look through its own memory logs and determine what to keep and how it can start to memorize and manage context for its own memory.
Outcomes is another one of my favorites — for Claude managed agents, this means that you can actually define a rubric for your agent outcomes. So you can start to think of your agent's tasks as something where you want the agent to reach a desired outcome instead of just executing calls. With outcomes, you can define a rubric of exactly what you want the agent to produce, and it'll figure out along the way which tool calls and what it needs to do to execute towards that final result. Vaults is something I hear come up a lot, because managing user credentials is something that's very painful from an access management perspective. For vaults in Claude Managed Agents, there's actually an encryption that happens between where the credentials are stored on a separate endpoint and what the agent is able to access. So you can manage these credentials on a per-user, per-session basis, all very safely and securely. This relies in large part on that architecture of how the brains and the hands of the agent are separated. This means that you don't have to set up your own secret stores or credential stores. There are also things like the ability to do webhooks, detailed and fine-grained permission policies, the MCP servers where we just released new MCP server controls, and the console agent builder where we've built a lot of capability into the default developer console, with a beautiful observability dashboard.
So just as a quick recap to end us off here, hopefully everyone leaves here with a bit of a mental model about how managed agents actually works under the hood and be proud of yourselves for everyone that was able to come in and build on your laptops and actually ship a site reliability agent. So that is where I'll end today, but thank you all so much for coming.
TL;DR
- Isabella He from Anthropic's Applied AI team walks through Claude Managed Agents, the first harness that handles scaling, sandboxing, observability, and tool runtime for production-ready agents, so developers focus only on tasks, tools, and agent configuration.
- In a hands-on workshop, attendees build a site reliability (SRE) incident-response agent step by step from four primitives: agent definition, environment, session, and local tools — running the agent loop server-side with full persistence.
- The session explains key design decisions like decoupling the agent's "brains" from its "hands" (cutting P95 time-to-first-token by over 90%), event-based sessions, state management, and previews advanced features: sub-agents, memory, dreaming, outcomes, and vaults.
Takeaways
- Claude Managed Agents is the latest step after the Messages API (2023, raw model access where developers built every primitive themselves) and the Agent SDK (programmatic Claude Code, but developers still managed hosting and scaling). Managed Agents handles scaling and production components with a purpose-built harness, sandboxing, observability, tool runtime, and managed infrastructure.
- Teams have shipped to production 10–15 times faster with Managed Agents because harnesses should evolve alongside agents — for example, Sonnet 4.5's "context anxiety" (stopping tasks early) required harness mitigations that became obsolete once Opus 4.5 removed the behavior.
- Three primary resources build an agent: the agent endpoint (the persona/capabilities — model, system prompt, MCP servers, skills — the "brain"), the environment (the container where actions happen — the "hands"), and sessions (which bind an agent instance to an environment and stream events).
- A key design decision decouples the agent loop from tool execution (separating "hands" from "brains"), improving credential security via sandboxing and cutting P95 time-to-first-token by over 90%, since containers no longer spin up per session for the loop.
- The workshop builds an SRE agent: defining an agent with Claude Opus 4.7 plus a simple system prompt and tools (get metrics, recent deploys, get diff, fetch logs), attaching logs via the files API, binding everything in a session, streaming events to the UI, implementing local tools, and supporting session deletion for security.
- Sessions speak in events (user messages, tool calls, agent responses) rather than request/response tokens, which makes them logged for observability, resumable, and reliable — if a container goes down it can be restarted without restarting the whole agent loop.
- Everything persists in the cloud: hard-refreshing the page retains all sessions and conversation state without managing a database, and session states (idle, running, rescheduling, terminated) enable resumability and webhook-triggered actions.
- Beyond the basics, Managed Agents offers sub-agents (orchestrator spinning up parallel context windows), memory with a dreaming service for self-improving agents, outcomes (defining a rubric the agent works toward), vaults (encrypted per-user/per-session credential storage), webhooks, fine-grained permissions, MCP tunnels, and a console agent builder with observability dashboards.
Vocabulary
Claude Managed Agents — Anthropic's first harness that handles scaling, sandboxing, observability, and tool runtime so developers focus on agent configuration and custom logic.
Harness — The infrastructure layer around a model that manages primitives like context management, the agent loop, compaction, and caching.
Agent endpoint — The agent's persona and capabilities (model, system prompt, MCP servers, skills) — the "brain" of the agent.
Environment — The container where an agent takes actions — the "hands" of the agent.
Session — A binding of an agent instance to an environment that streams events and enables resumability.
Time to first token (TTFT) — A latency metric; decoupling the agent loop from tool execution cut P95 TTFT by over 90%.
Context anxiety — A Sonnet 4.5 behavior of wrapping up tasks early even with context to spare, later removed in Opus 4.5.
Dreaming — A service for Managed Agents that lets Claude review its own memory logs to decide what to keep, enabling self-improving agents.
Outcomes — A feature letting you define a rubric the agent works toward rather than just executing tool calls.
Vaults — Encrypted, per-user/per-session credential storage built into Managed Agents.
Transcript
Hello everyone. It's great to see you all here today for our session on shipping your first managed agent. My name is Isabella He. I'm a member of technical staff at Anthropic on the Applied AI team. The Applied AI team at Anthropic sits at the intersection of products, research, and our customers, which means that I get to contribute internally to products at Anthropic like Claude Code and our Claude harnesses, as well as work externally with our customers that are building on top of Claude and on top of our harnesses. So my goal today is to get you all hands-on with actually building on top of managed agents, understanding how the harness works under the hood, and getting you ready to actually ship your first incident response agent.
The quick overview of today's agenda: we're going to cover first a quick refresher of Claude managed agents. I want to talk you through a little bit about how this harness works under the hood and what makes it so special. Our team put a lot of thought into the architectural design of Claude managed agents to make sure that it runs ready and reliably for production-ready agents. Then we transition to the second portion, which is the hands-on workshop, where you'll actually understand what each of the primitives you're building actually means for your agents under the hood. For the majority of today's session, I want you all to actually have your laptops open, building alongside me, actually working inside of a repository, and getting you ready to spin up a working incident response agent. Lastly, we'll talk a little bit about "beyond the basics." Today's session is the first of a couple of others that will build on top of this on Claude managed agents. Specifically, right after this one, there's another session on dreaming, which is one of my favorite new features with Claude managed agents for self-improving agents and memory built into the harness.
So let's first touch on how we got here with Claude managed agents. When we first released the very first Claude back in 2023, we released a Messages API alongside access to Claude. This provided raw model access to all Claude models. This became the very first way that people could programmatically build on top of Claude and essentially gave a way for people to access tokens in and tokens out via our Claude models. This also meant that for everyone building on top of Claude models, they had to implement all the various primitives themselves — things like context management, the actual agent loop, compaction, etc. All the primitives that come alongside making the agent work. When models were less intelligent back in the early days of, let's say, 2023, some of these primitives were much simpler because agents could simply do less. But as we evolved into now with higher model intelligence, and as agents are able to take on more complex tasks and actually take actions within environments and come to do entire tasks for humans, the primitives that come alongside context management and managing an agent's ability to execute API calls and tool calls become much more complex.
So that's when we moved to the Agent SDK, which became a harness that allows you to programmatically call Claude Code, one of our agents at Anthropic. So Claude Code is something where an agent has access to a computer and takes actions within a file system. The Agent SDK became a way for you to make Claude much more powerful by leveraging the power of Claude Code within a harness. The main thing here, though, is that with the Agent SDK, developers still had to manage hosting and scaling on their own and making sure that the Agent SDK would be safe to run within their containers. That's only then evolved into Claude managed agents, which is the first harness to be able to handle scaling and production-ready components for you by Anthropic, providing things like a purpose-built harness, sandboxing, observability, tool runtime, all within a managed infrastructure system. This means that developers can focus on task and agent configuration, custom tool logic, the things that actually matter for bringing domain expertise and customizability to your agents, where you're handing off the rest of all the primitives and core compute of essentially managing the basics of agent running to Anthropic.
So that brings me to managed agents as the fastest way to build production-ready agents on Claude. We've seen people build 10 to 15 times faster to production with Claude managed agents by leveraging our purpose-built harness. Part of the reason why we built Claude managed agents is because harnesses should evolve alongside your agents. For example, back when we were building ourselves on top of models like Sonnet 4.5, we noticed that Sonnet 4.5 emitted a particular behavior called context anxiety. This meant that with Sonnet 4.5, Claude started wrapping up tasks early even when it still had room to spare in its context window. To manage that in our harness, we then added some mitigations to combat against this early stopping behavior. But when Opus 4.5 then came out, we actually saw this behavior go away, making all that work we had done inside the harness essentially obsolete because Claude had evolved beyond that behavior. So the takeaway there is that it's a lot of work to maintain harnesses and make sure that they actually evolve alongside your agents, which is why with Claude managed agents, we want to make it really easy for Claude and Anthropic to handle all the complexities that come with compaction, caching, things like context anxiety, all these various primitives that come with actually making agents production-ready and getting the most out of Claude.
So three primary resources go into building on Claude managed agents. First is the agent's endpoint, which is the persona and capabilities. This is the core system prompt that powers your agent. Essentially here, you're defining the model, the MCP servers, the skills, the various components that your agent can actually leverage when it's able to run in that agent loop. The next is the environments. You can think of this as the hands of the agent, where the previous one is the brain of the agent where the agent is thinking through what to execute, and then it's using an environment to actually have a space and a container to take action on your behalf. Sessions are next — the way to tie together agents and environments. A single session has a spun-up agent instance within an environment. So you can connect the two together and actually stream events back to your user and start to take action on behalf of your humans as part of a Claude-powered agent. A key thing here is that Claude managed agents has the agent loop run server-side. This means that a lot of the complexities that come with managing hosting and scaling are abstracted away. And when you close your laptop or you hit hard refresh on your agent, everything is maintained and you don't have to worry about durability, reliability, all these various aspects that usually come to bite you when you're trying to turn your agent from a prototype into production.
And lastly here, before we dive into the hands-on portion, I want to talk you through a key design decision that went into Claude managed agents. Previously, with a lot of agent harnesses, we saw the agent loop coupled tightly with tool execution. This design pattern made sense and still makes sense for some agents because you want to give the agent powerful abilities to take action within the environment. For instance, with Claude Code, we want the agent to be able to access various files on your computer, take action within a file system, and therefore it makes sense for the agent to have access to all those tools spun up on every container. But we also realized there are some constraints for this, especially with some agents where you essentially want to be able to decouple the hands from the brains of the agents. For instance, credentials and security became a huge concern. With the ability to have the agent access your file system, you can actually add very distinct sandboxing by decoupling these two components, where the agent is no longer able to access the actual credentials without encryption. The other aspect is you can see huge benefits by doing this decoupling on things like time to first token and latency. Previously, with the agent loop and execution in the same box, you had to spin up containers for every single session, which contributed to additional latency from a time-to-first-token perspective. But with this now decoupled, our teams actually saw reductions in time to first token along the lines of over 90% reduction in TTFT for our P95 metrics on latency. So here you can start to see the power of this design decision coming through from the perspective of safety, reliability, latency, and everything else that you care about when it comes to building production-ready agents.
All right, so now it's time for the exciting part, which is where I want you all to open up your laptops and go to this URL to actually clone a repository, and let's start to feel the magic of everything that I just talked through. Here are some additional commands that I want you all to run to make sure this is all set up on your computers. Take that repository, hit the URL, git clone it, and then CD into the specific repository for the session, which is "ship your first managed agent." If you're on Mac, you'll see those two commands on the side, the Python and the source (there's a command for Windows as well). You'll install the requirements, copy over the environment key into your .env file — here you'll put in the Anthropic API key that hopefully all of you also received from the QR code for free credits earlier. And lastly, we'll just run the app. If you go into the repository in the link and then go to "ship your first managed agents," scroll down on the readme, you'll see all the setup instructions here.
So once you run streamlit run app.py, you should be able to see a URL that looks like this and a page that looks like this. What we're doing here is we're going to be simulating an agent interaction where we have an incident that's going to come up. A lot of you who might be software engineers in the room will be intimately familiar with the pain that comes alongside incident response. If you are a software engineer, you might be woken up at, let's say, 3 a.m. in the morning when you're on call, and this is usually a very painful portion of a software engineer's life, because when you're on call, it means that if a server goes down or a service goes down, you have to be immediately the one there to respond and tackle the incident. Usually for a human, this means diving into metrics and logs and deployments. And so what we're going to do is we're going to now have an agent run on Claude managed agents to do all this for us. So that when we get woken up by 3 a.m., we can hand it off to an agent, or maybe we don't even get woken up at all if Claude is able to do everything for us.
Let's now dive into the code here. What we're going to open up is we have the agent.py file on the left and the agent complete on the right. If you want to challenge yourself, you can of course try to implement everything yourself with Claude. But what we're going to do, just for simplicity's sake, is just copy over various elements from the completed file onto the incomplete file one by one. So you can see how these primitives compose our agent one piece at a time. Let's start off with this very first part, which is the agent. We mentioned before that the agent is the one that defines the persona and the capabilities — that's model, the system prompts, and the tools in our case. We're defining the SRE agent. We're going to use Claude Opus 4.7 here. And I've preconfigured a system prompt and tools for the agent. For the system prompt, you can see that it's actually extremely simple for the agent that we're defining today. We're just telling it that it's an SRE agent. It's responsible for coming in and debugging incidents, and it has access to various tools like metrics, recent deployments, get diff. These are tools that you would want as a developer if you're actually managing an incident response as well, like the ability to fetch logs so you can see exactly what's going wrong. So that's step one. Now let's move on to step two, which is the environment where the agent is going to actually do work in.
All of you here were very lucky for those of you who were able to come yesterday as well to Code with Claude London. We actually just released yesterday the ability to bring your own containers and your own compute to Claude Managed Agents, which means that you can actually execute the agent's tools and the actual ability for the agent's actions to work within your own infrastructure and not just Anthropic's managed infrastructure. We're defining our SRE agent to work within the Anthropic cloud, and here we're just giving it unrestricted access from a networking perspective. We've made Claude Managed Agents very composable and very customizable. So this networking list here is actually an allowed list. If you want your agent to only be able to access specific sites and URLs, you can restrict this down as much as you would like. We also released Claude MCP tunnels, which gives you the ability to run MCP servers within a private environment instead of on the public network. So here we have a unique identifier for an agent and an environment.
The next thing that we have to do is actually give our agent the ability to look at logs. With Claude Code, that is one of the first times where we realized the power of giving the agent access to files and a file system. Here with Claude Managed Agents, we're leveraging essentially the files API by uploading the metrics and logs to the agent, so the agent can start to run code and process through those files. The key takeaway is: as much data as you're able to give the agent is what makes it so powerful. Context engineering is a huge portion that comes to actually making an agent powerful. This is where we see the developers spending the majority of their time working on top of primitives like Claude Managed Agents — managing context and managing what types of files are uploaded, how the agent processes those files.
Now let's define the session. The session is going to bind the agent and the environment and also mount the log. So you can see we're passing in the agent ID, the environment ID, and the resources that we're giving to the agent. What we want to do is now also give the ability for the agent to come in and stream responses to me as we go along. The key portion here is that when our Claude Managed Agents runs within a single session, instead of responding in tokens in and tokens out, it actually works in units of events. Events here are things like user messages or agent tool calls, agent responses, so that every event can be logged from an observability perspective, as well as streamed back to the user for the user to see the agent responding as it calls tools and as it starts to populate responses. This is crucial for both a user experience perspective and from an observability perspective, and Claude Managed Agents actually has a very neat console built in for looking at everything the agent is doing.
If I send something like "hi" to the agent, it can respond, but it doesn't actually have the ability to call the various tools that we want it to yet, because we haven't connected that locally. The agent is ready and defined on the server side already. The missing piece here is just to finally give it our local tools so the agent can start to take action on my computer or my infrastructure. Now the agent is going to be able to start to call get metrics, get recent deploys, get diffs, so it can truly start to take action in terms of helping us debug this incident. The last thing I'm going to do here is also make sure I give my agent the ability to delete sessions. This is crucial from a security perspective — if you want to make sure that nothing is being retained for sessions that you don't want on the cloud or on your infrastructure, you can actually just come in and proactively manage how sessions are deleted. And once they're deleted, they will be also removed from every single log aspect, so that you can truly make sure that whatever data you want managed is managed actively and proactively.
So with that all set up, let's give our agent a test run. I'm going to click the new session here, and ask the agent to debug my incident for me. You can see here that because we gave the agent access to tools like sandboxing and bash, and get recent deploys, the agent is starting to take powerful actions on my behalf. It's run the sandbox command. We can see that it's actually coming in and looking at what the logs were added to. It's then called this tool called get recent deploys, which is returning results like what the recent deployments look like, the metrics. And again, we can start to see the magic of that streaming come through, because we saw these tools come in as they were being called from the agent. We saw the user prompt come in as soon as I prompted it, and the agent is actually streaming responses to me as it comes through with more token response and outputs.
We can see here that the incident is that there's something going wrong with our P99 latency that seems to be 10 times above the baseline. The agent is coming in and debugging everything for us. Some of the major design decisions that come in here when you're designing a real site reliability / incident response agent for your systems is to think deeply about the various components, MCP servers, and skills that you want to give your agent. Here we've defined a very simple agent, but for lots of the SRE agents that we build, we actually also think about things like how can we give the agent a skill to execute and run runbooks. Runbooks are things where, as teams debug incidents, they note down and document how they debug that incident so that they can do it again for a future session or incident. You want to give the agent the same access to the materials that you would have as a human developer.
Let me start a new session here. Let's say "debug my incident for me." Is anyone able to get it working on their laptops better than I have on the screen? Okay, we got some success in the room. Looks like we are streaming. The agent is checking logs, debugging everything. The data that's being passed in for our agent here is all local just for our purposes for our demo workshop today. But with the ability for you to run your agents within a container and infrastructure, you can start to see how things like your get metrics tool that are currently pulling from JSON can be easily moved to something like DataDog or other production systems. Oh, there we go. Success. So the agent has come in. If we scroll through all the tool calls, everything is persisted in the cloud from a logs perspective. All of this will also be logged in the observability console. And then the agent has come back to us with the incident response. It says that this seems to be caused by a database pool exhaustion. Seems like a commit that someone added from Alice to refactor the order summary builder introduced a query that then caused the pool resources to be exhausted. So it's giving us everything that went wrong from all the metrics it was able to call. It ruled out various other causes, and then it's giving us recommended actions to take.
Another key component here in a lot of other incident response management agents that we built is actually giving the agent the ability to go ahead and fix everything that it's been able to find. By giving the agent access to something like Claude Code, for instance, you can imagine this agent can then go into your code base, suggest fixes, put up a PR, and essentially do everything that it needs to do to help you go from initial incident all the way to fixing the root cause. For demo purposes, we're stopping at just the agent giving us the recommended actions, but I want you all to imagine the possibilities if we give our agent more tools, more ability to take actions, access to your code base, ability to put up PRs, so that you as a human developer can just become the oversight and watch over the agents as they take action.
Another key component of what we've built here on Claude Managed Agents is session persistence. So when I hit hard refresh on the screen, we're seeing that the agent is listing the sessions and everything is retained from all the sessions that we just ran. Everything is retained in the cloud, and we didn't have to deal with things like database and deployment of our agent and moving it from our laptops to production. Everything is already maintained server-side. We can also see the ability to delete sessions. Another thing to take note of is the states of the session. Here we can see that the sessions are now idle — just now as they were running, they were in a running state. We have the sessions managed by state here as part of that same durability and maintenance and reliability of the session. So when I come in and ask the agent something else like "Who are you?", I was able to easily resume the session and execute within that same session window. So state management here is really important to how managed agents works under the hood.
Now if we take a quick step back and look through everything we were able to accomplish: we started with an empty agent built on a couple of primitives. We then defined the agent definition, the persona, the capabilities. We gave the agent an environment. We gave the agent data and context to operate over. We then gave the agent sessions combining the agent definitions to an environment so the agent can think through which tools to call from an agent-loop perspective. And then it can actually call those tools and take action on our behalf. We then streamed the responses to the user into our logs, implemented some local tools as well as the ability to delete sessions. And within this Streamlit app, we saw how that actually affected from a front-end perspective how our agent was presented to our users by adding all of these primitives together.
Let's talk through some of the lessons of what we learned about how Claude Managed Agents works under the hood. The first thing we saw is that sessions speak in events and not responses in and tokens out from a request/response perspective like we see typically with things like Messages API. With Claude Managed Agents, instead of just having a request/response, we have events appended to the logs. This is a huge portion of why Claude Managed Agents is so reliable and secure, because events are coming through and just added into existing session logs, so that it's easy to resume a session and kick back off where you left off. This is also really important from a reliability perspective when we separate the hands from the brain of the agent. If a container goes down, we can just spin that container back up again, and we don't have to restart the entire agent loop alongside that container.
The next thing is that we saw the ability to implement local tools, defined in JSON and loading them in via our local files. We were then able to see how, with our Claude Managed Agents harness, the execution of the agent is completely separate from the agent loop. We defined everything that executed locally on our laptops and our scripts, and our agent loop ran on the cloud inside of Anthropic's managed infrastructure. Especially with what we just released with bring your own compute and bring your own sandboxing, you can swap out where you want that agent to execute its tools — in your own infrastructure or on Anthropic-managed infrastructure. Moving from things like loading our tools in from JSON into anywhere you want, like a DataDog client using the same wire protocol, makes it very easy to go from initially building the agent to producing and deploying it on production-ready infrastructure.
As we think about how sessions are controlled in Claude Managed Agents, you can think about the state as being something very powerful when you can start to take action on behalf of events. We saw a couple of key states for sessions in CMA (Claude Managed Agents): we went from idle to running, rescheduling if the agent needs to retry anything, or terminated if any of the sessions fail. The agent is able to restart from a reliability and resumability perspective, but it can also do some very powerful things. For instance, you can have a webhook run, and when an event happens from a webhook, the agent receives that webhook and can then do something like resume a session or kickstart a specific state based on external events. So this powerful form of having events and sessions be the core concepts means that you can make it very easy to compose your agent however you want it to, and have the agent listen for things that happen both internally and externally via webhooks. And everything lives in the cloud from the agent loop's perspective. The conversation is persisted.
Lastly, we just built the very basic form of Claude managed agents. Already there we were able to have something that would usually take us a lot of time to spin up from a production perspective. All of compaction, caching, tool calling, all of that was handled for us via Claude managed agents. And even if we wanted to go beyond that to make our agent much more powerful, we can do things like add in skills, add in sub-agents, add in memory, add in outcomes. Sub-agents or multi-agents is a way for you to have an orchestrator agent spin up context with other agents so that you can manage it from a context-engineering perspective, where sub-agents can handle tasks and have their own context windows and contribute back to the main agent. Memory is something always very important. I hear a lot of questions about how you can build self-improving agents or agents that learn from user corrections, agents that start to remember user preferences. That's where we're offering memory and a dreaming service for Claude managed agents out of the box. What dreaming means for managed agents is that Claude can actually come in and look through its own memory logs and determine what to keep and how it can start to memorize and manage context for its own memory.
Outcomes is another one of my favorites — for Claude managed agents, this means that you can actually define a rubric for your agent outcomes. So you can start to think of your agent's tasks as something where you want the agent to reach a desired outcome instead of just executing calls. With outcomes, you can define a rubric of exactly what you want the agent to produce, and it'll figure out along the way which tool calls and what it needs to do to execute towards that final result. Vaults is something I hear come up a lot, because managing user credentials is something that's very painful from an access management perspective. For vaults in Claude Managed Agents, there's actually an encryption that happens between where the credentials are stored on a separate endpoint and what the agent is able to access. So you can manage these credentials on a per-user, per-session basis, all very safely and securely. This relies in large part on that architecture of how the brains and the hands of the agent are separated. This means that you don't have to set up your own secret stores or credential stores. There are also things like the ability to do webhooks, detailed and fine-grained permission policies, the MCP servers where we just released new MCP server controls, and the console agent builder where we've built a lot of capability into the default developer console, with a beautiful observability dashboard.
So just as a quick recap to end us off here, hopefully everyone leaves here with a bit of a mental model about how managed agents actually works under the hood and be proud of yourselves for everyone that was able to come in and build on your laptops and actually ship a site reliability agent. So that is where I'll end today, but thank you all so much for coming.