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

0:01 [music] Thank you so much to everybody for for joining. Um I think we're going to get started given we have a have a full house. Um hi everyone. My name is

0:21 Priyanka. I'm a member of technical staff at Enthropic. Uh I lead the engineering team that built cloud manage agents and I'm really excited to be here to talk to all of you uh and help you

0:33 ship your first manage agent. I've been anthropic a little bit over two years and the last 12 months I've been focused on uh building um agentic infrastructure and hope to share some of our learnings

0:44 with you. >> Uh hello my name is Gabe Semach. I'm a member of the technical staff uh building cloud managed agents in Priyanka team. I've been at Anthropic a

0:52 little bit over a year and I've been mostly working on this my entire time. >> All right. Um, so here is our agenda. We will kick it off with h a little bit of an evolution story of how we built and

1:07 scaled managed agents, some of the pitfalls and the learnings that we had along the way. Then we'll switch to a hands-on part of the workshop. Uh the first part uh we will build uh a very

1:19 simple agent uh using cloud platforms console. You will not be writing any code during that part. We'll just kind of prompt our way to our first agent and test it out. Uh then I'll hand it over

1:30 to Gabe to walk you through like a hands-on portion. We'll be writing code using cloud code or your favorite coding agent. Um and then build a more complex financial agent and then we'll have

1:41 plenty of time at the end for Q&A. We we have a twohour slot. I know they broke it down into four parts, but it's basically one long presentation. Um, hopefully it doesn't take the full two

1:50 hours. U, we want this to be pretty interactive, so if you do have questions, raise your hands. We have a couple folks around that can run to you, hand you a mic uh with a question,

2:00 especially as we get into the hands-on uh portion. All right, let's let's get going. Um, so I'll start with the basics. So, we'll we'll start with what what is an agent

2:10 or what makes an agent work? Um so agent is basically uh a model in a loop with tools. So you'll see on the left you have the model that's deciding and taking the next action and calling tools

2:24 in a loop until your task is done. So that's like the very basic what what an agent is. >> Excuse me. >> Y

2:42 slide deck or slide. >> Oh, a link to a slide deck. Um, we can try to >> we we can we can share it after. >> Yeah, we we'll share it after. It'll be

2:53 hard for us to get it out right now. Um, but happy to answer questions uh and and share the slide deck at the end. Are you is it hard for you to see see the slides from the back? Okay, sorry about that.

3:04 Um, all right. Uh, the next thing I wanted to chat about is what a harness is. harness is typically like a layer that wraps around the model that helps you make these tool calls in a loop to

3:15 get you the outcome for the task that you're the task at hand and it's making assumptions about what the model cannot do and trying to sort of fill those gaps. So it's running in a loop making

3:26 tool calls managing your context encapsulating everything that the model cannot do. A good example is our set 45 model had something what we called uh context anxiety. So whenever sonnet 45

3:39 felt like you're getting to the end of the context limit, it would try to wrap up the task really quickly. So when you're building a harness around sonnet 45, you would add something like a

3:50 context reset to get around the limitation of the anxiety. But with the next model like opus 45, opus 45 did not have this limitation and you did not need to do this like context reset for

4:00 opus 45. So when you're building a harness, you want to encapsulate all these assumptions for different models and keep up with it with every new model that comes up, which is why building a

4:11 good harness is really really important. And that's something we've tried to do with cloud managed agents. And then the last bit uh you want your agent to have access to a sandbox or a computer

4:21 essentially uh a place where it's going to run the code it's writing to execute the task. Um, so typically you're giving cloud access to like a sandbox or container where it's executing the code

4:31 it's writing. It's able to edit files, install dependencies, etc. Cloud code is a really good example of this. It's running, it's a harness essentially running locally on your computer, has

4:41 access to your files, and it's executing, updating your files as it goes. Um, it's also writing uh code that's untrusted. It might be buggy. So you want to make sure when you're

4:51 deploying production agents uh your a the code your agents are writing is sandbox and contained within a container. Um and then you want your sandbox to be isolated and the blast

5:02 radius to be limited. So typically you want to execute every task in a separate container so you're not mixing up and you're not um uh increasing the blast radius for for your tasks.

5:13 Next up, I'll walk you through um the first architecture that we actually built managed agents with. This was in December of last year where we shipped our first architecture to our early

5:24 access customers, got a bunch of feedback, and then actually pivoted to a new architecture. So, I'm going to walk you through some of like the pitfall pitfalls and like issues that we saw

5:33 with the first one. So, with the first architecture, what we did was we put everything in the container. So we had the session log of everything that's happened within that session. So test

5:43 session is essentially your um unit of work. Um the harness was also running inside the container and then the sandbox execution was also happening inside the container. The benefit of

5:55 that was like because everything was in the container there was no service boundaries to design for. Everything was local um easy to edit. File edits were essentially just like sis calls.

6:08 But what happened was we realized we adopted a pet. Um so if uh if you've not heard about the pet and cattle analogy from like the old infrastructure days, um pet is when you essentially have a

6:20 named and handtended entity. When it gets sick, you have to nurture it back to life. Otherwise, you you basically cannot afford to lose it. And cattle is more interchangeable, more disposable.

6:32 So when one fails, you can replace it with another one and move on. So a good example is imagine you had like a single database shard. It goes down, your product is down, you have a pet. But

6:42 imagine you have a master replica set up. Your master goes down, you can bring up a replica. That's a cattle, right? So you have many instances. One goes down, that's not a problem. You can bring it

6:50 back up. So what we had with our initial setup was essentially a pet. Um so few few issues with this debugging was really hard because everything was running in the container. We didn't know

7:03 what was causing the issue. So a a drop packet a dead container would show up very similarly and we had to essentially like websocket stream into the container to debug. Um the other issue was

7:14 investigating meant we had to uh essentially investigating was hard because customer data would live on these containers. So we didn't have a way in essentially to go in and debug.

7:24 So that was like the other issue we saw in our early access. And then the last one was if a customer wanted us to connect to let's say an M MCP in their VPC, it meant peering networks or

7:36 shipping them our harness and having them run it. So there were like a bunch of challenges with that architecture that that we weren't able to really have a good solution to overcome. So what we

7:45 decided that we wanted to essentially decouple the brains from the hands and I'll dive into what that means. Um so the agent essentially became three separate interfaces. On the left you

7:58 have the session which is essentially an appendon log of everything that has happened in the session so far. In the middle you have the brain that's your harness or the agent loop along with

8:08 cloud. Um and then on the right are the hands. So sandboxes your MCP tool calls etc. Provisioned on demand uh gone when the work is done. And if you need if you lose a sandbox you just spin it back up.

8:23 So every component essentially became a cattle and interchangeable. So when the sandbox died, uh the harness or cloud could choose to just spin it back up, right? The error essentially went back

8:33 to cloud and the sandbox to cloud was essentially like any other tool call. So the tool call fails, sandbox fails, it decides what to do and it might decide to spin it up again or choose to

8:42 continue to move on. um when the harness died, you could bring up a new instance of the harness and continue where you left off by essentially just reading your event log from the session and

8:52 continue from there. So work resumes from the last event as if nothing went wrong, nothing happened. Um so the only thing with protecting here was like your session log. Everything else was

9:03 interchangeable, could go down, you could bring it back up. The other thing that we did was credentials never entered our sandbox. With our previous setup, your credential

9:14 would be in your sandbox, so you'd be more susceptible to prompt injection. The change we made was if the sandbox ever needed to call out um to uh something that needed a token or access

9:27 control, it would be routed through a proxy that would inject your token before it called the external endpoint or external MCP. That way the model never sees your credentials or your

9:37 tokens which means you can never prompt inject claude to say like hey give me your tokens or print out the tokens or write them to a file. You can never do that because cloud actually never sees

9:47 your your tokens. The other thing we did was because we had this like append only event log in the session um our compaction strategy could stay flexible. So nothing is ever

10:00 thrown away. We're not compacting and changing your event stream. We're always storing each and every event that happened and then the compaction strategy is the one that's deciding oh

10:08 do I want to look at my entire event log uh summarize and put it in the context do I want to only look at like the last n events and put those into context. So we we could have a more flexible context

10:19 strategy because of this like interface design that we chose. And then the other benefit we saw is because we could immediately start our inference calls, we were able to bring

10:31 down the TAM to force token by about 90%. So the cloud would only spawn the sandbox when it needed and it would not wait for the container sandbox to spin up for you to get your first token back.

10:41 So we were able to get like a much snappier and faster experience with this uh architectural change. Um, and then here's sort of like the illustration of like one brain can reach

10:54 many hands. So your agent loop or harness can now call a sandbox container. It could call into a customer's VPC. It could call into an MCP server. So all these like hands are

11:05 essentially interchangeable. You can call and plug in many of these and it made our architecture a lot more flexible. Um, so if you take one thing home from

11:15 this, it's that harnesses encode assumptions and assumptions can go stale. So we designed interfaces to outlast these assumptions and made the architecture more flexible. So this

11:28 allowed us to like I said change our compaction strategy, change out the harness completely but the interface and the architecture remains uh the same and we can really have a more pluggable way

11:39 of operating this. All right, so next we're going to get into a little bit of a hands-on portion. U we got you some complimentary API credits to help you build with us today.

11:54 So, please scan the QR code, either sign in to your cloud platform account or create a new one and you should be able to um get in there and get those credits so that you can build with me and and

12:06 then with Gabe. And I'll I'll leave this for for a second. Hi. >> Sorry, what? >> Last slide.

12:25 It's basically what we talked about here, right? This is the this is sort of like the three interfaces we designed for, right? So the first one is the the the question

12:35 was like what were the interfaces that we designed that ma made things outlast uh changes. So we have the append only session log. You have the harness that's again interchangeable and then the hands

12:46 where you can plug in a sandbox tool calls or whatever the model might need access to and that that's what kind of makes it more generic and extendable. All right, going back to

13:00 the credits. Uh, does anyone else need to scan this before we jump in? Okay, still seeing a couple phones. Okay, going to give everyone about 30 seconds. Thanks for your patience.

13:16 Oh, there are problems with the internet. Oh, no. >> Uh, Gabe, do we have a mic? Because I I can't hear some of the questions. Yeah, the the credit should arrive once

13:39 you once you sign up in hopefully a minute or two. Um, yeah, we're getting a mic so that we can hopefully walk around and uh get get some of these questions. But yeah, I'm going to walk you through

13:51 building a really simple agent that tells you jokes. Uh, and I'm going to cover some of our core APIs, our concepts first, and then we'll hop over to

14:02 platform.entthropic.com to build your first agent. Um, so our first step is going to be creating our our environments API, which is v1 environments that helps you create the

14:13 environment or template for your sandbox. So this is going to have uh your networking setup. So do you want uh unrestricted networking or you want to restrict it to specific domains or MCPS?

14:24 you can define what packages you want installed on your uh container or sandbox. Um so this is going to be like the first step we're going to take to set up our environment.

14:35 Next you're going to create the agent. So agent is essentially uh you're you can give your agent a name. So in this case we have we're going to call it joke teller. Um we're going to choose which

14:46 model you want to use for this agent. So you can use opus 48, you can use haiku uh or sonnet uh your choice. Uh and then we're going to provide the agent with a system prompt. In this case, we're going

14:58 to say you're a comedian. Find a fresh joke on the topic. Deliver it well. Uh and then you can provide this agent with tools. In this case, we're going to provide it with agent tool set, which is

15:08 sort of like our basic tool set. This is like your bash tool set, read, write, grap, etc. And you almost all agents will need need this. Um so that's going to be your step two. Step three is going

15:20 to be finally creating the session. Um so session takes an agent ID and an environment ID and creates a session. This is your task uh unit of work or your task. Um and when the session is

15:32 provisioned it's idle. No work has been done right until you send an event. And then this is sort of what an event stream on your session would look like. Um you're going to have events that you

15:45 send and then events that the agent will come back to you with. On the left side you'll see you have user message. You can say, "Oh, tell me a joke about distributed systems." And then the agent

15:53 will come back to you with a funny joke. Um, you can use something called a custom tool. Custom tool essentially lets you define a custom tool that you want to handle how you uh how you

16:02 respond to it and claude will essentially put a custom tool use event on your event stream that you can listen to and then you can process that event and then return the result um to claim

16:14 tool result. And then there are some other examples in there for what type of events you would see. So you'll see session error if your session ever ends up in an error or sees an error. Status

16:23 idle is when your session is idle, not working. And this is typically when you're not really have a sandbox that you're using. Um and then interrupt on the left is when you want to stop or

16:33 kill the session and don't want to do the work anymore. Uh this is sort of like our full feature list. Maybe if we have time at the end, Gabe can kind of come back to this and

16:42 dive in. But Gabe will be kind of working with you on his part of the workshop going deeper into some of like these concepts like multi-agent and memory that we also provide.

16:52 All right, before we go to that one, we're going to hop over now to platform.claw.com. Um, and hopefully you can use your API credits and see those. Now, if you

17:04 don't, I have Travis walking around with the mic in case you have questions or you need to just like flag him down for for anything. Um but if you go to your console you'll see in this manage agent

17:14 section there is something called as a quick start. This is sort of like our um guided tour of how to build your first agent. [music]