Transcript for "Agent Memory 102: Context Retrieval & Storage":
Hi, everyone. I'm Giselle, the education marketing manager here at LangChain. Super excited to have you all join us today for this session on agent memory, specifically around context retrieval. For those of you joining us for the very first time, welcome. And for those of you who joined our session last week on agent memory and context management techniques, welcome back. And as a reminder, the session is recorded, so you'll get the recording and slides later today via email. So I'm here with Jess, one of our education engineers who will be walking you through today's workshop. She'll give you an overview, do a demo, and then present you with the take home assignment so that you can try things out for yourself. So I think you're in super great hands here. And, Jess, the floor is yours. Yeah. Thank you everyone for joining today. I saw a couple different locations. Very glad that you're all participating. And just as a reminder, if you have any questions, please direct them to the q and a channel, and we have a couple TAs behind the scenes ready to help answer. But let me get started. Giselle, I need screen sharing permission. Yes. Okay. Great. I'm very excited to be talking about how deep agents remember, and let's just get into it. When I say remember, I'm actually referring specifically to the context available to an agent here. Now, basically, if we were to stuff all the information an agent needs into its context window, we would exceed its capacity. If you give an agent too much information, things like history, noise, or tool output, the model gradually declines in accuracy, recall, and reasoning quality, something you may have already heard of as context rot, and we have two main ways to deal with this. The first line of defense is retrieval. Retrieval brings the right information in, and since agents have a limited context window, it has to retrieve information to complete certain tasks instead of having everything memorized. On the other hand, context engineering is what keeps the window lean once the information is already in. So retrieval is kind of like the prequel to context engineering. That's how I think of it. And retrieval techniques include RAG, which stands for retrieval augmented generation and is useful when you have a big pile of documents with questions phrased differently from the source because it matches on meaning rather than exact wording. Now file system search is the opposite. The agent uses these tools to search the way a developer would. It's precise, and this is great for code, logs, and exact names. And skills are retrieval for know how. The agent only sees each skill's name and description until it actually needs one, and then it reads the full instructions. I'll cover all of this later, so don't worry if it seems like it's a lot. And you can also hand the retrieval itself over to a sub agent. So all the messy searching happens in its own context window and only the answer comes back to the main agent. We'll come back to each of these. So here's the plan for today. First, I'll go over what a harness is and what the deep agent's harness gives you. Then I'll cover the three main problems agents run into when retrieving and how the harness solves each one. Finally, I'll briefly cover storage so we can understand where the files actually live. And finally, we'll do a demo. So what is an agent? Well, one definition is a model calling tools in a loop until it completes a task and returns a result. You've probably used Claude or ChattGPT and and seen it searching for tools while it tries to answer your questions. So you start with your input, basically your question, and that goes into the model. The model then calls a tool, and the tool result goes back into the model. And this keeps looping until finally you get your output or your answer. So this entire picture, an agent is just a model calling tools in a loop until it completes the task. And this tool part is part of something called a harness. And to define what a harness is, we'll look at it again in the context of an agent. So another definition of an agent, to simplify, is just a model plus a harness. The model being a large language model and the harness being the scaffolding around the model. To break that down visually, the model here cannot actually do much on its own. A large language model is technically just a word guessing machine. The harness here is what surrounds the model. This includes things like tools, sub agents, the system prompt, and so much more. Now all of this combined is what makes an agent. So what exactly is the job of a harness? It's to get the model the right context at the right time for the given task. With just the large language model, you're missing all the support structures that help with filtering what goes into the context window. This is retrieval. And then also managing the information once it's inside, which is context engineering. So DeepAgents is LangChain opinionated harness. What this means is that our engineers have built up features with best practices so that you can improve your agent more efficiently. It's basically a customizable agent harness, purpose built for complex real world tasks. And it's a great harness for two main reasons. The first of which is that it's provider agnostic or model neutral. New models come out constantly. It genuinely feels like there's a new one every single week. And being provider agnostic as a harness means you can swap the models without having to rebuild your entire stack. That way, if there's pricing changes or if you just wanna use something different, you're not tied down to a particular vendor. And the parts of the harness are also highly customizable. So the DeepAgents harness comes with many, many customizable components. The first of which is an execution environment, and this is made up of code interpreters, sandboxes, and file systems. What these do is they take actions and they connect to your data. Then for context management, we have skills, memory, summarization, context offloading, and prompt caching. These are all very crucial for long running agents. And our harness also ships with some delegation capabilities. So as workloads increase, work needs to be distributed, and planning and sub agents help with that. And these can also help with context management. And finally, human in the loop is built in with middleware. So sensitive tasks like financial transactions or sending an email externally, basically, think of human in the loop as something that you just want an actual person to double check the work and make sure everything is as you want it to be. So anything that you want human approval and feedback in real time, that's what you would use human in the loop for. Now all of this all of this is implemented with middleware, and Deep Agent is open source. So as you can see, it quite literally could not get more customizable. And most of these help with context engineering or retrieval. Today, because our webinar is focused on retrieval, let's take a deeper dive into that. Imagine an open book exam. You technically have every right answer. Sorry. You technically have every answer. You have the books. But that actually kind of makes finding the right answer harder. Where do you start? How do you know our sources right? How do you avoid wasting time on repeat searches? When searching, agents struggle with these three main issues, inefficient searching, having too much context at once, and having irrelevant or stale context. Here's the example I'll use for the rest of the talk, a competitive analysis agent. Every Monday, it researches five competitors and writes a report. For each one, it needs to find last week's notes, look up a number in a huge market data export, and search a news archive for anything new. Let's take a look at how we can do that. So back to the harness, starting with the built in file system tools. Our first issue, as I mentioned earlier, is inefficient searching. If the agent opens every file to see what's inside, every file lands in its context window. It fills up just from looking. Instead, if you check names and keywords first, sort of like scanning a book's index, Glob finds files by name and grep searches inside files without loading them. See the difference in the context windows? For my visual learners, here it is. Opening every file versus using file system tools to check names and keywords first. And every Deep agent has these file system tools, the one on the right, built in. However, as useful as it is, grep only matches the exact words you give it. If the agent searches for company a funding, it will miss an article titled company a closes 50,000,000 series b just because it doesn't use the word funding specifically. To search by meaning instead, you need semantic search, and this captures everything that's related. And it makes sure that, you know, you get the gist of it. It's the same thing. Funding, 50,000,000 series b, semantic search. But that's not to say grep isn't useful, because it is. It is very useful. Just think of these limitations by having to be so specific as horse blinders. But before reaching for semantic search, there is one more thing you can try. You can try using synonyms. So grep only matches the exact words it's given, but the agent choosing those words is smart. So you can just tell it. If funding misses, try series b or raised. The model itself already knows these. And if there's specific words that only your team uses, like internal names for things, you can list them in a skill, and I'll show you this later. In a way, the agent is doing semantic search by hand. Here's a silly meme, but, mom, can we get semantic search? We got semantic search at home. But as silly as this is, what I am trying to explain with this image is that your agent figures out what you mean and then preps for the synonymous words. And it checks each guest's synonym one at a time. So this works when you can predict the wording, when your model has an idea of what could be a potential synonym. But when you cannot predict it, that's where semantic search helps. It matches by meaning. So it can find something like company a's new backers include even though funding is never mentioned. And it does that in one search, not per word. And this is where a retrieval tool comes in. It's just a tool that takes in a query, looks it up somewhere, and returns what it finds. That somewhere can be a vector store for searching by meaning, which is what I just mentioned, a SQL database for exact lookups, a search API for fresh web results, or an MCP server someone else already built. So the tool itself stays the same. A query goes in, results come out. But what changes is the data source behind it, and that decides how it matches, by meaning, by exact values, by what's new on the web, or through someone else's tools. Pick the source that fits your question. However, even the right tool is only useful if the agent knows when to reach for it. So simple bots retrieve once and then answer. This is two step rag. While simple, that can be bad sometimes. One search and nothing great, and it gives up. A research agent needs a GENTIC retrieval. It decides when to search, what to search for, and whether it needs to keep digging. This is the same loop we saw earlier. Search is just another tool. But now we have another problem. Even the right search can return too much. Let's say our market data export has 40,000 rows. That's a lot. Instead of loading it all in, the agent preps for company b revenue and then reads only the lines around the match. The read file tool reads one page at a time. Offset here is where to start, and then limit is how many lines to read. Essentially, you're just setting what page to flip to and then just reading that page. It's just getting the information you need without all of this extra fluff. Now despite our best efforts, sometimes the tool just returns more than expected anyways, and that's where context offloading comes in. So here's what happens without it. You have a tool call, which produces one oversized result, and this fills up the whole context window. So when a tool result is too big, this is roughly over 20,000 tokens, the harness saves it to a file under large tool results. So the agent will get a path plus a short preview. This preview is just the first and last few lines, and then it can read back just the part it needs with read files offset and limit. So you see the difference in the purple sections? It's a lot less if you do this. But that safety net only catches one big tool result at a time. If our new search returned four articles with each one just a little under the limit, nothing will get offloaded because it's only combined that it's a lot. But individually, it's just enough to not... To fly under the radar. But they still all pile into the context window. It's the same concept. Now instead of hoping the harness catches it, we can build our search tool to do this on purpose. We can save each result to a file and return only the paths. The agent will see four short paths instead of four full articles and reads only what it needs. So offloading handles the results the agent fetches. But what about the instructions that we give it? And that's where skills come in. So a skill is just a folder filled with the context an agent needs to complete a certain task. For example, submitting an expense report with a very specific format. And this folder can include instructions, scripts, and reference docs. This sort of follows a similar idea to offloading where we keep information out of the context window until absolutely necessary. We're not always going to be submitting an expense report or whatever specific thing it is that we need. So we keep all of this information in a skill instead of just constantly in the context window. Because with skills, the agent only sees each skill's name and a short description, just these two lines. So when a task matches, it then reads the full instructions with the same refile tool that we saw earlier. For example, something like this. These are just three skills in a skills folder, one to search the news, one to look at market data, and one to cite sources in a very specific format. So as you can see here, all we have are the name and description. The full instructions only come in when the model decides a skill is relevant and then reads the file with the read file tool. So now the instructions are loaded into the context. And see how the other skills remain with just the name and description? Yeah. We don't need to know about that right now. We're not using those skills. And this whole idea is called progressive disclosure. The model basically sees a menu upfront, the name and description, but then they only pull in the recipe, the actual instructions, when it needs it. So that a bunch of skills cost as much context as just the name and description lines. So remember when I previously mentioned semantic search versus using synonyms? Well, the agent already knows funding can show up as raised or series b. Models are very smart these days. But there are some words it cannot guess. For example, if your team calls revenue monopoly money for some reason, just a random example, you can write those down in a skill. Just like the skills we saw just now, the agent only sees the name and description at first. When it's about to search competitor research, it reads the full list and then knows exactly which words to try. But each one is still a separate grip, and it's still exact matching. But you're giving the agent better words to look for, and they only take up context when it's actually searching. So without skills, you constantly carry context for every niche task. Whereas with Skills, the load is much lighter. You only need to grab what's necessary when you need it. So we've talked quite a bit now about making sure we retrieve small results to be efficient with our context window. And that is the main concept here. We wanna keep everything out of the context window unless absolutely necessary. But small results don't help if they are the wrong results, which brings us to the topic of irrelevant or stale context. Remember this? Previously, two step RAG wasn't cutting it because we were missing out on a diamond mine of information. But you're not always missing out on a good thing. It can be stale context instead. For example, an outdated article, a company with a similar name but has nothing to do with you, or it could be text with instructions hidden in it. To the model, it all looks like diamonds. It cannot tell the difference. Only we as humans know that. So we can try to use sub agents to filter out the irrelevant or incorrect information. As a quick recap on how sub agents work, your input goes into the model. We saw this right at the very beginning. And your model has one context window, which fills up. But that's where the sub agents come in. Think of sub agents as mini assistants with their own context windows and separate tools. So let's say your main agent is a newsletter agent in charge of putting together an entire newsletter every week. Let's make the sub agents here specialized in research. The one on the left, subagent a, can have specific tools to scrape the web for news articles. And now the tools it needs for this, the main agent doesn't need to know. Same thing with the subagent on the right here, subagent b. It can have specific tools to scrape through video information. Everything is isolated to its own task. Then they can call their respective tools and return only the final result. And since their tasks are small, these subagents can also run on a cheaper, smaller model, saving you a lot of money. And now with the main agent only having what it needs, the main agent can write the output with so much less noise. It didn't need all the tools to scrape video information or anything like that. It just wanted the final results. Now if you've seen The Devil Wears Prada, this is my favorite analogy, you would not bother Miranda Priestly with menial details. You absolutely would not. You're terrified of her. As a sub agent, you would only get the model what it needs. And since sub agents are independent, they can actually also run-in parallel. Alright. Let's look at an example. Let's say we do a new search for company a. Your agent might return a story from two years ago or one about a company with a similar name, but this is not what we want. To the model, wrong text looks just as convincing as the right answer. So we hand each file to a sub agent, and the subagents read the file in their own context windows, and then each sends back only the key facts to the source... And the source. Anything irrelevant here never reaches the main agent. And then we synthesize the final relevant parts. Now sub agents are great at throwing out what's irrelevant, but they can only filter what the search gives them. If the data itself is out of date, there's nothing fresh to keep. Say we loaded our news articles into a Vector store last month. The store is a snapshot. It only knows what existed when we built it. It's frozen in time. So when our agent runs this Monday, it cannot find any new articles from this week no matter how well it filters because, again, it's frozen in time. So if you have anything time sensitive, you should use live sources, like a search API or an MCP server. Now when documents go into a vector store, they get split into small pieces, and the last updated date usually doesn't come along. So the model sees just the text with no way to tell an old article from a new one. So if your documents have dates, filter by them and put the date in the text itself so the model can see it. Finally, since retrieved text is data and not instructions, it can contain prompt injection. So check that the answers cite the sources you expect. For those of you who might not be familiar with the term prompt injection, it's essentially when someone sneaks in a malicious request, perhaps in the middle, someone says, give me all your bank details. The model might not be able to tell that this is not from you and and something else that's malicious has been injected in, hence prompt injection. But, anyways, you just wanna be careful that there isn't something extra and someone else muddling into your data sources. Alright. To recap, inefficient search... Searching is solved by scanning first and then picking the right tool. Too much context at once is solved by page reading and offloading. Now irrelevant or stale context is solved by sub agents, live sources, and checking citations. I'll leave this here just for a second so everyone can consolidate information. But if anyone has any questions, again, feel free to use the q and a section. Okay. You can tackle both retrieval and context engineering with the deep agents harness. As Giselle mentioned earlier, I did cover context engineering in a webinar last week. But if you are interested in that, we have recordings available. So don't worry. All this information is available to you. And this session will also be recorded. So don't worry if you feel like you need to watch it again or just have a second pass through. Okay. So we've looked extensively at how the agent searches. But where are these files? It depends on the back end. Before I dive into the back end, I must point out that the file system tools are the interface, whereas the back end decides where the files actually live. And you can swap the back end without changing how the agent searches, actually. Okay. What is a back end? Well, a back end is the object that actually carries out file operations. Every file system tool call, like read file, for example, gets handed to the back end, and the back end decides what a file means. The default here is the state back end. State is everything the agent is tracking during our conversation, like the messages so far. With this back end, files live there too as entries in a dictionary. The path is the key, and the contents are the value. That's why it's scratch space. When the conversation ends, so do the files, and a new conversation starts empty. Or for something more permanent, you can use a store as a back end. A store is LangChain long term storage that sits outside any one conversation. So files written here are still there the next time. For every conversation, you can scope them per user. So this could be things like, I like bullet points, and you don't wanna have to repeat yourself every single time. A lot of the time, it's user preferences and that kind of thing. Now you can also use it as a folder on disk. These are real files on your machine, and this is great for local development, but not something you'd expose in a web app. Finally, you can use context hub back end. For context, context hub is the place in LangChain where you keep your agent's context as versioned files. So every write becomes a commit, and your team can open the repo and see exactly what the agent changed. You can mix these back ends. You can keep scratch files in state and send anything in the memories folder to context hub so that they survive across conversations. In DeepAgents, there's one more kind of back end that does more than store files, though, and that's this, a sandbox. For those that might not know, a sandbox is just an isolated environment. Think of it like a safety container or a separate computer the agent can safely work in without touching yours. So in the event that something goes wrong, like you just saw, everything stays protected. Now in DeepAgents, a sandbox is actually a kind of back end. It gives the agent the same file tools with one more called execute, and this tool lets it run shell commands. And your agent can write code safely. So that's some information on back ends and what people traditionally think of as storage. But let's get to the fun part. I'm going to demo these techniques with an apartment hunting agent. There, I believe, Giselle is either sending out the link or it's already in the docs tab. So you can feel free to take a look at the collab. But, honestly, it might be easier just to watch me and follow along for now. There will be a separate take home assignment later, so you can, for sure, play around and customize it as much as you want. But for now, let's head over to my Google Colab. Okay. Beautiful. Beautiful. So I thought we could have some fun here. We are going to take a look at an apartment hunting agent, which searches viewing notes, a rent data export, and a listings archive. This is all so much information, so much context to deal with. And we will take a look at all three issues that I addressed today, inefficient searching, too much context at once, and irrelevant or stale context. So this is just some setup code that I've already run. This installs the libraries. This makes the code pretty so that the rest of you who are watching don't have to suffer. And then... Okay. Here. This is where it gets interesting. This is a little demonstration of how we are model neutral or model agnostic. So here is where we add our model provider. I'm using Anthropic, but you can change this to anything you want. You can use OpenAI. You can use Nemotron. Whatever. We support open source models. So all you have to do is make sure that, this is where you add your API key, this literal key symbol. Just make sure that the name here is the same as what you have here, and then you add your key. And then just make sure that you give your Colab notebook access. But... Yeah. So this is where you add your model provider. It's just these two lines. And then here is where you specify the actual specific model you wanna use. I'm using CloudFront at five here, but, again, could use GPT six. You could use whatever you like. Yes. And if you wanna change anything at any point, all you have to do is just come back up and change it here. Alright. I also created these helper cells so that we can take a look at what's going on behind the scenes. Show steps prints each tool call, the final answer, and the peak context. That way we can see what's being called. For example, if it's grep or something like that. And then the peak context returns the most tokens the agent saw at once. This will be really helpful in comparing using the retrieval techniques I talked about and not using it. There's a very stark difference, and these numbers will will help cement that. And here's just some stuff about the data. Again, we're doing a... An apartment hunting agent, and I'm looking for a pet friendly one bedroom under 2,500 a month. This is impossible in San Francisco. If anybody knows, feel free to let me know, but just as an example. And these will just build a research folder with some made up data. And here we have three things. We have our notes from 30 apartment viewings with one file each, and then here's our 40,000 row market data export with median rent and number of listings by neighborhood, month, apartment size, etcetera. And then listings are an archive of rental listings with one profile. And each one is... The first one that I mentioned is around 21,000 tokens. This is around 436,000 tokens, and this is around 52,000 tokens. And here is where we set up the back end. Okay. Let's get to the fun part. Inefficient searching. Here is the part where I mentioned that you should always scan first before reading. Otherwise, you just open up every single thing and it takes forever. So we're gonna look at the taking forever option first. So my question is, what did I note about the laundry at 14 Maple Street? My viewing notes are in notes. So the way you actually create a DeepAgent is super simple. It's literally just this line, create DeepAgent. And then here, model equals model is the model that we added earlier, the part that I said you will never need to touch again unless you choose to change. So... Because it's here, super simple. thing with back ends, which was here. You quite literally just add your back end here. And then for my system prompt, I've added don't use glob or grep. I have to state this specifically because models are smart and they they know not to do that anymore. But this is if you didn't use file system tools and you read every single file in it with read file. So, at peak context, we saw almost 40,000 tokens. And, yeah, it did answer the question, but look how much it took. So a default deep agent, which does have file system tools built in, it can check the file names with glob and then search inside files with grep. So, again, same thing. I've added the model in back end here, and let's take a look. So we read the file, and look, 5,628 tokens. That's a big difference just by using a file system tool. There you go. But remember we said that grep only matches the exact words it's given? Well, if I wanna specifically look at which listings are pet friendly, we can tell the agent to grep for pet friendly. So search listings with grep using the word pet friendly. And, again, same format. And we can see we've used grep. We've looked for the words pet friendly, and there is an option here. Only one one bedroom listing that matches. And it says there's also a pet friendly two bedroom listing. That's not what I'm looking for. It took roughly 4,186 tokens. Now this dataset had two twenty twenty five listings that say pet friendly. However, there were actually two October 2026 listings that never used that word. But it only looked for pet friendly, so it didn't know to look for anything else. This is where we bring in semantic search. So, again, when you cannot predict the wording, semantic search helps. And this cell basically splits each listing into paragraphs and loads them into a vector store using a small embedding model that runs locally. In the homework assignment that I give you, you have... You don't need to run this. I give you some examples with Wikipedia so you won't need to have so much setup, but this is just an example for the demo. And like most vector stores, each piece keeps only the paragraph text and the title and date go into metadata that the model never sees. And we'll take a look at this later. Alright. So everything's in, and let's take a look. How does everyone feel about the poll questions so far? Are you having fun with those? Okay. Wait. We have this back now. So this one bedroom is pet friendly with a small yard. This two bedroom is pet friendly and close to a large... Whatever. Small dogs and cats are welcome in this one bedroom. And bring your furry friend. So these two options, we wouldn't have seen if we didn't use semantic search. If we were super, super precise about wanting to use the words pet friendly, we would have missed these two. It means the same thing. Alright. Now when you have too much context at once, this was our second issue, we want to read one page at a time. Just gonna run this first. So my question is, what was the median rent for a one bedroom in Riverside in twenty twenty six zero nine? The answer is going to be only one row in a file with 40,000 results. So read file will never return a whole file. It will return one page, and it'll limit a 100 lines by default, but you can also set this. And we'll start it at whatever offset you set it. Now the first line of every result says which page the agent got and where the next one starts. So here, again, very simple setup. What was the median rent? This is our question. We read the file and we grabbed for specifically what I was asking for. And it tells me that in 2026, it was 2,410, and this was about 6,671 tokens. If we look through the entire thing, remember, the entire export was 436,000 tokens. So, thankfully, it only took this much. Yes. Now retrieval, offloading, and delegation is another pattern that we briefly covered earlier. A retrieval tool takes a query, looks it up somewhere, and then returns what it finds. So this one will return the full text of the four best matching listings, and each one is under the 20,000 token offload limit. So if you remember my earlier diagram, if each one is, like, just under the limit but all four land in the main agent's context, it's still a lot. And so here are some more helpers, and some tools that we use to look for our listings. Okay. Back to here. Because we use this tool, search listings, all you have to do is add it to your deep agent here. Super simple. Here's our tool. And we can see that we use the search listings tool, and here are the pet friendly one bedroom apartments that we found. One bedroom with a small yard, explicitly pet friendly, renovated kitchen, pet friendliness wasn't explicitly stated, but we might need to confirm, etcetera. Now this was about 12,000 tokens. So it, like, worked. We got our answer. But, again, this was higher than the other searches that we did. So because all four full listings land in the main agent's context, it has stuff we just don't need. So we can split the work into two. Retrieve and offload, search listings to files runs the same search, but it saves each listing to a file in retrieved and then only returns the file paths. And then for delegation, the main agent will hand each path to a chunk analyst sub agent. The sub agent reads the listing in its own context window and sends back just the key facts, and the main agent only will ever see four short paths and four short summaries, much less than everything. Great. So this is how you set up a sub agent. Right here, we have our name, chunk analyst, and description. Reads one retrieved file and returns its key fax. Give it the file path. So progressive disclosure, the concept I mentioned earlier, this is all the agent will see until it actually needs anything else. And then for the system prompt, read the file you're given with read file. Return the key facts in two or three short bullet points. Don't return the raw text. So the system prompt is essentially something that sets the behavior of the agent. So we want it to respond in two or three short bullet points. We could leave this out, but it just means it might respond with paragraphs instead. And I specifically want bullet points. And then this was the tool that I mentioned earlier to search listings. And... Yes. So we add the tool here, same thing, search listing to files, and then we just add the sub agent here, chunk analyst. Alright. So, oh, we can see they fired it off in parallel, four task calls. So these are all sub agent calls. Analyze it listing file result one because there were four files, and each one used the chunk analyst sub agent. So they found three pet friendly one bedroom apartments. Wow. A tub. Haven't seen that in a while. A loft near a dog run, pet friendly, with grooming station and no breed restrictions. Okay. Doing crazy out here. So here are three great options found using a sub agent. And look at that. The peak context was 5,401 tokens, much less than that 12,000 that we saw earlier. There we go. Direct comparison. Alright. Now, usually, all of this is quite manageable and relatively intuitive. But when it comes to irrelevant or stale context, this is what most people tend to struggle with. We can try to combat that by putting the date in the text. So same question again. Is the one bedroom at 14 Maple Street under $2,500 within my budget? So the archive has a long 2025 listing and a short 2026 relisting with different rents. And if I were to look at something thinking it was 2026, but it was actually 2025, would be operating on old stale information. So I'm asking now. It uses the chunk agent... Chunk analyst sub agent, and there appear to be two different one bedroom listings at 14 Maple Street in the results. One at 2,300 a month, which is within my budget, and another at 2,600... 22,650 a month, which is over my budget. So it depends on which specific unit you're looking at. This took 5,440 tokens. So the search tool writes a short header at the top of each file and can skip older listings with published after. So the sub agent will return the date along with the key facts and flag anything outdated so that we're... We don't even need to look at anything that's older. It's irrelevant to us. So that's the tool here. And a tool with deep agents, is essentially just plain code. Whatever you can write as a code and this... And you can include, MCP servers and everything, that's how you add a tool. You quite literally just add this little... It's called a tool decorator, and that turns something into a callable function. Okay. So back to our usual setup of creating deep agent. We have our model, our tools, our sub agents, dated analyst, right here. It's essentially our chunk analyst, but flag anything that looks outdated, and we have to include the published date. So with that, we take a look. And two listings for 14 Maple Street workout, an older one and a more recent one. So, yeah, the most recent listing is over my budget, unfortunately. So we can see that here. So, essentially, what we covered in this notebook and in the lesson earlier is inefficient searching. You wanna try and scan with glob and grep before reading. And when the wording is predictable, have the agent try synonyms. But when it isn't, it's worth to try a semantic search tool. And when there's too much context at once, you wanna grep first and read a page at a time with offset and limit, and then have retrieval tools return paths instead of full text. As for irrelevant or stale context, let a sub agent read each result in its own context, put the date in the text so that the model can tell old from the new. So this was a very quick overview. We only had, a limited amount of time today. But if you are interested, we have a deep agents course from LangChain Academy. Actually, let me navigate back to slides. Let's take a look. Oh, before I get into that... Actually, here is a take home practice for you. I I understood I went through things a little quickly, and if you wanna take your time, if you wanna customize things, we have this take home copy for you to play around with. I believe it should be in the docs tab, but if not, feel free to scan this QR code or use, this specific GitHub repo. If, I know sometimes some people cannot access Google Colab due to company computer restrictions, anything like that, there are local versions that you can run your own IDE or anything like that. But, yeah, I highly recommend you try to play around with it. It's a great way to see the real... You can see the token difference, and I think that's really satisfying. And... Yeah. Again, would recommend heading over to LangChain Academy. It's taught by someone really cool. It's me. And for the first time ever, I'm actually also going to do... This is a little experimental, but we all recently... All the education engineers recently got Twitter accounts. Some of you are very active on tech Twitter, some of you are not. But if you would like, I am opening up suggestions or requests for specific concepts that you may be struggling with, and I'm gonna try to respond in meme format. So using humor to explain something a little more unconventionally. But as you can see, I love sprinkling those into my webinars. So if you're interested in anything like that, let me know, and I will do my best to try to explain things in a way that's accessible to students. Yes. And I'll hand it back to Giselle. Alright. I'm launching a feedback survey now. Thank you so much, Jess. I learned so much from you all the time. So please let us know how we did and just the kind of topics you'd be interested in learning about in the future, like Jess mentioned. And we actually launched this series on agent memory based off of feedback from previous workshops, so your feedback definitely does matter. And our next session will actually be on a managed run time for agents. So if you're not familiar with what that is, I definitely recommend checking it out. You can click the link in the docs tab next to the chat to register, but I'm actually gonna just drop it in the chat right now as well. And then, one more thing is that if you tag us on LinkedIn and use the hashtag l c a workshop to let us know what you learned and show us your take home assignment, we'll be keeping track of those posts and raffling off a very fun prize. So looking forward to see that. And thank you all so much again for joining us today. Hopefully, we'll see you again in the coming weeks.