Name: Build and Deploy Deep Agents with Managed Infrastructure
Uploaded: 2026-10-21T16:01:23.082Z
Duration: 37 min 12 s
Description: Build and Deploy Deep Agents with Managed Infrastructure

Transcript for "Build and Deploy Deep Agents with Managed Infrastructure": Alright. Good morning, everyone. Welcome to... Or ask me anything on Langht Smith, building and deploying deep agents with managed infrastructure. Gonna give it a couple of minutes as I see folks trickling in now, and then we're gonna get started. It's gonna be myself and Nathan here today. We're going to go through a little bit of material on what you get with Blacksmith, a quick demo on how you can build and what you can build, with manage deep agents, and then we're going to have a live q and a at the end of it. Alright. I think we have enough folks trickling in, and I'll kick it off. Right? So as I was saying, we're gonna start with intros from Nathan and myself. Then we're gonna talk a little bit about what type of agents are being built and what happens when folks try to move an agent from prototype to production, what sort of obstacles they hit. And then we're gonna talk about, can we actually make this whole thing easier and how we are trying to do that with managed agents. And Nathan's gonna show you a demo of how it works in real life, and then we're going to go into live q and a. Right? So I'm Kartik. I'm a product marketing manager at Langshane, and I'm very interested in how we build agents, the infrastructure for agents, and how we are going to scale up to thousands and thousands of agents in the future. And with me is Nathan. Do you wanna give an introduction? Sure. Yeah. I'm Nathan. I'm a product manager here at Langchain. I am working on manage deep agents primarily, and I'm really looking forward to the session. I've got a couple of cool agent demos to showcase, towards the end of the session, and I'm also looking forward as always to questions from everyone, which always are fun and surprising. So definitely share, like, use cases in the chat as we're going. We're gonna be pulling the questions out at the end of the session and, like, talking through some of the different ways that we've seen people use MDA. So I'm really looking forward to session. Carly, go for. it. Thanks, Nathan. So, before we start, a little bit of housekeeping. You can drop questions into the q and a panel anytime. You should be seeing it on the right side of your screen. We'll answer them live at the end of the prepared content. Right? We are recording. this, and we will send it to you after the session gets over. Once you're done, we'll be very, very happy to hear feedback that we've got about this session and things that you think you would like to hear from us in the future. You can also keep throwing things into the chat, things about questions that you have. We can pick it up from there if it's relevant, and you can also... We'll be very interested to know what you are building and what you're trying to do with Langht Smith and agent in your companies. Right? So I think we're at the stage where we have seen that agents can really boost internal productivity. Right? And we have been talking to a lot of our customers who are trying to build agents for themselves and for their customers, and there are few patterns and use cases that we keep seeing pop up all the time. Right? One of the top three categories of agents that we see is GTM agents, where companies are building agents that can dive into their internal systems and then help their go to market organizations with outreach, research, progressing the pipeline, and so on. The second big category is coding agents, which really exploded towards the end of last year. And now there are agents which are sitting inside companies with access to all of their different systems that is helping with issue triage, with actually building and generating code, and then with PRs and testing and so on. Right? A third big category we see is analyst agents. These are agents that help with data analysis, with analyzing documents. These are very, very domain specifics. For example, we have a customer who was working on on the legal side and is trying to build data analysis and document analysis that are specific to how legal cases work and so on. Right? And two patterns that we keep seeing come up is that most often, a lot of our customers build teams of task force agents. So there's going to be one agent which can call a bunch of other agents to do data analysis, to build some code, to write up that PR, to test it, and so on and so forth. Right? And our customers are also building a mix of internal and external agents. Internal agents, they're really looking to move fast and get that functionality in their hands of their associates so that they can really boost productivity, like, ten ten x. Right? But I'm sure a lot of you have gone through this. Right? When you're trying to build agents, a lot of you hit this age old problem of, hey. Work on my machine. Right? We can get to a prototype really fast. The prototype works for a couple of minutes. But when we go to production, there are a bunch of things that change. Right? Like, we have to build to have multiple users concurrently using the agent. The agent needs to run for hours, always on one go and do work while you are focusing on other things. It might need to ping you for approval and wait for it and needs access to multiple systems where you either need to authenticate as the agent or as yourself to get the right access then. Right? And when you do this, a bunch of questions pop up. Right? Can one user see another user's data? Does a crash make the agent repeat an action? Are we going to start over every time that happens? Does the agent remember each user's preferences and knows how to use a certain tool the way that this particular user likes it? And does it resume smoothly when it came in a previous data. Right? We could kick off a task at a Friday evening, and then we forget to check what approves are needed. And then Monday morning, we come back and hit approve. We want it to pick it up like nothing happened in between. Alright? And so these are all real infrastructure problem that will be the wrong key behavior, and this this often topple up folks as they're trying to move from prototype to production. And so we have been thinking about, can we make shipping agents easy? Right? And the way we think about building and shipping agents is that there are three layers to this. Right? The topmost layer and the most valuable layer for you is the business. Right? You think about the prompts, the skills, the agent behavior, the tools, and the custom sub agents that you need, and this is how your agent behaves for your specific domain and your specific task where you're the subject matter expert. Right? And then in order to make this work, the two layers below it are the harness and the infrastructure. Right? The harness is the file system, the context management protocols, the planning, rhythms which help you take your business logic and make it function as an agent. And then the infrastructure is just the pieces that all of this run on. Right? You need a runtime sandbox. You need to be able to connect to different channels, and you need to be able to connect to different tools and so on. Right? And so the way we think we can make this easier for our users and for our customers is that we leave the business logic to you so that you know what expertise and domain specific context you need to bring in, and we take care of the hardness and the infrastructure to... Through something that we call managed deep agents. Right? So what are managed deep agents? Put simply, managed deep agents is the simplest and the easiest way to build, deploy, and run agents in productions. This is a bit of a text heavy slide, but bear with me as I walk you through this. Right? So what do you get with Managed DeepAgents? We start with the DeepAgents harness. Right? So DeepAgents is our open source agent harness where you get planning, file system, context management, and the scaffolding that takes your business logic and runs it as an agent. Right? Managed deep agents builds on top of this to give you open ended defaults on how to deal with tool calls and memory and so on. It allows you to test and deploy with a few lines of code, which I'll show you shortly, and then Nathan will demo. It comes with prebuilt tools and connectors so that it can work with all of the different enterprise systems that you needed to work with on day one. It gives you user level memory and authentication so that it remembers your users and their preferences and uses tools the right way. Then it also gives you out of the box support for schedules, triggers, and more so that when you have an always on agent in your company and it is helping your associates with work, it can work all the time, and it can be triggered through Slack, through Teams, or through web book somewhere. And it actually does work for you rather than just, you know, think about it and put... Push off text. So, like, Managedep agents builds on top of Langht Smith to give a production agent everything that it needs. Right? So we need durable workflows, and so managed agent runs the agents on Langht's deployments. We need secure code execution, so managed agent steps into Langht's sandboxes and can easily be configured to use it with a few lines of code. Your agent needs memory and skills, and so manage your agents, tap center context hub on landscape where you can store your instructions, version them, have user specific memory folders, and so on. You need triggers and schedules so that the agent runs when you need it to and does work without you having to oversee it all the time. And this gets handled by managed Deep Agent, so by, you know, defaults on top of the Deep Agent's harness. And then we have connectors and authentication. We give prebuilt tools out of the box, which lets you connect to a variety of tools and to authenticate as the agent and as the user. We also support channels. We have support for Slack, and we have other channels coming up soon. And finally, emails and observability, which LangSmith is known for and comes out of the box with every managed agent when you deploy it to LangSmith so that you can keep monitoring and iterating on your agent so that it keeps improving over time. Right? So let's talk about how you start with managed agents. Right? You take your agent, you take all of your business logic that you want, and then you structure your agent as a directory. Right? So you start with an agent dot py or TypeScript file, which talks about what the agent is and its configuration. You have an instructions file, which is just a dot MD file. You can set up folders for skills, tools, channels, schedules, sandbox, and sandbox so that you can set it up within Lacksmith. It's just a couple of lines of configuration or depending on what custom tools you want to use. You can bring in that code and have it stored in tools and skills and so on. And then we have a file... Python or TypeScript file for identity mapping, where with a couple of lines, you can set up how you want the agent to handle identify... Identity and authentication as well as user memory. Right? And then how do you actually go from this directory to a working agent in production? Right? So you start or you go through three commands. Right? You do mda init, which scaffolds the product and sets you up to build your agent locally. And then you do m d a dev so that you can test with the CLI or lang graph studio, which comes prepackaged. And then you do m d a deploy, which builds and ships it to your Lang Smith deployment. Right? And then when you do m d a... When you run m d a deploy, what happens is that, the Locksmith deployments, context hub, sandboxes, and a tracing project are all automatically deployed and set up and tagged to your agent so that your action agent is actually live in production. Right? So three simple commands, and you have an agent running in production. Right? And so with this, I'm gonna hand over to Nathan to walk you through a demo of two agents that he's built on top of, managed deep agents and how to use them. Alright. I'm gonna give you the screen, Nathan. Alright. Let me just screen share. Here we go. Sweet. Alright. Thanks for the intro, Karthik. So, yeah, the the core thesis with manage agents is making it really easy to build an agent and then deploy it within your organization. And so we're focused on making it very straightforward to construct an agent, as Kartik was saying, to design that business logic in a human readable way, and then to distribute that in the places that you're already working, like Slack, for example. So let's take a look at some example agents that we have seen that are very common use cases for some folks that are building with MDAs today. So the first one I wanna look at is an on call agent. So an on call agent, in this example, it's going to need the ability to take a look at the data from our online services and analyze that data and understand if there's an issue with that data. And it also has the ability to send a page to the right person if an issue needs to be escalated. So we need an agent that can investigate the data. It can pull in data from external sources. It can analyze that data to understand what it needs to do with it and whether it needs to escalate it, and then it needs the ability to actually send out the page. So there's a couple of custom tools that we need to give the agent to do this, and we also need to make sure that the agent can do this continuously. So for an agent like this, it's definitely useful for me to be able to ask it for triage and to learn what it's doing and to to see what the current status of our systems are, but we also wanna be able to have this agent automate itself. So the agent can execute commands on its own time or it can review the traces continuously even and properly escalate, maybe at any time of day. So in this situation, we have a couple of services, and two of them need human action. So when an agent takes a look at our historical traces, we'll expect it to, escalate for the checkout API and the webhook dispatcher, but maybe not for the search indexer, which had an incident. Maybe we need to look into it, but it doesn't need to escalate. So to build this agent, we'll... This is a sample conversation, and this agent is one that we'll distribute in Slack. We'll have the on call agent for the Thornberry organization inside of the Slack organization. You can ask this agent in Slack. I think that happened last night. The agent can run a query to the metrics database or to a live database. For example, if you're sending data to Datadog or something like this, you could build in that connection dynamically, run the query that... To pull in the data that it needs, bring that back and analyze it as part of the agent runtime, and then construct a response for me, the human, to read and understand what's happened. And from there, I can decide to take an action, like, hey. Estimate this. Page the engineers that are on call in order to, investigate this issue and resolve it. And when it does that, then... Or when I when I perform that action, then we'll send out the, page itself with the page engineer tool. So let's take a look at how this works in practice. So this is our on call agent, and this agent was built with MDA in it. And what we're looking at is an agent that's already constructed, so I won't be building it from scratch here. But we can take a look at what I put into this agent to give it those behaviors. The most important piece of this agent is our instructions file. So this is the instructions file. You're... You help the on call team at Thornbury, a software company. People ask you about the systems you... We run, and you answer in the channel. We give some explanation of the data that it has access to. In this case, it's a mock database. But if you have tools that are wrapping external data sources, then you might wanna describe those in your instructions file. We also wanna give it some information about the ways it should use that data. And this is really helpful to give the agent the ability to analyze using your business logic because different agents at different organizations or even different agents at the same organization may perform in different ways. You may have multiple on call agents that have different instructions depending on the services they're expected to monitor. So in this case, we have a pretty simple definition of an alert. We want to make sure that even if something is red, that doesn't mean we need to page someone to run an escalation. Sometimes it may have gone green again, so we'll look at the full dataset. I'll give you some information on how to run a page. These are the tools that I've written for this agent. We've got a page engineer tool. We've gotta forget pages in this case because it's a demo, so I wanna be able to reset. And then we also have some schedulers, which I'll dig into a minute, so we'll we'll come back to that. So first things first, we can run this agent. And in this case, if you're running this locally, you can use mda dev, which is great. And we've also just introduced mda chat, which lets you interact with the agent from your command line. So if you want a terminal interface, you can do that as well. If I run m d a dev, this will open up Studio. So I have this agent deployed, so we can just chat with a deployed agent directly. And you can think of Studio, in this case, kind of like a developer environment. So I can ask it questions and experiment with the logic and make sure things work as expected. So let's try creating a new thread with our on call agent that's running in Studio, but it's actually running inside of Langhsen deployments. This is already deployed. It's ready to go. So I'll ask it the current status, and it's useful to run this inside of Studio because we can actually monitor the tool calls. So here, you can see the tool calls that it's using. It's running execute commands in order to query data from the back end. It's pulling from our SQLite database. If you built different tools, then you might see, different, actions that are performed here. And it's gonna use this to pull in the information that we have about our current or last night's services that we're running and then give me a human readable summary. And it's able to do this, and it's able to immediately query against our SQLite database because we've encoded that business logic into the instructions file. So I'll give it a second to run through the data that we have here, and here we go. So here's what it sees based on those incidents. It finds that the two services are actively down. It finds that one of them is... Was down, but now it's green. And then it used that information after reading that out, and it, ran. two additional tool calls. It actually... Can you Yeah. try turning your screen share off and on? It's a bit blurry for the audience right now. Yeah. Let's see. Yes. Is that better? better for me. Thank you. Okay. Awesome. Yeah. So it ran the tool calls, and we can see that it actually escalated and used the page engineer tool call. So it... Based on the information that it pulled from the database, it was able to escalate that. It decided that there were two, services that we need to escalate to check that API and the webhook dispatcher, and then it ran the page call on those as well. So that's great. This is what we were expecting. And if I wanna add this agent to Slack, if I was running it locally or I was running it in development, then I would have this just set up and I can access it in studio and I can access it in studio, but I really wanna distribute this across my organization. So to do this, if you've never set up a Slack channel before, then you'll just do channels in it or MDA channels in it. Slack. And in this case, if I run this, it won't actually do anything because I already have a Slack channel configured. But what this will do is it'll create the Slack channel definition, which is just slack.pie. And here we instantiate the channel. We've given this a name, a description. We've given it some reaction logic so it can acknowledge messages that it receives, and I've actually created an icon for this agent as well. And when I deploy this agent into Slack or when I next run MDA deploy, then it'll automatically run a Slack integration. So the agent will become available in Slack through a couple of clicks. You don't need to create a Slack bot. You don't need to instantiate any systems. And if I tag the agent in Slack here, after I've run that deployment, then the agent can interact with anyone in my Slack, if it's been added to a channel or if a user sends it a DM. So this is a really great way to distribute your agents. We wanna make sure that's, again, straightforward to bring them to where people are already working. So this channel's integration is key. Once an agent is deployed, it's configured to be able to distribute this out to your team. And while this is running, we can actually take a look at the usage of this agent in our tracing tab over here. So because this agent was deployed, we look not at local, but at production. We can see all the traces that have happened for this agent. So we can see the trace that we ran in LangSmith Studio, but we can also see the trace that happened in Slack just now when I asked it a question. We can see the set of tool calls that happened. We can see the performance of the agent. We can see the response time. And you can see here, this is a thirty second response, which isn't that great. So I might wanna take some optimizations there. Now it it found that the checkout API was down. And because my tools expose a log history of who was paged, it actually also can see that the right person was paged here. So that's an on call agent. It's really useful because it both reads and writes, and it can escalate to a user if we need that done as well. So the next agent that I wanna show everyone is Current Ops, and this one, I'm honestly partial to. This is a bike share agent. So we imagine this bike share company called Current, and this is an internal agent that will be used to manage station traffic and actually dispatch vans out to the stations in order to move bikes around. As we know, bike share flow is, is variable if you're in a city that has a bike share. So some places, usually downhill, are going to be sinks and others are going to be sources where the bikes are going to originate from. So we need to send vans back and forth to move bikes from the full stations to the empty stations to make sure that our commuters can get to work. So in this example, we have a couple of made up stations. Some of them are out of bikes, some ran out, but naturally filled up again, maybe as it was used over the course of the morning and then people came in the other direction, something like this. We have this auto refill or, like, refill by the nature of the system. And the agent we want is going to be somewhat similar to our, on call agent. In this case, we have an ops lead who is gonna ask the agent, where do we dispatch our vans to? So the agent needs to be able to query the trip data, which may come from a private database or a user authenticated database, and you can't authenticate on behalf of users with managed deep agents. Pull that data in, analyze the, sinks and the sources of our different stations, and then give me the information. And if it sees that it thinks it should dispatch a van, in this case, I've added human in the loop. So the human needs to approve the van dispatch before it actually is sent out. So I tap approve, then VAN one and two get their runs. So let's look at how this agent works in practice. Again, the business logic is encoded in our instructions file. You help the morning shift at current. It needs to look at the data from the database. You can query it with SQL like commands in this case. Again, if you're interacting with a custom DB, this might mean you write tools around that database in order to interact with it. We're also encoding the business logic of how to analyze that data and determine where Vans go in plain English, which is great, because we can help the agent, interpret what these things and sources are and make recommendations dynamically with this instructions file. So again, the business logic is encoded in the agent behavior. And as the developer, I wanna focus closely on how this business logic works rather than worrying about the harness or long running tasks or restarts if something crashes, things like this. So, again, this agent, I've already deployed it. And you can see here, we have our send vans system or send vans tool calls, which are defined here in our tools. We've added this one to Slack already with a custom icon, and we're ready to go. So I'll try adding... Asking this one in Slack directly. Current ops, what's the current status? And I'll ask you a similar prompt question as we saw before. And when I ask you this question, like we saw in that diagram, it's going to query the data, pull it out, get it back, and see information about our bike share, propose a response, and send this back to us. While it does this... Oh, here we go. It's ready. Okay. So two stations are empty. Harborside Ferry is down. The rest network looks fine. Want me to check the van availability and froze runs? Yes. And while it analyzes this, I'm gonna actually set up our on call agent just to run some regular queries. So we want the on call agent, to actually not just check the status when I manually ask it a question, but to also check the status automatically with scheduled runs. So I can ask it that while our current ops runs. And our on call agent is going to be able to do this because we have a new schedules SDK, which lets me provide tools to the agents that I've built so that it can create, view, and delete schedules and automatically execute agent runs. So you can add an agent run-in your project definition, or you can add dynamic tools so the agent can create and manage runs when users message it, which is really powerful. So this activates whole new use cases. We see a ton of runs that are powered by scheduled runs because the agent is going to automatically pull in the data. It can escalate things or run pages if it needs to in this case or more sophisticated tasks. So our current ops is ready. We have two VAN approvals, and in this case, this has a human in the loop interface. And the way this works is we're constructing a, UI here with an interrupt. So when we try to use the send VANs tool, it's going to send this UI where the user actually needs to, approve or decline. As a developer, all I had to do was write the approve and decline buttons and the descriptions the agent uses. So this is actually defined as a tool as well. And this is in our send VANS file. I click approve, this will resume the agent run. And even if I click approve an hour or two hours later, hopefully, in this case, I'm not doing that, it will still continue to resume the run right where we left off. Meanwhile, our on call agent is ready to go. Every fifteen minutes, it's gonna check for failing results, and this is using these schedule tools that we provided, recurring schedules, one off schedules, or schedule lists that all use the schedules API for managed agents. So for the sake of time, I'll wrap it up, but that's a quick demo of a couple of different agents that we're seeing people use. There's a lot more ways that you can build with managed agents. These are just some of the examples, purchasing agents that use Stripe, per repo, coding agents that are different on different repositories or different tools, competitive research agents, policy desks, spreadsheet analyzers, etcetera. There's There's a ton of powerful ways you can use this system. Alright. So we'll open up to questions. Karthik, did you see any come up in the chat that you. want to. raise? Thank you, Suresh. And that was a cool demo. The reactions always get me excited. Alright. So there's a couple of questions. Let's start with this one. So a user, Raghunath, is asking, he has a very basic question. How do multi agents and managed deep agents differ? I think the question here is when you have, like, teams of multiple agents and sub agents, is it different from managed deep agents? Manage of agents actually does support sub agents, as part of it. You can define sub agents within, your managed agent agent definition. So in this example, we have our agent file, and here I can actually define sub agents underneath, my agent, which it can invoke. And we're working on, more tooling to make this easier. So for example, asynchronous sub agents that can run while parent agent, is working on something else. So there's more on this to come, but you can create many agents that are orchestrated by a single managed deep agent today. Perfect. So another question has popped up. Michael is asking, does deep agents or manage deep agents support using, neural models like Jeff? I know the answer, but I'm... You said. Yes. I... Yes. Absolutely. I I think it really depends on your use case. One of the features that, we are excited about with decision models and managing agents, or I am personally, and I think we've seen some excitement as well, is picking reactions, for example. It's it's very simple, but, you can use Jev, for example, to provide it a list of Slack reactions, and then Jev can pick one based on the message context that it will use to react to the message, which can help. You wouldn't use a decision model to produce responses, but you could integrate it inside of your tools or inside of the deeper logic of the agent. We have some really nice, systems inside of the Lang chain developer toolkit if you're trying to do this. And, of course, you can also add JEV to the LangSmithLM gateway so that you can route all of your requests requests centrally, and you can reuse the same system across many agents so you're not, spreading API keys willy. knowing. Perfect. We have another question. Hans is asking, do we support multi user setup? What he means is... Or, what they mean is, is there a pair of memory for user level memory and user level tool access? Is it supported is the question. Yes. Absolutely. And multiplayer is really important for us. So, this is kind of in the Slack example. I didn't really have time to demo it, but I could add in Karthik to this, and, Karthik could jump in to this channel and start messaging the agents that it sees... That Karthik sees here. And so this multiplayer is... It goes down into the agent architecture. If you're using memory, depending on who makes a request to the agent, yeah. So here goes Karthik, and I could even jump into the thread that Karthik started and ask the agent different questions. We could also add logic in our tools that say that certain users are allowed to run the approval flows if we have a human in the loop. And if you're using memory, which was the kind of the original question, we actually have systems for both agent memory, which is shared across all users, and user memory, which is stored on a per user basis. So if Karthik tells the agent, I'm not sure if I've set up memory for these agents with user memory, but if Kartik tells the agent, remember my favorite color is blue or remember that I work at this bike station, for example, I can remember that for Kartik, if I ask the agent what Kartik station is, it actually can't answer that because it's using user principles in order to identify which memory needs to be attached at which time. So here's the status, and I can jump into this. thread. And as a a little plug, we use a lot of, managed deep agents within blockchain, and we have a design agent where we have, like, hundreds of folks coming in and working together to create content. We have a session next week about that, actually. So if you go into the events page, you can check that out as well. Right? We're... Okay. One more question. Does the deep agent support user impersonation when the agent is executing an external tool on behalf of a user? I think the question is when we have tools, can the agent use as the user versus the agent itself? This is such a good question. We have a toolkit called Connections, which, unfortunately, I didn't have time to demo today, but Connections allows you to determine how the agent authenticates. And it's a powerful system that lets you use either agent identity, where you can have a single identity that the agent uses, or on behalf of identities. So if a user asks the agent a question, that agent is connected to an external service, it'll actually perform a OAuth handshake with the external service, on behalf of the user who asked the question. So if Karthik asks the agent a question, that agent tries to connect to Notion, it will send an approval flow back to Slack wherever the agent is deployed. Kartik has to run through the authentication flow, send it back, and the agent can perform actions on behalf of Kartik. Now if I ask the agent the same question about Notion, it will use my authentication flow. So if it doesn't... If it hasn't already run that for me, then it will run it from scratch. So I cannot use Karthik's, authentic identity in order to perform actions if you're using the connection system. So it's really powerful, it's super flexible, and in some cases, it kinda depends on the agent use case. We see people both using agent identities and on behalf of identities, and sometimes both for different services inside of the same agent. I definitely recommend checking out connections if it's something that you want to learn more about it. We have some great resources in our documentation. there. I I really love how you implemented that. I definitely want the agent to act as me, but I don't want you to ask them to act as me, which can get into some messy situation. Yeah. Alright. In the interest of time, I'm gonna bundle a couple of questions that have come up. So the question is roughly, how is LangSmith being used when you build on managed agents, and where can we run managed agents today? Yeah. You wanna answer that, Nathan? Yep. Sure. Yeah. Managee patients is designed to run on lines with deployments. It's really tightly integrated with the system, and this is on purpose because we wanna make sure that the experience is essentially turnkey. So when you start with a managed deep agent, we have deployment sorted, checkpointing is sorted, memory systems are stored in context hub, which is part of Langhtsmith. Your tracing is configured and executed automatically. So it's really well integrated with the system, and that's by design. Manage Deep Agents is really intended to take the best parts of the Langhtsmith ecosystem, which we think are all parts of the Langhitz ecosystem, and bring them into one place. So you create an agent within it, you deploy the agent with deploy, get it your instructions file, you add some custom tools, and then it's immediately distributed in Slack. It's traced. It's scalable. It's really easy to scale up and down if you need to. So all that power is really enabled because the system is integrated with Langhitz deployments and the Langhitz platform in general. Awesome. Thanks. Thank you so much, Nathan. So... Yes. So it it it runs on locksmith deployment, uses deployments, sandbox, and our tracing capabilities. And today, we support running it on public cloud, but we will provide support, down the line for other modes of deployment. With us, I think. we can start wrapping up. We're a little bit over time. Thanks for all of the questions. Keep bringing in the questions. You can reach out to Nathan or myself through LinkedIn or our emails. It's just my name at langchen dot dev. We do have a couple of interesting events that's coming up where you can learn how to build on top of managed deep agents. There's one on agent events coming up in, next week. There's also one on how to build a design agent, which I just spoke about earlier, which is on top of managed deep agents. And then we had a workshop earlier that is on demand out on our website. There's also a number of resources that you can use. We have, docs. We have tutorials, and we have a number of videos on how to use these... Each of these features. We will be sharing out these links later, so you don't have to worry about noting them down now. But, thank you so much for joining us today. Thank you for all of your questions. These are great questions. If you have more questions, reach out to us on LinkedIn. We'll always be happy. Nathan's also super active on Twitter. You can find him on Twitter and talk to him there as well. But, yeah, we are very, very interested in seeing what you build on top of financial agents. Thanks. Thanks, John. Yeah. And like I said at the beginning, we love seeing your use cases. Keep sharing them. And like Karthik said, I... I'd love to chat with folks who are curious to learn. more. So reach out to me on LinkedIn, Twitter, wherever you prefer, and, yeah, love to learn what you're building. Thanks, everyone. Thank you so much.