Decoupling the Brain from the Hands: Claude Managed Agents (Part 1 of 4) — Anthropic

AI Engineer · 17 min · 195 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

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