Deep Agents Explained

Nice to meet everyone. I am, as Jake mentioned, core maintainer of our open source tooling at LinkChain. So I've worked on everything from LinkChain to LingGraph, and now most of my time is spent on deep agents. I kind of have a history in open source. I spent about a year and a half maintaining Pydantic and then kind of helped start Pydantic AI. So I'm very passionate about kind of the open source for AI space. Awesome. Awesome. Thank you. I'm Jake. I'm a deployed engineer, which means that I work with a variety of teams of all different shapes and sizes who are either building agents or thinking about building agents. I've seen teams use a variety of different frameworks in their approach to building agents, and I've seen teams roll their own custom implementation or use their own custom solution. What's really interesting is that typical agents excel and are actually pretty good at the regular tool calling loop. that can handle relatively simple tasks. Where it gets challenging, though, is when agents are kicked off to do longer-running tasks. Maybe they're doing research across a variety of different topic areas. Maybe they're writing to files. Maybe they are doing some kind of delegated planning and having sub-agents. That becomes tricky, and that's the problem that deep agents and other agent harnesses that we'll touch on today aim to solve. So, without further ado, Sydney, how would you describe Deep Agents in a sentence? What is Deep Agents? Yeah, so Deep Agents is a batteries-included harness for building agents that excel at complex and long-running tasks. That's my sentence. There we go. It's a good sentence. Harness. You mentioned harness. Let's kind of touch on that. I think that if you're across X, if you're reading about different developer forums, you'll hear the word harness a lot. What do we actually mean when we say harness? Harness is sort of the surrounding support that we add onto that core model and tool culling loop. So we're all very familiar with like you have a model and some tools relevant to your context and then you send the model some prompt and it runs in a loop until it decides it's done and then produces some final output. But there's actually a lot of kind of complex engineering that you need to have built into all of the stages of that loop. And so the agent harness is kind of all of those pieces added in. Okay, yeah. yeah that makes sense and and given that's what deep agents is what kind of agent apps or what kind of applications do you see as the most common or the most applicable for deep agents yeah perhaps the one that folks are the most intimately familiar with in this space is coding agents so an agent like quad code we would consider a deep agent because it's doing you know those longer running jobs It needs lots of context and to kind of be able to manage that context over a long horizon. Deep research is another common use case. So specifically answering questions or solving problems where you need access to tons of different data sources. And, you know, you expect those research operations to take a long time. Okay. Yeah. Yeah. Yeah. That makes sense. And if we're sort of thinking about the way that deep agents are different to traditional agents, right? I think that... um you know around around 2023 the whole react agent paper came out which is reasoning and action agents agents having access to tools how did like what are the components that make up deep agents i know there's you know there's there's things like file systems and things what are the main areas that make a deep agent or or that agent harness different or an extension of the react framework that we're all so familiar with yeah so i'm going to touch on like kind of a couple of the pieces of the harness you're probably like sydney what what are you inserting around that model and tool calling loop that's very abstract and then i think we'll dive into a lot of these pieces in more depth so the first thing again you're probably familiar with this if you're a like cloud code user is a planning tool just like humans are better at executing tasks if they like write down what they're going to do and then check things off as they go agents are also better at executing complex things if they keep track of the work they're doing so planning tools number one Sub-agents are super helpful. So if you have a lot of work to do, it's super helpful if you have assistants that can go off and do work for you and then come back with some report. So sub-agents is number two. Perhaps the one that I'm most excited to talk about is access to a file system or kind of more abstract, a back-end where that agent can keep track of files, memories, skills. These are a lot of like buzzwords, but just sort of the core abstraction used to keep track of all the context. And that kind of includes sandboxes as well. And then, yeah, so that's kind of some of the core pieces. One last thing I'll mention is we keep saying long horizon tasks, right? And one thing that's really hard to get right with agents is summarization. So models have context windows. They are getting longer and larger and larger. we're pushing agents to do tasks that always like hit that limit right and so you want some sort of like built-in summarization that happens so that you never actually hit that limit you like work on your task until maybe 80 of your window is taken up and then you like squish back down and then you can keep doing work so those are some of the core things built into the harness okay awesome yeah so so to reiterate a planning tool subagents a file system uh the execution environment so sandboxes am i missing anything and some summarization three or sorry four key areas that i think sort of is is really interesting to dive into in a little bit more depth today so let's sort of start with file systems what make file systems a really powerful feature or element of building and working with deep agents i know that you know uh when i'm using clawed code or when i'm using cursor agents they're accessing my code base which is a file system so sort of What does it mean to have a file system in deep agents? And what are some common file systems that people might use? What does that look like? Yeah, great question. So I'll start with kind of the example of a local file system that we're all familiar with. Maybe not something you would use in production, but great for just general development. File systems are kind of the key to context engineering. It's where you can offload. information that you don't want to squeeze into the prompt all at once but you do want generally accessible to the model in my mind the file system is basically where you can practice what we call like progressive disclosure and so you give the model enough information about what's in the file system that it can access relevant files when it needs to but you're not overloading the context window and the relevant information can take a lot of forms right like sometimes that's prompts in the form of skills sometimes that's documents that have memories sometimes it's your like relevant data for your context okay got it and and so you mentioned that was for local a local file system is is one that's quite popular what if i'm now sort of starting to think about how i can productionize and and build deep agents that have access to to something that is that is more than something that locally lives on my machine i'm sure that you know speaking about this today will hopefully sort of catalyze a lot of people to go and see how they can build this and the different types of applications that they can build so obviously i'll start locally but where will i go from there and sort of what is the file system what does the file system landscape look like when i want to move beyond local development Yeah, so we talk about file systems because that's an abstraction that's pretty easy for an agent to understand and interact with, like you can read and write files, etc. But really what we're talking about is kind of abstract backends. And so where is your agent going to go to find the vast sources of data that are relevant to your application? That's probably databases, right? Like surely you have important information there. I personally have a lot of helpful information in Notion, for example, or in GitHub. You can imagine all of these data sources that you want your agent to be able to interact with like their file systems. Yeah, yeah, yeah. That makes sense. In terms of some of the work that I've done as a deployed engineer working with teams who actually use file systems, I've seen that people will use them, for example, to offload large tool calls and things like that. So if I'm sort of thinking about building an agent, things that are familiar to me if I build traditional agents are agents that can call tools. How does a file system, like why would I use a file system to store large tool calls and sort of like why is it helpful for me in that instance? Yeah, so we're definitely getting back to the idea of like context overflow here. if you're calling tools that return extremely large results maybe you're doing data analysis and you're getting huge files or just you know getting multimodal results that are incredibly large those are going to start to fill up your context window quite quickly and it's probably not necessary that your agent has access to those that information in its main prompt all the time and so the file system is a great place to like offload tons of data and then point the agent to it in the case that it needs that information. And the one last thing I'll say is this is all sort of in our attempt to optimize what context you're sending to the model so that it can perform and do its best. And so tool input and output offloading is one of the strategies we use so that we don't have to summarize as often. Because when you summarize, you inherently lose information. The agent is more likely to lose track of its main goal, etc. And so those are kind of intermediate steps we can take to reduce context size. Got it. Got it. So in summary, we're not storing things in the context of an agent anymore. We're storing a reference to where that context lives and exists in the file system. And I think that's sort of the key unlock there is that I can now maintain and have reference to all of this information, but not have it clutter the context window, not have my LLM calls be slower because there's large context. Would you sort of agree that that's one of those core benefits there? Yeah, definitely. I think I really like making the analogy that agents are like humans, right? Like I already mentioned, they use a planning tool to keep track of their various tasks. And I think similar to humans, if you send a ton of information all at once, they're more likely to get overwhelmed and have trouble. So if you can kind of control what you're sending there, just like humans, they do a better job. Got it. Got it. And just Deep Agents give me flexibility with file systems and sort of like, yeah, I guess like I have access to a variety of different options, I presume. Yeah, yeah, it's super flexible. So we have a couple of built-in ones, local file systems. We also, Deep Agents runs on Langraph, which is our core agent runtime, which has kind of short-term and long-term memory stores that are built-in and accessible as well. But then we also have kind of a generic backend protocol so that you can add in your own backends and file systems, whatever those may be. Like I mentioned, Notion, GitHub, databases, et cetera. And I think the coolest thing is that we offer a like composite backend option. So maybe your, you know, documentation is in Notion and your customer information is in some other source. And so you can like combine those in a singular backend. Awesome. Awesome. Hey, and so what are skills and why do I keep hearing about them on X? Yeah, it's a great question. So skills are just prompts. They're fancy prompts, but they're really easy to share and they can help agents, you know, really narrow in and do a certain task well. And so I use the like progressive disclosure buzzword earlier. And all that that means is like you give the agent a little bit of information like, hey, you have access to this like right PowerPoint skill. and this code review skill like if you decide that you need them you can go load them from this location and so then i you know i'm like oh no i'm late for my meeting can you help me generate this powerpoint with these docs and then it'll go and load in that skill into the prompt and so you're not kind of cluttering your prompt with this like you know hundreds and hundreds of lines of like powerpoint specific information but when you need it you can load it in got it got it got it Can I get a show of hands of people who use skills or at least are familiar with skills in the audience? Yeah, I mean, wow, look, we've got a pro crowd here. I think that skills are really interesting. And I think that the real unlock is that skills, as you mentioned, it's an extension of a prompt. And skills are becoming very shareable. Talk a little bit about why I would want to share a skill and what unlock that allows me to do when it comes to building agents. you know, we've all probably read and seen about OpenClaw and ClaudeBod and there's, I think Claude or OpenClaw has like a skill hub. Like what's the idea of sharing these and what does that allow my agents to do? Yeah, great question. So I think we've seen skills blow up in a way similar to like MCP blowing up, right? Because it's like, oh my gosh, we have this standard that makes it easier for our agents to like be more capable. And so like, let me just share this folder with my co-worker that's helped me like improve my code quality right um or improve my um i don't know security of my code or just anything like that and so um sharing skills are just like ways to make yourself more productive make your agents more productive um and because it's standardized it's yeah i think i think very very popular yeah yeah i know that that makes a lot of sense thanks for kind of diving into that so Earlier we mentioned sandboxes and sort of execution environment again You know if I if I talk about X I see that a lot of people are now talking about where the execution of their agent exists and I think that you know you have companies like like modal like Daytona you have these companies aiming to make it easy to access a sandbox and I think that as agents become more powerful people are leaning on them to do more things and so you know the natural next step is well Now, if it's going to do more, then I at least want to be sure about the execution environment, and I want to make sure that this is executing in a way that I have control over. We spoke about OpenClaw. That's great, but I'm likely not going to release that on my enterprise data. That's why people have it in a Mac Mini. That's why people isolate where it executes. So what role do you think the execution environment plays in the rise of these more powerful agents? How can you work with an execution environment with deep agents? Yeah, great question. So I'm going to give a little bit of preface here. So all of us developers are very intimately familiar with how powerful and transformative agents can be, right? Like agents help us write code at rates that we could not have imagined maybe even a year ago. And so we know that coding agents are really powerful. But I think... like agentic ai has yet to have quite the same impact on other industries but i think the like avenue into that is not coding agents but agents that write code and sandboxes are the key to that and the reason is if you can write code to automate work you can do really powerful things so code is super helpful for like data analysis and research and that is like you know invaluable across industries and so if you can ask your agent to you know go look at your database and analyze things it's going to do a much better job of that if it can like write scripts and use those to analyze the data and generate figures and things like that and so i think we're going to start to see this emergence of agents that rely a little bit less on tool calling and a little bit more on executing code in sandboxes or repls executing code in sandboxes and repls yeah that's really interesting and and for context guys uh i'm working with a variety of different companies who are now thinking about this they're now building data analysis agents that are executing sql but you want some safe place to do that sql execution right and and so uh i i think it's really interesting and i i think that it's also really interesting when you sort of look at things through the lens of everything can sort of be solved by code or rather like you can break a problem down into a way that is resolvable by code right like That's sort of the beauty and the power of having like exec tools and things like that where you can use Bash and Grep and all of these tools that we see Claude Code and things like that use. So that definitely makes sense. And so you mentioned that it's very easy to work with sandboxes, with deep agents. Why is it important to have flexibility in the control of... where things execute and sort of like what does that interface look like if i'm working with the deep agents package yeah that's a great question so sort of the name of the game for us is flexibility right like when blank chain was released long ago one of its kind of core pillars and still to this day one of our core values is that we produce like model and provider agnostic solutions for folks the reason for that is that the space is moving incredibly quickly and so the model that is right for the job you know today is maybe not the model that's right for the job next week um and i think the same is true you know with sandbox providers we mentioned we have all these integrations um and yeah our foundations are in kind of open source and open provider and so we are still kind of advancing that with deep agents and so you you know users basically get the benefit and certainty that they can you know not experience that like vendor lock-in and try out the latest and greatest without having to deal with changing code on their side. Yeah, that makes a ton of sense. And so we've sort of given an overview of what deep agents are. We've spoken about file systems. We have spoken about skills. We've spoken about the execution environment. If I'm now someone who is building and developing a deep agent locally, I'm writing it in code, what's the next step for me? First of all, what are the challenges when it actually comes to deploying an agent? What does it mean to deploy an agent, and what are the challenges there? Yeah, so if you're deploying an agent, things are getting real, right? Your agent is going to do things, make an impact. And despite the value in fully autonomous agents, you might want a little bit of human oversight or human loop before really sensitive actions are taken. Maybe you're working on an email assistant and you want to give a final stamp of approval before you're sending your email to your boss. Maybe you're working on a travel assistant agent and you want users to be able to click an approval button before it charges their credit card, things like that. So first class human in the loop support is kind of the first thing that comes to mind. The next thing is like durable execution. So you want to be able to kind of observe all of the steps that this agent is taking. and roll back to previous steps and try things again with different inputs and know that all of those steps are documented, et cetera. Got it. And also as well, we spoke about agents being long running. Is the infrastructure different for that? And presumably as well, these tasks are now running for extended periods of time. What does that also mean for the deployment story? Yeah, great question. One of the important things that comes with long running agents is that you probably want your end user to not experience like really horrible latency. And so we in our underlying runtime, which is lane graph, as I mentioned, treat streaming as a first class primitive. So you can see like live updates and, you know, be able to interrupt and intervene and kind of redirect your agent, et cetera. But I think also one of the challenges with long running agents is you're going to have like really hard to debug and understand traces. Yeah, that might get into our next subject a little bit. Maybe I'm jumping the gun here. No, no, no, it's perfect. It's perfect. That's actually where I want to go. Because obviously there's a variety of different steps involved when having an agent that you want to deploy to production, right? Now you've taken the leap and you've made it available to different users and it's being consumed, right? Now you're on the hook for the way that that responds. you are responsible for making sure that it delivers high quality solutions to wherever you are applying it. Talk to me about some of the challenges in observing and evaluating deep agents. We've spoke about them being quite complex. Does that introduce complexity? Yeah, so I think if you looked at kind of tracing and observability for agents that you were building months ago before deep agents were really popular you would maybe see like your input and a couple of tool calls um and then some final result and it's pretty easy to reason about like three five ten tool calls but as soon as you're veering into the space of like hundreds of tool calls minutes of um processing etc you start to need support in like understanding what's going wrong if your agent isn't on track and kind of aggregating you know across runs like what are the um what are the trends with my agent what prompts help it do well what's like you know when is it failing are there like failures that i can predict or things like actually going wrong in my code etc and that's like really hard to uh reason about if you have traces that are that long and and so naturally i'm using length change deep agents i'm i've probably heard of langsmith so i'm going to use langsmith what are some of the parts of langsmith that make it easier to to sort of address those challenges address those really long-running traces understand different usage patterns how does what kind of tools do i have there yeah i think the the thing that i'm most excited about is um we're building ai insights into our observability platform um and so you can use our our ai assistant which is like you know the little button in the bottom right hand corner now um to ask questions about your traces and ask questions not only about like a single trace or thread a thread is kind of like a conversation but also view like aggregate statistics about failures etc across across runs that makes sense that makes sense making me want to try it so we're sort of coming to the end of this of this uh this part of the the evening you and i you and i discussing then we're going to open the floor up for some q a but before we wrap up if a team wanted to try Deep Agents today and sort of they're setting out their missions of achieving as much as they can in the first month. What are some quick unlocks or like what are some quick things they can do to really begin to see the value of using Deep Agents? Yeah, great question. So the first one is easy, which is like write a really good prompt. So the whole point of Deep Agents is to make agent building easy for users. And so the idea is you as a developer can just write a prompt that's really specific to your use case. And it should perform well. So put the complexity of the prompt is I would say our number one recommendation Deep agents makes it really easy to get started with like five lines of code You know you define your prompt and tools and like you're you're off to the races. The second thing I would say is and this is also Something you can do in LinkSmith is you're going to want to kind of quantitatively Evaluate how well your agent is doing and that's going to help you kind of build this like self-improving feedback cycle. And so you'll want to set up evals for like, yeah, evaluating your agent. And I think the earlier you commit to that, the better your agent's going to be. Awesome. So regular prompts set up in Langsmith and deep agent CLI as well, right? Yeah, yeah. So we have sort of an adjacent to quad code implementation. The DeepAgent CLI is fully powered by our DeepAgent SDK, but some niceties that come with that, you can use any model, and it's automatically connected to Langsmith tracing. So if you kind of want to understand more of the nuances there, you can see your Langsmith traces. Nice. That's one thing that I also think is really interesting is, and we sort of mentioned it as well, and this is what I've seen working with a variety of different teams. If I want to do something that is image-related or video-related, I'm probably going to go and use a model by Gemini. If I want to use or build an agent that can execute SQL and generate code, then I'm probably going to go with some Claude or some anthropic model. I personally think that OpenAI's models are really good at writing. And so I like 5.2 for expressive things and writing. And so if I'm doing something that's kind of like responding to customers maybe or is something that's more conversational, Maybe I use a model by OpenAI. And so that, I think, is another thing. I think we've touched on it, but it's definitely a power and an unlock that you get when using something or when using a harness that is sort of model agnostic. And so finally, what are you most excited to ship next, working in our open source team, working as a core contributor to the DeepAgents package? Yeah, great question. We've got an exciting queue coming up for March. So we talked a lot about sandboxes, kind of a lighter weight version of a sandbox is a REPL. So it's not like a full execution environment. It's really like code focused. And so we're working on a REPL tool. I'm excited about that. We're also working on, actually, there's a version of this in Deep Agents Now that you can opt into, an auto compaction tool. And that sounds pretty complicated. Why are you bringing that up, Sydney? It sounds like you already built in summarization. But I think Lance wrote a blog post about this called Learning the Bitter Lesson, which is the more power you give to the model, the better it's going to do. We're giving the model code writing and execution capabilities. We're giving the model basically everything. We're experimenting with giving it the power to control when it summarizes things and trying to evaluate if that is better than our kind of deterministic, like, okay, you're at 85%, like, now let's compact. But that being said, we're kind of very researchy with the harness still, which is pretty exciting. Yeah, yeah. I agree. I agree. Well, thank you so much for answering those questions. I want to open up some questions to the floor. If there's anyone that has any questions about anything that Sydney has mentioned tonight, then please feel free. I can come and find you, give you the microphone. Hi. How do you write a good prompt? What are the lessons learned there on how to optimally a prompt engineer? That's a great question. So I think... part of the like my two things were like write a good prompt and then set up evals and I think those really go hand in hand and I think you know experimenting with like here's ten different versions of this prompt like and I'm gonna run this agent a bunch like how is it doing across all those runs is really important and so I think if you don't have evals it's kind of hard to really convince yourself that you're that your prompt is as good as you want it to be. But that being said, in like a rapid development cycle, you can kind of figure out like, okay, my agent is really not doing what I want it to do. And there's like great, I think my favorite like prompting tip is just like keep it really organized and give, you know, good examples and bad examples. And what's my last prompting tip? I would say also like as a developer, don't forget about your tools because the tool like descriptions also go into the prompt. So even though that information is often like in code and doc strings or arg types or, you know, um, things like that, like don't, uh, don't forget about the tools because those are like, you know, how your agent takes action. And if it doesn't know how to call them, well, then it's not going to do a good job. So I have a question maybe for both of you. I want to know if you've seen any cases we are like nations using. divisions with reparations of agents. So we have been testing this approach for data-heavy tasks and it's like quite a mess because you have like a tree of an agent that has sub-agents that has sub-agents. But it's quite interesting. It's why any of you have seen this interaction. If you have any opinions, it's like it. So just to clarify, it's like a hierarchy of a tree of agents where you have an agent and then an agent and then that has... has planning agents. Yeah, Sydney, I'll let you take that. Yeah, so sort of two notes here. We did a bunch of work on kind of documenting and research for like multi-agent architectures and just like the super quick run through, we decided that there were four main ones we were seeing. It was like a router where you decide like who does this query belong to and then send it to the relevant agent. The sub-agent architecture, which we use. The like skills architecture, which is like you can kind of say that different. agents with different skills or like different personas um and the i'm i can't remember the fourth one maybe it was custom workflow anyways it doesn't come oh it was it was swarm i guess um but that hasn't been coming up as often anyways that being said um we went with the sub-agent architecture for um deep agents because we saw so many other powerful harnesses using that and having that be successful um so that's kind of the the history of why we're using it At some point, you're really going to struggle from a latency perspective if it's sub-agents all the way down. But that being said, we're also seeing RLMs, so recursive patterns, gain a lot of popularity right now. And that's certainly the tree pattern. So I think it's still to be determined how effective that can be. I think the answer is very effective, but very slow. I also think an interesting thing there is if you ask yourself why you have a sub-agent, it's probably to do some particular task. And if you kind of abstract that away, a model that calls a tool calls that tool because that tool helps it do the task. If you have a send email tool or a query my bank account tool, those are separate tasks. When you break that down into a powerful, like, multi-planning agent that can solve different domain areas, you might, let's say I have, like, a finance agent. One sub-agent does accounting. One other, you know, one other sub-agent does, like, accounts receivable. Another agent does, and so, and those sub-agents have access to their own tools, right? And so, like, what I think is really interesting is this idea that really, like, model calling a tool can be like that same abstraction is applied to like model has or like planner has a sub agent if that makes sense because the sub agent just has access to its own set of tools as well and so like I think there's a really interesting trade-off between how many tools can you provide to a model before it starts to lose accuracy on calling the right one because now it has to decide between a variety of different tools but the next question is okay how many sub agents can I provide to a model before it begins to become inaccurate in directing to the right sub-agent. And so you must have a really, really big problem space to have that sort of level of depth. But I think it's an interesting way to think about things, you know? Yeah. Does Langston have any plans to support multiple providers during the execution? So, I mean, many times we see that these content blocks, when it passed one provider to another provider, it breaks. But if you look at cursor, it handles very perfectly when you switch between them. the uh you know providers and the models so i mean right now litellm they're doing it so do you have any plans to support that for the deep agent yes um so in i believe it was october we released link chain v1 which was sort of our like maturity mark um for our you know core underlying agent building utilities and with that we shipped uh standard content blocks and the But we have to handle it of our whole, those blocks. So for example, like a lens doing automatic, you switch in providers. So is there any plans to score that? Yeah, so we definitely want to support like multimodal content blocks and like sending them between providers. An example with deep agents is that you might want, you know, your sub agents to specialize in like image generation, but then... you know your supervisor agent is doing something else so you're using a different provider um if you're running into like specific issues feel free to feel free to open an issue but our like standard content block should enable those um communications is that question from this side of the room i'm gonna kind of i see one down here thank you so i feel like that the whole sandboxing thing is getting oversimplified what exactly are we isolating here is that just code execution or the tool permissions or the model state or GPUs being used. And then my second question is actually, how many agents are being deployed in the production now to worry about the cost efficiency in the production action? Do you, I mean, are we there yet to worry about that or? To worry about the cost efficiency of like long running agents? Yes. Yeah. Are you seeing a lot of agents getting deployed in the production? So I think there's two parts to that question. I can answer the question about the cost of these long-running agents, and then I'll let Sydney take the one about sandboxes. Absolutely, yes, we are seeing a lot of long-running agents be deployed to production. The main cost comes from the model calls, not the actual infrastructure to host them. And actually, as well, these longer-running agents actually often make less model calls than... than short, quick-fire, chat-based agents. We're kind of talking about long-running research-based tasks and things like that. And so I think that the power that agents, or rather the scope of problems that agents can now solve and the ability to use these really powerful reasoning models is a price people are willing to pay to be able to offer something that is able to... to effectively infer over such a large range of unstructured data. And so the answer to your first question is yes, or rather no, I don't see people being blocked by the cost there. I think that people are sort of embracing that with open arms. And it's also a competitive market, right? Like the benefit of having model providers across, you know, Gemini, Anthropic is that really like the cost of inference is going down. So is the cost of API prices, right? Because everyone's competing to make as many calls as possible. or to be that provider for calls. And so it's in the consumer's favor. And so I think that it's trending in the right direction. And I think that people are quite willing to move in that direction. To the sandbox question. Yeah. So we talked a lot about code execution in sandboxes. Obviously, you can do that in a REPL tool, which just has fewer resources. I think one of the things we didn't touch on, and I should have touched on when you asked about complexities with deployments, is like, um off and permission control um and so that's definitely i think where sandbox has become super valuable like should this sandbox be you know shared should it be unique to every user conversation should it be like uh used for this user across conversations across the team across an org probably not sandbox across an org but um yeah i think permissions is like the biggest thing there and then also you know like why do we have containers why do we have servers for different things like you're just giving your agent access to like isolated resources is the idea and i think another interesting thing that people are sort of thinking about now is like do you run the entire agent in a sandbox or do you execute tool calls in a sandbox and and and effectively cross that that networking boundary make the tool call and then extract that response back The the problem with executing the entire agent in the sandbox is that you're now giving it sensitive API keys You're giving it the flexibility to go and make the calls that it needs to do now that agent, you know, it's still in a sandbox, but but The the environment secrets and things like that now also live in the sandbox, too And this sandbox is meant to be a safe place. So so now if you if you just use the sandbox for calling tools you have to take the hit on latency of making requests to the sandbox, the tool executes, and then receiving that result. And so there's trade-offs in both. And I don't think that the market sort of landed on a clear use of them yet. But our CEO, Harrison Chase, wrote about this, actually. He wrote a blog recently talking about the different paradigms of using sandboxes. And so I think definitely a good call out. And that's something that will become more clear as more people use it. So I think we have time for a couple more questions. I want to make sure that we're heard over here. Speaking for myself, the problems that we're solving in my company, we've used your React agent with almost like call it workflow and sub-drafts and all that. When clients come to you and ask, is this the right use case for deep agents? Do you see deep agents replacing some of those? here's the right way to do an analysis. For example, like I've got really complex data analysis that can run. There's a right way to do it. Sort of like a textbook case for like a workflow. Do you see Dbidgets kind of like coming in and replacing that like paradigm or you still see like two specific lanes for all the types of problems we've run into? Yeah, this is a great question. We are pretty... excited about deep agents we do think it's like the direction that things are going you know i said um give the agent more power to do things and it's gonna do a better job i think that's in line with the general like the more agentic something is the more useful it theoretically is but also maybe it's uh riskier for something to be more agentic i think you were mentioning like you know there are a lot of tasks that kind of fit well into this like workflow architecture like you need some deterministic compliance steps before you run some agentic task. And I think one of the ways that we're trying to build that into deep agents is with support for custom middleware. And custom middleware are things that you can go and plug in at any point in that agent loop. And so that's kind of our escape hatch for, hey, I do need to run some deterministic logic in this or checks, et cetera. We are putting a lot of bets on it as our agent runtime still. But I think Deep Agents is the future, yeah. And with that as well, the Create Agent, Sydney mentioned V1, the Create Agent is sort of the Create React Agent equivalent. And there are definitely some cases where if you just need a few tools to be able to be called by a model and you don't need to have things like delegated planning and all of the benefits that you get with Deep Agents, then it definitely does still make sense to use Create Agent and that. and that's sort of called React primitive. So that has access to middleware as well. So yeah, different levels of complexity is sort of where we see people use different primitives, if that makes sense. I think the last thing I'll add too is like we do aim to make these things composable. Like if your use case really lends itself to a workflow with like one agentic step, maybe you have a bunch of deterministic ones and then a deep agent runs in that agentic step and then you like go do your other tasks. Okay, I think we have time for one more, and then we'll have some time for networking. Was there one coming up from around here? Yeah. Yeah, we were talking about a couple of like, sort of like, Oracle standards, like A to A, like, through a little bit of collaboration. And the other one, MCP, as I get superseded, get a good, like, execution and running in the sandbox. Sorry, what was the last part? MCP, I mean, it was super popular, you know, like. there's six traditions more towards code execution and CLIs. Yeah. Yeah, I do think now that we're seeing a little bit more like popularity with programmatic tool calling in, yeah, like repls and sandboxes, maybe a little bit less relevant. At the same time, I think generally when there's like provider agnostic standards, I'm excited about it just because, you know, like skills, MCP, things like that are very exciting to like, you know, enterprise customers, et cetera, who know that collaboration across teams, both between people and agents, is really important. So maybe it's a little bit less important than it was three months ago, but I think still having standard specs is helpful. Yeah. And we kind of endorse that for Lynxmith deployments, our service for deploying agents built on Lingraph. We have A to A endpoints, and Lynxmith has MCP endpoints, and things like that. It's been an absolute pleasure to host you all at Lang Chains headquarters. Thank you.

Join LangChain's Sydney Runkle and Jake Broekhuizen as they dive into Deep Agents, an open source agent harness built for long-running tasks. It handles planning, context management, and multi-agent orchestration for complex work like research and coding.

In this talk, Sydney and Jake break down the core components of the Deep Agent "harness"—including planning tools, sub-agent delegation, file system integration, and secure execution environments (sandboxes). They also discuss the very real challenges of deploying these agents to production, managing context windows, and keeping track of long-running traces using LangSmith.

Deep Agents: Building for Complex, Long-Running Tasks with LangChain
00:00 Introductions
01:32 What are Deep Agents?
02:43 Common Use Cases for Deep Agents
03:56 Core Components of a Deep Agent
05:53 How File Systems Work in Deep Agents
11:58 Agent Skills and Skill Sharing
14:15 Sandboxes and Execution Environments
17:21 Challenges in Deploying Agents to Production
19:18 Observability, Tracing, and LangSmith
21:01 Quick Tips for Getting Started
25:05 Q&A: How to Write a Good Prompt
26:23 Q&A: Multi-Agent Architectures and Sub-agents
28:13 Q&A: Sandboxing, Isolation, and Cost Efficiency
29:43 Q&A: Will Deep Agents Replace Deterministic Workflows?
30:52 Q&A: Supporting Multiple Providers and Multi-modal Blocks

Extra resources
- Build with LangChain: https://www.langchain.com/
- Get started with Deep Agents: https://www.langchain.com/deep-agents
- Trace and Evaluate with LangSmith: https://smith.langchain.com/