Decoupling the Brain from the Hands: Claude Managed Agents (Part 1 of 4) — Anthropic
https://www.youtube.com/watch?v=Uv0nAf_7tyU
AI Engineer · 17 min · 195 sentences · sentence-level transcript from YouTube's caption track; each line begins at the time shown

[00:12] Thank you very much to everyone who joined.
[00:15] I think we'll start, since we have a full hall.
[00:19] Hello everyone.
[00:20] My name is Priyanka.
[00:22] I am a technical employee at Anthropic.
[00:25] I lead the engineering team that built Claude Managed Agents, and I'm excited to be here to chat with you and help you launch your first Managed Agent.
[00:34] I've been at Anthropic for a little over two years, and for the last 12 months I've been focused on building out the agent infrastructure, and I hope to share our learnings with you.
[00:44] Congratulations.
[00:44] My name is Gabe Semack.
[00:46] I am a technical fellow building Claude managed agents on Priyanka's team.
[00:51] I've been at Anthropic for a little over a year and have been working on this project almost all that time.
[00:58] OK.
[00:58] So, here is our agenda.
[01:02] We'll start with a history of how we built and scaled managed agents, as well as some of the pitfalls and lessons we learned along the way.
[01:12] Then we will move on to the practical part of the seminar.
[01:16] In the first part, we will create a very simple agent using the Claude platform console.
[01:22] You will not write any code during this part.
[01:25] We'll just try to create our first agent using the prompts and test it.
[01:29] Then I'll hand it over to Gabe to walk you through the practical part.
[01:33] We'll be writing code using Claude Coder, your favorite agent for programming, and then building a more complex financial agent, after which we'll have plenty of time at the end for questions and answers.
[01:42] We have a two-hour slot.
[01:44] I know it's divided into four parts, but it's essentially one long presentation.
[01:49] I hope it doesn't take all two hours.
[01:51] We want it to be quite interactive.
[01:53] So if you have any questions, raise your hand.
[01:56] We have a few people nearby who can come up to you and give you a microphone for a question, especially when we get to the practical part.
[02:04] Okay, let's get started.
[02:06] So, I'll start with the basics.
[02:08] Let's start with what is an agent or what makes an agent work?
[02:13] An agent is essentially a model in a loop with tools.
[02:19] You will see on the left a model that makes a decision, performs the next action, and calls tools in a loop until your task is completed.
[02:26] This is essentially the simplest definition of what an agent is.
[02:33] Yes.
[02:44] Link to the presentation?
[02:46] We can try...
[02:48] We can share it when it's finished.
[02:50] Yes, we will share it when it is finished.
[02:53] It will be difficult for us to provide this now, but we will be happy to answer questions and share the presentation at the end.
[02:59] Do you have difficulty seeing slides from the back rows?
[03:02] Good.
[03:03] Sorry about that.
[03:04] Um, okay.
[03:05] The next thing I wanted to talk about is what a “harness” is .
[03:09] Harness is usually a layer that wraps around the model and helps execute tool calls in a loop to achieve the result of your current task.
[03:18] It makes assumptions about what the model cannot do and tries to fill in those gaps.
[03:24] So, it works in a loop, making tool calls, managing context, and encapsulating anything the model can't do on its own.
[03:31] A good example is our Sonnet 3.5 model, which had what we called “ contextual alerting .”
[03:38] So whenever Sonnet 3.5 sensed that you were approaching the context limit, it tried to complete the task very quickly.
[03:45] So when creating a wrapper around Sonnet 3.5, you added something like context reset to get around this limitation.
[03:53] But with the next model, like Opus 3.5, there was no such limitation, and you didn't need to do such a context reset for it.
[04:02] So when you build a wrapper, you want to encapsulate all these assumptions for different models and keep up with each new model, so building a good wrapper is very important, and that's what we tried to do with Cloud Managed Agents.
[04:16] And lastly : you want your agent to have access to a sandbox or computer.
[04:22] Essentially, this is where he will run the code he writes to perform the task.
[04:26] Typically, you provide access to a cloud sandbox or container where it executes the written code.
[04:32] It can edit files, install dependencies, etc. Cloud Code is a great example of this.
[04:37] This is a wrapper running locally on your computer, accessing your files and executing them, updating them in the process.
[04:45] He also writes code that is unreliable.
[04:48] It can be buggy, so when deploying product agents you want to make sure the code they write is sandboxed and confined to the container.
[04:58] You also need to keep your sandbox isolated and your attack radius limited.
[05:03] Therefore, you typically want to run each task in a separate container to avoid mixing data and increasing the impact radius for your tasks.
[05:13] Next, I'll tell you about the first architecture on which we actually built managed agents.
[05:19] It was last December when we delivered the first architecture to our early access customers, got a ton of feedback, and then moved on to the new architecture.
[05:28] So I'll tell you about some of the pitfalls and problems we faced in the first version.
[05:35] In the first architecture, we placed everything in a container.
[05:39] So, we had a session log with everything that happened during that session.
[05:43] This session is essentially your unit of work.
[05:47] The harness also worked inside the container , and the sandbox execution also happened inside the container .
[05:54] The advantage was that since everything was in a container, there was no need to design service boundaries.
[05:59] Everything was local, easy to edit, and editing files felt like system calls.
[06:05] But it so happened that we realized: we had a " pet."
[06:11] If you haven't heard the analogy of "pets " and "livestock" from the old infrastructure days, a " pet" is when you have a named entity that you manually care for.
[06:22] When he is sick, you must nurse him back to life.
[06:26] You simply cannot afford to lose it.
[06:28] And "livestock" is something more interchangeable, disposable.
[06:31] When one unit fails, you replace it with another and keep going .
[06:35] A good example: imagine you have a single database layer.
[06:38] If it falls, your product doesn't work—it's your "favorite."
[06:41] But imagine that you have master- replica replication set up.
[06:43] The master falls and you can pick up the replica.
[06:45] That's what "cattle" is, right?
[06:47] You have many instances, one fails—it's not a problem, you can restore it.
[06:51] So, our initial setup was essentially a " pet" setup.
[06:56] There were several problems with this.
[06:58] Debugging was very difficult because everything was running in a container.
[07:01] We didn't know what exactly was causing the problem.
[07:04] A lost packet or a stopped container looked almost the same, and we had to connect via WebSocket to the container for debugging.
[07:13] Another problem was that the investigation was difficult because these containers stored customer data.
[07:20] So we essentially had no way to get inside for debugging.
[07:24] This was another issue we discovered during Early Access.
[07:28] And lastly, if a customer wanted us to connect to, say, an MCP in their VPC, that meant peering the networks or sending them our harness to run on their own.
[07:38] So, there were a lot of problems with that architecture that we couldn't find a really good solution for.
[07:45] So we decided that we wanted to essentially separate the "brain" from the "hands," and I'll explain what that means.
[07:53] The agent essentially turned into three separate interfaces.
[07:57] On the left you have the session—this is essentially a log just for adding everything that has happened in the session up to that point.
[08:04] In the middle is the "brain", which is your framework or agent cycle along with Claude.
[08:09] And on the right—" hands."
[08:10] That is, sandboxes, your MCP tool challenges, etc. They are created on request, disappear when you're done , and if you lose the sandbox, you just start it again.
[08:22] So each component became interchangeable and " non-unique".
[08:26] When the sandbox "died" , the framework or Claude could just start it again, right?
[08:31] The error returned to Claude, and for him the sandbox was essentially the same tool as any other.
[08:36] If the tool call fails, the sandbox "crashes" and it decides what to do: run it again or move on.
[08:44] When the framework "crashed", you could start a new instance and continue where you left off, simply by reading the session event log.
[08:53] Work resumes from the last event as if nothing had happened.
[08:58] Nothing happened.
[08:58] The only thing we were protecting here was your session log.
[09:02] Everything else was interchangeable: it could fail and be easily repaired.
[09:07] Another thing we did was to ensure that account data never entered our sandbox.
[09:11] In our previous system, your data was sandboxed, so you were more vulnerable to prompt injections.
[09:20] We changed it this way: if the sandbox needed to access something that required a token or access control, the request went through a proxy that appended your token before calling the external
[09:31] endpoint or MCP.
[09:34] This way, the model never sees your credentials or tokens, so you can't force Claude through prompt injection to say, for example, " Give me your tokens ."
[09:42] Either display the tokens on the screen or write them to a file.
[09:45] You will never be able to do this because Claude never actually sees your tokens.
[09:51] Because we had an append-only event log, our data compaction strategy remained flexible.
[09:57] So, nothing is ever deleted.
[10:00] We do not compress or change your flow of events.
[10:03] We always store every event that happens, and the compression strategy decides, “Oh, do I want to go through the entire event log, summarize it, and add context?
[10:13] Do I want to review only the last n events and add them to the context?
[10:17] So, thanks to the interface design we chose, we could have a more flexible context strategy.
[10:24] And another benefit we noticed: because we could start the logical inference calls immediately, we were able to reduce the time to the first token by about 90%.
[10:33] So Claude only started the sandbox when needed, and didn't wait for the container or sandbox to be deployed for you to get your first token.
[10:41] So thanks to this architectural change, we were able to get a much faster and more responsive system.
[10:47] And here is an illustration of how one "brain" can control many " hands."
[10:55] Your loopback agent system can now access a container in the sandbox, a customer's VPC, or an MCP server.
[11:03] So all these "arms" are essentially interchangeable, you can connect many of them, which made our architecture much more flexible.
[11:12] If you remember only one thing, let it be that systems contain assumptions, and assumptions can become outdated.
[11:21] So we designed interfaces that would survive these assumptions and made the architecture more flexible.
[11:28] This allowed us, as I said, to change the compression strategy, to completely replace the system, but the interface and architecture remain the same, and we can work with it in a more modular way.
[11:44] Okay, now we'll move on to the practical part.
[11:49] We've prepared free API credits for you to help you build with us today, so please scan the QR code, log in to your Cloud Platform account or create a new one, and you can get those credits to build with me and then with Gabe.
[12:06] And I'll leave that for a moment.
[12:10] Greetings.
[12:12] Excuse me, what?
[12:15] Last slide.
[12:19] That's actually what we were talking about here , right?
[12:27] These are kind of the three interfaces that we designed the system for, right?
[12:33] The first question was what interfaces did we develop to keep the system relevant despite the changes?
[12:40] So we have a session log just for appending, there's a framework that can be replaced again, and tools where you can plug in a sandbox, tool calls, or anything that the model might need access to— this makes the system more versatile and extensible.
[12:57] Okay, back to the credits.
[13:01] Does anyone else need to scan this before we start?
[13:05] Okay, I still see a few phones.
[13:07] Okay, I'll give everyone about 30 seconds.
[13:10] Thank you for your patience.
[13:12] Oh, are there any problems with the internet?
[13:18] Oh no. Gabe, do we have a microphone?
[13:27] Because I can't hear some questions.
[13:37] Yes, the credits should arrive as soon as you sign up, hopefully within a minute or two.
[13:42] We are now taking the microphone so that we can walk around the hall and answer these questions.
[13:48] But I'll show you how to create a very simple agent that tells jokes.
[13:57] I'll first talk about our core APIs and concepts, and then we'll go to platform.anthropic.com to create your first agent.
[14:06] Our first step is to create an API for environments (V1 environments), which helps create an environment or template for your sandbox.
[14:15] Here you will find your network settings.
[14:18] Do you want unlimited network access or do you want to limit it to specific domains or MCPs?
[14:24] You can specify which packages should be installed in your container or " sandbox".
[14:29] So, this will be our first step in setting up the environment.
[14:34] Next, you create an agent.
[14:37] An agent is essentially an object that can be given a name.
[14:41] In this case, we will call him a "joker."
[14:44] We will choose the model you want to use for this agent.
[14:48] You can use Opus, Haiku, or Sonnet—your choice.
[14:53] After that, we will provide the agent with a system prompt.
[14:57] In this case, we would say: "You're a comedian, find a fresh joke on a given topic and tell it well."
[15:03] Then you can give that agent tools.
[15:05] We will provide him with the agent toolkit, which is our basic set.
[15:10] It's like your bash toolkit: read, write, grep, etc. Almost all agents will need this.
[15:16] This will be your second step.
[15:19] The third step will finally be to create a session.
[15:22] So , the session takes the agent ID and the environment ID and creates the session.
[15:26] This is your task, i.e., a unit of work or your assignment.
[15:29] And when the session is initialized , it is in standby mode.
[15:33] No work has been done yet, right?
[15:35] Until you send the event.
[15:37] And this is what the flow of events in your session will look like .
[15:43] You will have events that you send, as well as events that the agent will respond to you with.
[15:47] On the left you will see user.message.
[15:49] You can say, "Tell me a joke about distributed systems ."
[15:52] And then the agent will answer you with a funny joke.
[15:55] You can use what is called a custom tool.
[15:57] A tool essentially allows you to define the tool you want to use to handle how you respond to it.
[16:03] And Claude will essentially add a custom tool usage event to your event stream, which you can track, process, and return the result to Claude as a custom tool result.
[16:14] And there are a few other examples of the types of events you might see.
[16:18] So, you will see session.
[16:20] error if your session ever throws or encounters an error.
[16:23] Idle status is when your session is idle and not working.
[16:26] This usually happens when you're not actually using the sandbox.
[16:29] And interrupt on the left is when you want to stop or interrupt the session and no longer want to continue working.
[16:36] This is kind of our complete list of features.
[16:39] Maybe if there's time at the end , Gabe can come back to it and dig deeper into the topic, but Gabe will work with you on his part of the workshop, looking more closely at
[16:47] concepts like multi-agency and memory, which we also provide.
[16:51] A. Okay.
[16:53] Before we get to that, we'll now go to platform.claude.com.
[16:59] I hope you can use your API credits and see them now.
[17:03] If not, Travis walks around with a microphone, so you can reach out to him if you have any questions or need help.
[17:10] And if you go to your console, in the agent management section you will see something called "quick start".
[17:17] This is kind of our guide on how to create your first agent.