Name: Managed Deep Agents 101
Uploaded: 2026-10-07T18:30:18.134Z
Duration: 59 min 41 s
Description: Managed Deep Agents 101

Transcript for "Managed Deep Agents 101": Alright. Hello, and welcome everyone to the manage deep agents webinar. Thank you for joining me today. I'm seeing so many wonderful people already in the chat indicating where they're from. Yeah. There's a poll. Go ahead and fill that out, for some of our previous workshops. So, so, yeah, we'll dive into the stuff very, very shortly. In fact, if backstage we can turn off the poll so that I can share my screen, that would be excellent. Amazing. Alright. So as I said, welcome to the manage deep agents workshop. My name is Ishaan. I will be guiding you today. Behind the scenes, we have two fellow people from the education team, Giselle and Sean. They are going to be here providing support throughout the webinar, making sure everything runs super smoothly, and answering your questions. So if you see stuff from them, know that they're there for you, and they're there for me. So here we go. Manage deep agents. What are we talking about today? Let's get right into it. So here is the brief rundown of what the next hour or so will look like depending on how much I talk for. I'll spend the first dozen or a couple dozen minutes talking about what managed deep agents are. That's what you're here to learn. Let me explain to you what they are, dive into the theory, how they work a little bit. From there, we'll transition into looking at an actual managed deep agent, taking a peek into the code, seeing how it all works. And at the end, time permitting, we will do q and a. If you do have questions during the session, please drop your questions. You know, we're here to help answer your questions. There should be a Q and A tab in Goldcast, so drop your questions there, and Giselle and Ishaan, who are behind the scenes, will get your... Get answers to you. They're gonna do their best to try to answer as many people as possible. But, yeah, drop your questions in that tab, and... Yeah. Alright. Without further ado, let's dive into it. So we're gonna start by talking about what an agent is, and then we will go up to what a deep agent is, and then we will go and finally end with what a managed deep agent is. So starting out with what is an agent. So an agent feels like it has been the buzzword for a couple years now. I would be shocked if it wasn't the word of the year for 2026, but I guess we shall see. A simple definition of an agent is that it is a model, a large language model at the core with access to a set of tools, and the model calls tools in a loop. Model works in tandem with the tools back and forth until it eventually produces an output for whatever input or query that you supply. So this is one definition of an agent. And another definition of an agent is that it is a model plus a harness. So this is probably closer to the definition that we use nowadays. And so let's, you know, explain what this is. So still at the core of an agent is a model. This is your large language model. Something like Claude's on it five or GPD six, that sits at the core of your agent. But on its own, it's kind of just like a word guessing machine, and it can solve some problems and answer some basic queries that you provide, but, it can't handle much more complex tasks or things that are a longer horizon. It needs a lot more support around it. And so that's what the harness is for. The harness is the scaffolding around your model that provides it extra capabilities, like access to tools or sub agents or skills or context, more and more things. And so this scaffolding gives your model more things to work with, more context. And in combination, they can start to com... Complete longer, more long horizon tasks that are much more complex. And so the purpose of the harness is to give the model the right context at the right time for a given task, and that is essentially what an agent is. I don't know if people here are fans of Harry Potter, but I like to think of Harry Potter here. Like, you can think of Harry as the LLM. Like, he... He's kinda he's kinda dumb on his own. Like, he he doesn't really know what he's doing half the time. But once you give him, like, Hermione's knowledge and Dumbledore's wisdom and whatever Ron provides, because Ron is Ron, once he has that support and that scaffolding, then they're able to accomplish much more complex tasks like, killing Voldemort. Sorry. I didn't mean to spoil it, but whatever. So that's what an agent is. Now we'll jump to deep agent, and then we'll get to a managed deep agent. So deep agent is still an agent. It is still this model plus harness combination. What makes it a deep agent in particular is the fact that it's using the deep agent's harness. So the deep agents harness is LangChain's opinionated harness. So our engineers have developed a harness. So all of those things that scaffold it around the model, being like tools and sub agents, We have developed a harness using best practices so that way you can just focus on the business logic of the agent yourself and all of that scaffolding is there for you. And so put simply, a deep agent is a customizable agent harness purpose built for complex real world tasks. And, you know, I've been talking a lot about a harness, but there's there's so many parts to a harness, and even this slide doesn't show everything that a harness includes. But some of the layers of a harness include the execution environment, so having a code interpreter or a sandbox or a file system for your agent to use. Context management is a really big thing. We just said that the purpose of a harness is to give the model the right context at the right time. So things like skills and memory and summarization and offloading, All of these things are managed by the harness. They're part of context management and really important for your agent to complete complex tasks. There's also the notion of delegation, so being able to plan before the agent completes very complex tasks or handing smaller routines and smaller work off to sub agents to make the outer agent's life easier. That's delegation, which is also part of the harness. And then middleware as well, so this idea of having these deterministic pieces of code that fire at different points in the agent loop that you specify, that's also managed by the harness, and one of which is human in the loop. And so, again, just to contrast the difference between what an agent is and a deep agent, if you were to just build an agent on your own, you would be responsible for creating the harness around it. So you would have to define what the file system should look like, how sub agents should work, how summary... Summarization should be implemented, and on top of that, how all of these things wire with your agent, how your agent interacts with all of these different things, which is pretty daunting. But with deep agents, since the harness is provided for you when you create a deep agent, the harness and all of those systems, like the file system, solve agent summarization, etcetera, that's taken care of for you. So that is built up and that's wired into your agent, so much less to worry about. So that's really the difference between the two. But still, a lot of what I've been talking about thus far has been about creating a good agent. Having something that will solve your problems in a pretty good way. Agents often have to complete pretty difficult tasks and handle difficult business logic, And so the whole point of building these deep agents is to, handle all that stuff and build the correct skills and sub agent routines, so on and so forth. However, there is a completely separate challenge at hand, which is taking your agent that might work really well locally and putting it into, a deployed environment, some sort of production environment or somewhere else. And once you start to do this, a lot more problems start to arise. You might start to want your agent to run on particular schedules or have durable execution or manage authentication and authorization. So many problems that you have to think about, and each one can and should be handled. And so that's what managed deep agents are here to solve, that ideally with managed deep agents, we can define an agent in a simple way such that we can take that agent into a higher environment as seamlessly as possible. And so this is something to get excited about because if if this works, which it does, then life becomes a lot easier. You have an agent in a... An environment that is very easy to manage with very low setup. So if that's the case, then come with me, and you'll be in a world of managed deep agents. I'm not Gene Wilder. Okay. So one sentence summary. What are managed deep agents? They are the simplest way to build and deploy production agents. So a lot of the infrastructure that's needed for a production agent will be handled by managed deep agents, and it will be handled simply. And, again, just to hammer home the point of, like, why this is so important, so with specific examples, when you have an agent that needs to write code, which increasingly more and more agents do need to write code, you do need sandboxes. These are little boxes where agents can write and test and run code. So this is its own piece of infrastructure. You may also need an LLM gateway to handle model traffic or a tool server or a context hub, all different pieces of infrastructure that on their own with a normal agent, you would have to manage this infrastructure yourself, choose the right thing, or develop it yourself, as well as wiring it into your agent. But managed deep agents bundles this all together. This whole picture becomes one deployment. So all of these pieces of infrastructure kind of get tied into your agent, on the go as you deploy them. And best of all, it's pretty simple to set things up. And because of this, like, if MDA handles so much, your responsibility comes down to just writing the business logic or the intelligence of your agent, and MDAs will handle the rest. So you would provide things like the instructions, which is like the system prompt for the agent, the tools that the agent can call, the skills that it has access to, and the model, all of the different things that customize an agent to truly make it solve the problems that you want. In other words, you configure the brain, but everything else, how it runs and how it manages context, that's handled by MDAs. So MDAs provide the deep agent's harness, which we talked about before, all of that scaffolding, as well as now the managed run time, which includes things like the agent server, sandboxes, schedules, and so on and so forth. And so the way that this works is we will see that, in a managed agent is essentially just a bunch of files, in some sort of directory as a project directory. And once you deploy your managed agent, which amazingly is just one line m d a deploy, we use links with deployments, which has a links with agent server, and this unlocks a lot of different things for your agent, such as an agent server API, some threads, runs, streaming, etcetera. And so this is kind of what happens when we deploy a managed deep agent. So I've already been yapping for ten minutes. I'm sure you're tired of hearing my voice. We're gonna launch a poll question right now to test your knowledge on something that I just asked you about. So that poll should appear soon, maybe, and I'll give you a couple seconds to think about the answer. Okay. It is live. I'll give you a few seconds to think about it, and then we will reconvene. I think that's the wrong poll, but it's okay. We we can still probably work with it. So let me... Let's let's pull up the results of the poll. And... Okay. So there's there's a ton of votes for everything. Let's see. Sandboxes has the most votes, skills, instructions, channels, schedules, and agent server. Yeah. Really great. The answer to this question is all of the above. And I know some of the stuff we didn't talk about yet, so maybe this is unfair to you. But that's okay. I'm an unfair person. So really great. All of these things are provided to you by the managed runtime, and we will see we will see this very, very shortly. So cool. Let's jump back to the slides, if we can close down the poll. Beautiful, beautiful, beautiful. Alright. So So here we go. I I want you to remember one thing, not that I'm an unfair person, but at the core of your managed deep agent is a deep agent. So the brains of your managed deep agent is still a deep agent. This is still something that you would define on your own. So all of that stuff that I talked about, like the the business logic, the instructions, the tools, and whatnot, that is the brains of your deep agent. What manage deep agents provides you is now this, like, extra layer of scaffolding that your deep agent would interact with, and this this becomes, things like infrastructure. So, things like sandboxes or running your agents on a particular schedule or access to channels and connections, which we'll define very shortly, this is the extra layer that managed deep agents provides. I see that the the poll question went live. So let's let's just take a look at those... The responses. If you haven't taken a look at the new poll, go ahead and vote for that, and we will show the results now. Cool. Okay. What do manage deep agents manage for you? The overwhelming majority is agent run time plus deep agents harness. Beautiful. Absolutely correct. The business logic, yes, that is still part of a managed deep agent. That is stuff that you define yourself, but what is managed for you is the run time and hardness. And now everyone's swapping their votes to the correct answer just like me in high school. Awesome. Great work. That is, yeah, a more fair question. Back to here. Okay. So I just said deep agents are the brain of your managed deep agent, and managed deep agents helps with the whole part of going into production. This is not to say that you should never use deep agents. Deep agents are still there to... For you to use. Now the question of choosing between deep agents and managed deep agents comes down to how you want this infrastructure to be managed. So if you have your own infrastructure to handle, things like schedules or credentials or sandboxes, completely okay. You can define your own deep agent, and you can handle the connection to all of these three things. Totally okay. But with managed deep agents, these things are provided for you through the links with deployment, and so you can configure them very, very simply. You'll see that a lot of these files and directories end up just being a couple of lines of code. So that's kind of the distinction between the two. Okay, so I think now I've kind of hammered the point of what a managed deep agent is, that we can go into a higher environment a lot easier. I want to now walk you through what a managed deep agent looks like. So I mentioned this briefly in passing before, but a managed deep agent really is like a file structure, a file system structure. And so a lot of managed deep agents, or MDA is the abbreviation, so I might use MDA. Many MDAs have a structure that looks similar to this, where you have files or directories for specific parts of your agent, one for the agent definition, some for context, some for code that the agent can access, some for configurations with related infrastructure, and others for dependencies, secrets, and so on and so forth. And so what we're going to do is I'm just gonna go through each of these files and kind of tell you what they do and what they kind of look like, and hopefully, you'll see how simple it is to really work with these MDAs. So we'll start with this agent. Py file. So this lives in your home directory. And the question that this file answers is, where does my agent start, and how do I choose its model, or where does the brain of my managed deep agent live? And that goes in this agent dot py file. And this is a simple example of what this file could contain where we are defining a deep agent and giving it some parameters. So as I've said before, the brain of your managed deep agent is a deep agent. A deep agent is a model plus the deep agent's harness. Here, we are specifying the model, and this define deep agent function provides you the deep agent's harness. So, again, that's the brain. And then you also supply some other parameters that you might need, like tools the agent will have access to, human in the loop configuration, middleware, etcetera, etcetera. And then when you actually deploy this agent, it kind of compiles it into a deep agent through this create deep agent command in the background. Hammered home the point, the core is your deep agent that is defined in agent dot py. Everything around it, this extra layer that manage deep agents provide, all of those are handled by these other files and directories that you specify as I showed you in the file system. Shoot, forgot to delete that. My bad. Okay. So let's take a look at the instructions. Md file. So this is where you shape agent behavior, and where your system prompt lives. So an example, instructions. Mvile will look something like this, the information that your agent should receive at every turn of the conversation. So in this case, I'm letting the agent know you are a careful research assistant, use Internet search, etcetera, etcetera. This is essentially your system prompt. When you deploy your managed deep agent, this gets written to context hub, which is something in LangChain, which we might take a look at later. And the agent, when it runs in this agent server deployed environment, it reads from context help. But again, instructions live in their own instructions. Md file. Now onto skills. So skills are these repeatable tasks, specifications that the agent can access and helps keep the prompt lean. So these have become pretty standard, in terms of agents and how they work. Skills are written as markdown files. For managed agents, you create a skills directory, and within it, you have a skill for each thing you want to include. Start out a skill with some front matter, including the name and the description, which the agent references, and the body of the skill is what the agent reads when it needs the skill, and this helps the agent complete repeatable tasks that are maybe one off, for example, style guidelines when it's writing some UI code. Okay. Now onto tools. So tools allow your agent to take action, and often tools will need some sort of API key or a secret. And so the files we look at are this tools directory and the dot end. So tools have a shape that looks like this. They are these, Python functions, straight up Python code. They are decorated with an at tool decorator to indicate that they are a tool, and the agent references the name of the tool and the description. And based off of the name and the description, it decides whether it needs to call it. When it does so, it runs the code within the tool and life is good. So tools are pretty standard for agents, works the same way with manage deep agents. You would create a file in the tools directory, and then you would have to import it into your agent dot py where the brain resided. So that's one quirk that you need for tools. Now, often, your tools need to access some sort of third party and which requires a secret or some sort of password. And often, you store these API keys or secret in a dot env file. When you run your agent locally, your managed deep agent locally, which you can do with this mda dev command, a local instance of the LangSmith deployment system will load up. And when you run the agent, it's just going to read the values from the dotenv file. When you actually deploy your agent, your manage deep agent, these secrets get written to, a deployment secrets vault in LangSmith. So they they all get loaded into LangSmith and stored securely there, and your agent ends up reading from the secrets in LangSmith. So this allows you to use essentially the same exact code, whether you're running it locally or in some some sort of other environment. So reading this, like, environmental variable still works in your deployed environment because it's reading from the LangChain secrets. There's still a little bit more on tools I wanna talk about, which is if your agent, wants to sign into external services and actually act on behalf of yourself, how exactly do we do that? And can we have an agent... A single agent that acts individually based off of the person that is using it? And this is possible, and this uses something called connections. So a connection is, again, kind of just like a secret that is stored in the LangChain workspace securely. So I would provide it a connection. I would create a connection, which is some sort of secret value. And if my agent needs the secret value in the code, I will say, okay, connections dot get and provide the name of the secret that I need to access. And the agent will extract the connection from the secure LangChain workspace secret store, and the entire communication of, the agent with the third party, so if I have a secret that's trying to, sign into GitHub and act on behalf of myself or Notion or something else, all that communication is handled for you. So these connections are essentially just these secrets safely stored such that the agent can act on behalf of you for, a different service. And, incredibly, these credentials can be owned at different scopes. So you can have a credential that is agent scoped, meaning it is a shared credential. Everyone kind of uses the same key here. This is particularly useful if individualism doesn't matter. Individualism does matter, but it's like for the case of web search, it's okay if everyone has the same key. So here you can scope it to be an agent scoped credential. But you can also have user scoped credentials, and this is important when each person, has particular requirements that they are able to access. As an example, if your agent is accessing Notion pages and wants to act on behalf of a user, that agent should probably only see and be able to access the Notion pages that that user has access to. So this is when you would use a user scoped credential and each person would then be able to log in as themselves. And the way you would create a connection is through this mda connections create command, and there's a few ways of doing this, depending on how the service provides its secret. So if the service provides a static API key or a fixed API key, you can use this secret from env flag, and it would be a fixed API key and the owner would end up being the agent, so it would be agent scoped. If the service you're accessing has a general OAuth entry point, you can configure it with OAuth. So for example, with GitHub, you can create a connection that utilizes OAuth, and what ends up happening is this is user scoped. So when the agent accesses GitHub, when the user provides a query for the agent to access GitHub, the agent's going to say like, hey, I need you to sign in. I need you to go through this OAuth workflow. You know, you provide your own credentials, and then the agent will act on behalf of you. And also there are MCP OAuths available, which work in a very similar way with this MCP flag. And, again, each user becomes... Or the credential is scoped to the user. So it's been another dozen minutes of me yapping, which means it's time to not listen to me talk. So we're gonna queue up another poll to test your knowledge, and we will review the answer in just a moment. But for that, I need to hydrate myself. So... Okay. Cool. The poll is live. Give another fifteen to twenty seconds to think about it. It might seem a little familiar. K. And now we'll pull up the results. And, wow, look at these incredible results, pretty much equal spread across all of the answers. And that that is correct. The managed runtime does supply all of these things for you, and some of which we still need to talk about, like channels and schedules, for example. But, yes, correct answer. So, not as unfair as before. I'm somewhat nice. Okay. Let us dive back into the Yap session. Here we go. Hopefully, we're learning. Alright. Onwards. So MCP, I was kind of just talking about how you might configure a connection with MCP, but just connecting an MCP server in general is done through an mcp dot py file. So this allows you to access these third party services and utilize their tools. So the way that this works here is you kind of specify your MCP server in a mcp. Py file. This you can use the standard JSON that a lot of MCP servers expose, and should you need a credential or a connection, you might end up using this connections. Get from before to extract and provide the secret key that you need. And so the agent, when it needs to access these third party tools, it will run the server. The user connection will be injected into the server, so that way the agent can act on behalf of the user, and results will be passed back to the agent. Middleware, I'm just gonna speed through this one because why not? Middleware are these, like, deterministic pieces of code that you can run at particular points in the agent cycle. So, for example, if I wanted a piece of code to run around a tool call, like logging the tool call, I could provide that through a decorator, like wrap tool call, and now when the agent executes, as it was being executed, wrapped around it, this thing will fire. So middleware is something you can always define, and that goes in its own directory middleware. So, again, there's there's this compartmentalization of all of these different aspects into their different directories and files. Onto memory, so how does my agent remember across conversations and what's shared and what's personal? There are two layers to memory. So just as before with connections, where there were these two scopes of user and agent connections, kind of similar for memory, except you can enable both. So agent layer memory is memory that is shared across people. So this is particularly useful for when every caller, wants to access, like, this type of memory. So maybe you use this for team conventions that you want your agent to remember or reusable procedures. So this would apply to every caller, and every caller can influence the agent agent level memory. But then there's also user layer memory, and this is important when you want the agent to remember things about each individual person. So it's useful for personal preferences and caller specific context. So two layers of memory, they're not mutually... Like, you can you can enable both of them, and have your agent have both of these layers of memory. They just remember different things in different ways. Okay. Now onto the fun stuff. Like, sandbox is pretty important. Sandbox allows your agent to safely run code, and, it should have some control of where the agent should reach. Normally, this is, like, sometimes annoying to set up that you need some sort of sandbox system and connect your agent to it. But it ends up being really simple with managed deep agents. You just need the sandbox directory, and, literally, all that you need is an initialization file in the sandbox directory. And really just call this define sandbox function, and I'll show you what that looks like in an example in a little bit, but it ends up just being a couple of lines of code. And why this works is when the deployment runs, when we run mda deploy, the deployment recognizes we have a sandbox directory. It sees the definition, and the deployment knows that, okay, I'm going to spin up a LangChain sandbox, and it will connect the agent to it. So the entire process of connecting a sandbox to an agent is literally, like, two lines of code, which is why MDAs are so seamless. And so a sandbox provides your agent the ability to write code. It gives it an environment to do so, where it has its own file system and its own shell to execute commands. But also a nice thing about langsmith sandboxes is that it comes with a proxy. So this sits outside of the sandbox and helps inject headers and kind of controls what destinations the sandbox can reach. So this is nice because now your connections can be injected to the proxy itself and your secrets don't have to live in the sandbox itself. Okay. So that was sandboxes. Now for identity. Identity, controls who's allowed to use your agent, as well as like what type of conversations that the people have. So there are a few ways of setting up identity. First is through a LangChain API key, and this is done by default. And the way that this works is that if identity is configured in this way, the callers of your agent essentially provide a valid LangChain key, and the manage deep agent will verify that key. And if it's verified, all is good. The user has access to whatever shared threads exist. If your application that you have to sign into to access the agent has Supabase configured, you can also use Supabase for identity. So the way that this work is that users would sign in through Supabase. It would send off a token and a JWT, which the MDA would approve and authenticate, and if all things pass, then the user has access and they get their own private threads. And if you have your own backend that you're using and your own API to configure user access, that can also be set up with managed deep agents, and again, the API should authenticate the user and eventually call the deployment. So these are the three ways you would set up identity. Now onto channels. So increasingly, more and more people want to use their agents outside of a single UI. You want the ability to call your agent through channels like Slack or WhatsApp or iMessage, these different ways of communicating with your agent. And that's what channels are here to solve. And when when you think about it, like, this is a pretty complex task, having an agent that lives in Slack that you can communicate to that still handles all of the work that your agent is supposed to do and responds back in Slack. Like, that is a lot of effort to try to connect all those things together. But with managed key patients, it ends up being really, really simple. So a channel puts our agent inside of a messaging service such as Slack, and when a message comes in, the managed deep agent will check first that the message is genuine, figure out who sent it and what conversation it belongs to, and then eventually run the agent behind the scenes. Once the agent is completed, the managed deep agent handles the whole part of posting the response back to Slack. So setting up a channel, all of these intermediary steps between sending a message in Slack and having the agent run the query, all of that is kind of taken care of for you. And, again, this is, like, this is pretty complex. But, with managed deep agents, it is... It's literally just this. Like, it is literally just a slack. Py file, and there's one line of code. You can add some more customization to it, but it is just as simple as this. Defining a channel in this one line, what ends up happening is when you deploy it, again, since managed deep agents follows this particular file structure, the deployment recognizes you have the channels directory. It sees the slack. Py file, and it handles all of the rest of it. Spinning up Slack, it will ask you to authenticate yourself and connect to workspace, but all of that piping together that we saw in the prior slide, that's taken care of for you just through these couple lines of code. And so once you deploy it, your agent will appear in Slack. It'll send you a DM. You can respond to it. The agent will get back to you, so on and so forth. Again, this is, like, this is pretty cool. Right? Like, one line of code for all of this. One line. Like, dang. What a world we live in. Okay. But there are specific channels. So I I showed you it for Slack. You can also use HTTP channels, which turn MDAs into an HTTP endpoint that any external service can call. So you should use this for any provider that MDAs don't support directly. So we have git... Or sorry. We have Slack, provided directly. GitHub is coming very, very soon, I think, and probably a couple more soon. But otherwise, you can use HTTP channels. And... Yeah. So with this, you just supply two callbacks, one that authenticates your request called verify and one that converts the request into a message, which is called parse. And the managed deep agent owns the handoff, the agent run, and the reply as we saw in that prior Slack. And so this is kind of an example of how you would define an HTTP channel. Again, pretty simple. It's just channels dot HTTP now, and you provide those two functions I just mentioned, verify and parse. Okay. I think we're getting good. Okay. Next is schedules, so running agents at a particular schedule. Maybe you want it to run every morning or how does it remember past runs? Again, this is kind of a heavy lift from an infrastructure perspective, having your own perhaps microservice that handles scheduled runs, that's a lot to deal with, but, again, this ends up being very simple. And as has been the pattern, you kind of have your directory, in this case, the schedules directory. Within it is a single file, and there you can define a schedule in just a couple lines. So here I have defining a schedule to run the agent every weekday at 8AM and provide a starter prompt for it to go off of. And everything else, the running of the agent at that schedule, that is handled for you with the LangChain deployment environment. So there's no extra infrastructure needed, no other piping needed. Again, just a few lines of code. I'm gonna skip this slide since we're running low on time already. And in fact, yeah, let's let's run another quiz question because it's been another dozen minutes of yapping. So I think we have another one locked and loaded. So hopefully that'll be live in just a minute. Excellent. Gives me a hydration break too. Give another twenty or so seconds to think about it. Alright. Let's take a look at the results, which we shall see in just a second. Okay. Pretty close. 70% saying user level, 35% saying agent level. Your sales team has an agent that schedules one on one meetings with customers. What type of credentials should be used for the agent's access to Google Calendar? So, yes, if the agent is scheduling meetings and each person of your sales team needs to have a one on one meeting with other customers, you want the agent to kind of act on behalf of the salesperson, and so you would want a user level, connection for this, a user level credential. So that way you can schedule on that person's Google Calendar. So tricky question. Answers are shifting in the correct direction, which is good to see even though I just told you the answer, but whatever. Okay. Let's move on. Move on. Here we go. Couple more slides. So with managed deep agents, you should run your agents locally. This is how you test before you deploy that, and that's done with this mda dev command, and this handles a lot of things. It handles the secret management, but it also spins up a local instance of the agent server and a local instance of LangChain Studio, so you can test your agent on your own without it being in an in an environment. But when you're ready to deploy it, you use this m d a deploy command that I've been mentioning, and this makes your agent go live on the agent server. And those are really the two commands that you need. Okay. So I've done a lot of talking. Hopefully, by now, you are fluent in m d a ness. I wanna shift gears and now show you an actual m d a that's been created. You can access the project repo through this QR code or this link, though I recommend for now just watching me as I walk through it, and then maybe going through it on your own time. For now, just watch and learn and, you know, continue looking at my ugly face. But the agent we're going to build is a PR writing manage deep agent. So something that can write code to your repository, in GitHub. So create personal PRs in GitHub, and you can also call this agent from Slack. So it's a lot of things that we want out of our agent, but this is what we're going to try to build. So I need to switch my screens, I'm trying to see... Let me see. Okay. I think this is the one. Brilliant. Okay. So here we go. On my left, you have... This is like the code base that I'm working with. If you access the repositories, it's the same thing. And on the right is just gonna be some demonstration. So just a little bit of understanding of what the agent we want is. I have this code base right here called a simple game that I've coded up. All it is is an instance of Tetris that you can, you know, you can play this game however you want, so on and so forth. So this is this is the code base that we're working with. Our agent is going to make changes to it. And then in practice... Whoops. I need to go here. What this would look like is I want to be able to call it from Slack. So maybe you have a team that's communicating about what kind of changes that you want. So in this case, we wanted to change the background color to purple. I should be able to call my agent through this at command, tell it what I want. It's going to do all of its work, create a PR, and get back to me in Slack. So all of these things are things that we want out of our agent. So we'll build it up. So, progressively, we'll build it up. It's gonna be a managed deep agent, but at the core is the brain, which is the deep agent. So we still need a deep agent at the core. And as I mentioned, that is the agent dot py file, and that is right here. So I am defining my deep agent, and I'm giving it a model. So in this case, cloudsonnet five. This gives me the harness. I'm also providing a name for it. So on its own, this can't really do too much. It is just a model plus a harness. It doesn't have any customization. So the first thing that I want to do is actually provide the agent a sandbox as well as the code repository. So since this agent needs the ability to write code and edit code, it needs a sandbox to test things in, and it should also have access to the code repository. So all of these things I'm going to set up with... Like, through a managed deep agent. So on its own right now, all we have is the agent. Py file. So we will include those two things, and here we go. So first thing I wanted was a sandbox. As I mentioned earlier, we just need to specify this sandbox directory and an initialization file within it. And so this is what the init file looks like. As I mentioned a couple times, it is literally just like two lines of code. Import the define sandbox function and then actually define a sandbox. And I pass in some parameters, but that's kind of all that you need. There's no additional wiring that's necessary. The deployment is going to find this file, see the definition of the sandbox, and spin up the sandbox from there. So that's all we need for the sandbox. The next thing I want to do is get the repository synced in, which is through middleware. So we have a middleware function... Or middleware folder here. And within it, I have a file that contains my middleware code. So this is a function that I want to fire at a particular point in the agent loop, and I designate the point with the decorator, in this case, before the agent executes. And all this is doing is running git clone, so it's going to clone the GitHub repository and make sure that that's included in the sandbox. So ideally, when this executes, the code will be... The code will exist in the sandbox and the agent will have access to it. So I'm trying to spin up this locally so we can play around with it. Just give it two seconds. So behind the scenes, I have run this, I've started up the dev instance of it, so this mda dev that I mentioned before, and this starts a local instance of the agent server. I'll move that off screen, and now we have this, like, local instance of LangChain Studio that we can chat with, and this is gonna chat with our agent. So in order to test to ensure that the agent does have access to the sandbox and the, repository itself, I'm gonna ask it this question. What versions of git and node are you using and what was the last commit in the Tetris game? So if it has the sandbox access, it should be able to run a command to check the versions of git and node. And if it has access to the repository, meaning that the middleware did fire, then it should be able to see the last commit in the Tetris key. And so now we will patiently wait for just another three seconds. Okay. That was pretty close. A couple more seconds. And here we go. Okay. Here's what I found. It gave the versions of git, and it sees the last commit that rhymed. And we can we can look in a little bit. This is the command that it ran, git version and node version. So it did run that in the sandbox, and then it did some more. We got the commit, so it also has access to the repository. So the middleware did fire. So that's setting up the sandbox and middleware. Next thing I wanna do is handle the business logic of this agent, so, business logic and connection to GitHub. So I want to specify the instructions, the system prompt that the agent should follow, as well as the skills that the agent should have access to. And then at the same time, I want to configure the GitHub MCP. So allow the agent to write code and write that code to GitHub. And finally, I'll configure some human in the loop. So it's a big step that I'm going to do all at once, but if you stick with me, I promise it will make some kind of sense. So here we go. Alright. Investigating this side, there's a lot more stuff in here. We have skills, we have tools, we have instructions, so on and so forth. Let's take a look at the instructions file. So this gives your agent the system prompt. You should tell the agent what it needs to be doing. You fix bugs and implement small features. The workspace exists in this, workspace slash app in the sandbox. For each request, determine if it's a bug report or a feature request, so on and so forth. Right? Lots of instructions right there. So that's this file over here. We also give it some skills too that the agent can follow. So whenever it's adding a feature, it's going to ideally load this skill. We have the name and the description at the top, and we're telling it, okay. Get the behavior, check the scope, read before writing, etcetera, etcetera. Here's another one about opening a poll request. So if we ever want the agent to open a poll request, I'm kind of telling it the formatting that I want the PR to appear in. So it should have the following body, this what, why, changes, verified, etcetera, etcetera. So skills, instructions, pretty standard. This is shaping the behavior of the agent. As far as the GitHub MCP, so this over here giving the agent the ability to talk to GitHub, this is done in the m c p dot py file, which is located within tools. So here we go. We use this define MCP and specify a list of servers, and this is the GitHub MCP server. A lot of MCP servers publish the JSON or format that you would need specified. So if you wanted to add another MCP server, you can just kind of paste it right after this one, and the connection will be good. But there's a few things that I wanna point out here. First, I'm including a set of tools. So these are the tools that I anticipate my agent to use, and it doesn't really need to use other tools. So create branch, pull... Push files, create pull request, etcetera, etcetera. But, importantly, I want the agent to act on behalf of myself. When it creates a PR, I want it to be under my name, Ishaan. And so for that, I need to provide the, the MCPA connect... Or a credential that shows... That proves that I am who I am, and moreover, the agent should act as myself. And that's handled by this connections dot get right here. So this connection is going to, it's essentially going to be a secret value. We're extracting this patch GitHub, that's the name of my secret, from where the secrets are stored, and I'm saying I want this secret to be at a user level scope, so it should act on behalf of myself. So when this GitHub MCP is called, in order to get this connection value, it is going to search for this patch GitHub variable, the secret, and know that it's for each user, and it will handle the connection to GitHub that way. So I know it might not make so much sense right now. We will see it in action in just a little bit. But in order for us to access this, this variable, we need to create a connection. And the way that a connection is created is gonna be as follows. And so I pasted the command here. Let me make it a little bit bigger. Probably harder to see, but... Oh, well. Let me just minimize this. Classic technical issues. Okay. This is the command I'm using to create the connection. So m d a connections create. I'm giving it the name, patch GitHub. I'm configuring it with OAuth. So this was on one of the previous slides, how the how the service you're accessing, provides the credentials. So here, I wanted to do it through OAuth. I'm connecting to GitHub. You have to provide a client ID, which is right there, and then I'm also giving it a scope. So this will create the, the secret that I need. Here, you have to provide a client secret. So I will do that. Don't worry. You won't be able to see it, so you can't steal my stuff. And there we go. I've created the connection. This secret value now exists, and so when the MCP server needs to be hit, it is going to extract that value. Okay. Keeping an eye on time. I'm gonna try my best. The other thing that we added here was human in the loop, so that is done in this agent dot py. Human in the loop is configured with this interrupt on parameter, and I'm specifying the tool that I want it to pause on. So this GitHub create pull request, this is saying whenever the agent wants to run this create pull request tool from the GitHub MCP, I need the agent to pause. I need you to stop and ask for my approval to run it, and I will either approve or reject it. So that is exactly what human in the loop is, letting the agent pause and ask for human approval. And, ideally, when we test this out, when the agent writes a pull request, we will see that in action. So let me, let's try loading this up. So once again, we're gonna launch the local instance of blanksmith studio. We're going to test out this updated version of the agent with all of these things configured and hopefully see it in action. So what I want to do, I want to write a PR, essentially, to test everything we just added, and it's going to be a very simple change. Right now, the game has this new game button. I just wanna change it to say restart. So we will ask our agent that. Open a PR that renames the new game button to restart. And, immediately, you see that, okay, it needs to access GitHub. We had configured it with OAuth when we created the connection, and so it is stopping, and it needs us to connect to GitHub. And so this connect button appears. When you do this, it will verify you through OAuth because that's what we specified. So my authentication was successful, and now it's gonna continue doing its thing. So that is this part of the code... Or sorry, not this part, wherever the MCP is. That is this part of the code in action, that now it's using the patch GitHub secret and it'll now act on behalf of me. So we can take a look at what it's doing. It's reading the read me. It's loading a skill, the fix a bug skill, so that's great because that's something we just added. Now it's reading some files, editing some files. I can do this in five minutes, I think. Okay. I got it. I got it. No worries. We're gonna let it keep going just for another couple of seconds. Again, hopefully, it's gonna drop the PR because that's what we want it to do. And here we go. Okay. Review GitHub create pull request. So this is the PR that it wants to write, and you can see the body, the what, why, changes, and verify. And that matches exactly what we specified in this skill. So it did load this skill. It followed this body suggestion right here. But importantly, it is paused. It has asked me to accept or reject this PR. This is the human in the loop configured back over in index... In agent dot pie. It's interrupting right before it creates the pull request. So let me accept it, and I'll let it do its thing. And, okay, it's completed its work, and it's opened up a PR right here. And so there you go. GitHub PR taken care of for you, all handled by the agent. Okay. So that was that. Last thing I wanna configure with the agent, we still want the ability to call the agent from Slack. So first, we can include memory, but that's not important right now. Importantly, I wanna connect it to Slack and run it on a schedule. So I will implement those right now, and we're just gonna take a look at it. Unfortunately, we don't have time to deploy it, but that's okay. I just wanna show you how simple it is to configure these things. So for memory, for example, remember the two layers of memory, the agent level, agent layer of memory and the user layer of memory. And this is toggling it on just like this, memory dot py file, define memory. Good. We have memory set up. Let's take a look at channels. That's the one that matters. Connecting to Slack, it is as simple as this, slack dot py file, import channels, channel equals channels dot slack, and I'm giving it these parameters. You don't need to specify these parameters. That is all you need. When the agent deploys, it will find the slack. Py file, see that a Slack channel is defined. It will then connect you to a Slack workspace. So you would choose the workspace that you want your agent to appear in, and everything would be handled for you. This is literally it. Unfortunately, we don't have the time to show you how the deployment would work. It would take a couple minutes to deploy, but I assure you, eventually, it will appear in here. Let me... This is this is something that I ran, last night at 10:26PM. So you know how late last night I was out for. And change the background color of the game to green. The agent would appear here. You tag it just as if you were tagging your colleague, and it does exactly what we want it to. So, again, it is just these couple lines of code. You don't have to worry about all of the infrastructure and wiring together. And I believe that is all I wanted to cover for this demo. So I have two more minutes. I just wanna quickly wrap up. Again, you have access to this. You can play around with it on your own. Even better, there's a take home version, so you can build the same, MDA that I built yourself. There's instructions guiding you through the process. So highly recommend checking this out. You can deploy your agent to Slack. All of the instructions are there for you. If you do not have access... Or if you have any questions, feel free to email me, which I'm going to add to the chat right now because I didn't put it on the slide. So you can email me, but play around with that. If you wanna learn more about managed deep agents, I recommend checking out this LangChain Academy course on deep agents. There's a section at the end covering managed deep agents. But even better, a managed deep agents course is coming your way very, very soon. You might see a familiar face. You might not, but keep your eyes out for that. High... Highly recommend checking this out. And if you enjoyed this webinar and you want to learn more, we have another webinar coming up in a few weeks. This one is about agent e valance one zero one happening on October 28. So feel free to attend that. It is free to register for. QR code is right there. So feel free to register for that. I think that's all I got. Unfortunately, we don't have time for q and a, but I... I'm certain that Giselle and Ishaan did an excellent job handling the question. So hopefully you got responses there. If you have more questions, please feel free to email. And I think we should also have some sort of feedback survey running or will be launched very shortly. I don't know how that works exactly, but that's all I got for you today. Hopefully, you enjoyed and learned something about manage deep agents, and thank you so much for attending. It was really, really great.