Transcript for "Agent Memory 101: Context Engineering":
Hi, everyone. Thank you for joining us today for this session on agent memory. I hope you're all excited to learn about some context management techniques to prevent context rot. So how many of you guys did the suggested reading that I linked in the reminder emails? Everyone? Everyone? Okay. Great. Well, for anyone who didn't, you can think of the next hour as a compression of that reading since we'll be summarizing very aggressively if you understand my drift. But just in case, I will put it in the chat now. There you go. Anyway, I'm Jezell, the education marketing manager here at LangChain. I'm here with Jess, who's one of our talented education engineers, and she'll be walking you through the workshop today. So she'll give you an overview, do a demo, and then present you with a take home assignment so that you can try it out for yourself. So I think you're in really good hands. Just take it away. Yes. Good evening or good morning depending on wherever you are in the world. I'm seeing a lot of different places. I saw one person said they're from Earth. Welcome. I'm very excited to be talking to you all today about context engineering. So when I refer to remembering, I'm actually referring specifically to the context available to an agent here. And if we were to stuff all the information that an agent needs into its context window, we would exceed its capacity. Now if you give it too much information, things like history, noise, or tool output, the model gradually declines in accuracy, recall, and reasoning. 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. Since agents have a limited context window, it has to retrieve information to complete certain tasks instead of just having everything memorized. Now techniques can 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. And file system search is the opposite. The agent uses these tools to search the way a developer would. It's precise, which 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 explain more on how this works later. And finally, you can also hand the retrieval itself to a sub agent so that all the messy searching happens in its own context window and only the answer comes back to the main agent. So this is retrieval, but retrieval only solves half the problem. Even if you pull in all the right things, a long running agent keeps piling up tool results, messages, and intermediate work, as I'm sure you've experienced yourself. So beyond retrieval, something called an agent harness has to manage what's already in and around the context window with offloading, summarization, sub agents, and long term memory. Now the common thread is that none of these just delete information. They move it somewhere the agent can get back to. In order to look more closely at how we can implement these techniques, let's take a closer look at what deep agents is, what a harness is, and what an agent is. Let's go all the way back to the beginning. Let's start with 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 TouchEPT and seen it searching for tools while it tries to answer your question. So how that works is you start with your input, basically your question, and that goes into the model. The model then calls a tool, and the tool result then goes back into the model. And this keeps looping until finally you get your output or your answer. So that's the entire picture. An agent is just a model calling tools in a loop until it completes the task. Now this tool here is part of something called the harness. And to define what a harness is, let's look at it again in the context of an agent. Another definition of an agent, to simplify, is just a model plus a harness. The model being the 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 is what surrounds the model. This includes things like tools, sub agents, the system prompt, and so much more. All of this combined is what makes an agent. And retrieval is how the harness makes sure the model makes the right decisions by getting the model the right context at the right time for the given task. With just the LLM, you're missing all of these support structures that'll help with filtering what goes into the context window and how to manage the information once it's inside. So DeepAgents is LangChain opinionated harness. What this means is that our our engineers have built up features with the best practices so that you can improve your agent more efficiently and not have to worry about building the things that everybody needs in the first place. 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. Genuinely, it feels like I'm hearing about something every other week. And by being provider agnostic, it means that you can just swap models without having to rebuild your entire stack. That way, you're not tied down by a particular vendor, so pricing changes or just wanting to try a new model doesn't affect you at all. And the parts of the harness are also highly customizable. It has many, many components, and the first of which is an execution environment. This is made up of code interpreters, sandboxes, and file systems. These take actions and connect to your data. Then for context management, we have skills, memory, summarization, context offloading, and prompt caching. These are all crucial for long running agents. And our harness also ships with delegation capabilities. As workloads increase, work needs to be distributed and planning and sub agents help with that. They also help with context management. And finally, human in the loop is built in with middleware, and I'll get back to this in a second. But human in the loop ensures that sensitive tasks like financial transactions or sending an email externally, essentially anything that you want an actual human being to keep an eye on and double check, it ensures that there's human feedback and approval in the loop in real time. And Deep Agent is open source, so everything you see quite literally could not get more customizable. And again, all of this is implemented with something called middleware. So what is that? These are essentially hooks that allow you to customize behavior in the agent loop. It's basically a custom function that you insert into the loop, and it could go before an agent. It could go before the model or wrap a tool call. Everything that you see here, these are all potential middleware options, and this will make more sense with an example. So let's take a look at summarization and context offloading as a way to manage context. Let's focus on offloading first. Offloading intercepts your input before they even enter your context window. In terms of middleware, offloading works by wrapping a tool call. So let's say a tool call comes back with something huge, perhaps a full database export, which contains hundreds of search matches past roughly maybe 20,000 tokens. That's too big to just drop straight into the conversation and quite frankly unnecessary. So before that ever gets added to the model's context, file system middleware intercepts it, And it then writes the complete result to disk untouched so it's full and lossless. So if the agent ever actually needs the rest, it can call the read file tool with an offset and limit and page through just the part it needs. Offset just basically tells you, like, which part to go to and limit is how much to read. And that way, you can just slice out exactly the part you need instead of having to go through the whole thing. Now what actually lands in the model's context is just a short preview, like, literally the first and last few lines plus a pointer to where the rest lives so that you can go back and search if you need more. And it's the same idea for an oversized user message, for example, like a long pasted doc or transcript. It's the same concept. The threshold is slightly higher at 50,000 tokens instead of 20,000 for a tool call, but it's the same, and it's safe to conversation history instead of large tool results. But the model just sees a few lines instead of the entire pasted transcript or the entire pasted database. Now summarization, on the other hand, acts on content already in the context window. This is what you do when you need that information and it's already in there. It wraps each model call and can rewrite the message list first. So here's our context window, and this represents everything the model can currently see. As a conversation runs, messages will pile up. We know this. User turns, tool calls, tool results, and this bar right here at 0% represents that. So I'm using a summarization threshold here of 85% as an example because that's the default, but you can actually customize this to be whatever you want. So we start chatting. You can see the bar going up in green right there until... Look at that. We just crossed the we just crossed the threshold. So before the next model call, the harness decides what to keep as is and what to fold. Oh my goodness. Maybe I need to summarize this talk. We just crossed the threshold. But for the next model call, the harness decides what to keep as is and what to fold into a summary. Now the reason it overshot the 85% threshold to 88% is because the check only runs right before each model call. Remember this middleware diagram I showed you? A turn with several tool calls can add a lot in between model calls, so that's why it doesn't just automatically stop at 85%. Now everything above that cutoff line goes to a separate LLM call that writes one compact summary, and everything below the cutoff stays exactly as it was. So a little similar to offloading, the original messages are saved to a file. Nothing is actually lost, but the next model call is so much smaller because it just needs the summary, and usage drops way down. The model now sees the summary first and then the recent messages word for word. We We wanna keep the more recent messages in case you're working on a task or you just need everything verbatim. You need everything exactly as it was in the full context. But you might not need something from 10 conversations ago. You know? And as the conversation continues, it climbs again. So remember, what you're seeing now is the context window after summarization has already occurred once. More messages keep building until it hits the threshold again, and then we summarize again. And this time, the summary includes the previous summary too, and the recent messages come along after it. And this keeps cycling. Remember this table? I'm personally more of a visual learner, so I like to think of it like this. Offloading happens before, intercepts the results, intercepts the inputs, whereas summarization happens after the context is already in the context window. Now to picture these two together, look at this graph. As the agent works, context grows. This is that graph trending upwards. The small white drops here are offloading, so it's managing all the tool results, remember, that we looked at earlier. So this sort of prevents, like, it from building too much and any large tool out... Outputs. Whereas this big blue drop here is summarization. The harness at this point condenses the history while preserving the key information needed to continue, but it deals with the overall buildup over time. So these two work together and that was context offloading and summarization. Another context management technique, however, is to use skills, and a skill is essentially a folder filled with the context an agent needs to complete a certain task. For example, something like submitting an expense report with a very specific format, and the folder can include instructions, scripts, and reference docs. It follows a similar idea to offloading where we basically keep information out of the context window until absolutely necessary. I mean, you're probably not supporting it at expense report every single day. You only need this once in a while. And this works by using two middleware hooks. First, before the agent starts, it scans the skill... Skills folder and reads just the header of each skill dot MD file, and this has just the skill's name and a short description. The instructions are not loaded in yet. This is the actual know how on how to do things. And then the second middleware hook on every model call, it adds that list of skills to the system prompt. This way, the model essentially knows what you have available, what skills exist, but not necessarily what's inside them or how to actually operate everything because it only has the name and description up until this point. So for example, here are three skills in a skills folder, and the full instructions will only come in when the model decides a skill is relevant and reads the file with the read file tool. Now the instructions are loaded into the context, but see how the other skills remain with just the name and description? This whole process is called progressive disclosure where the model basically sees kind of like a menu upfront but only pulls in the full recipe when it needs it so that 10 skills cost about as much context as ten one liners. So without skills, you constantly carry context for every niche task, whereas with skills, the load is much lighter and only grabbed when necessary. Okay. We just covered three examples of how to deal with context rot, but another excellent way to manage context is actually with sub agents. So you've seen this before. You start with your input, which goes into the model, and your model has one context window, which fills up. But that's where the sub agents come in. Think of them as mini assistants with their own context windows and separate tools. Let's say your main agent is a newsletter agent in charge of putting together an an entire newsletter every single week. Let's make the sub agents here specialized in research. The one on the left, sub agent a, has specific tools to scrape the web for news articles. The sub agent on the right, sub agent b, has specific tools to scrape through video information, for example. They call their respective tools and return only the final result. And since their tasks are small, they can often run on a cheaper model. With only what it needs, the main agent writes the output with much less noise. If you've seen the Devil Wears product, then this is how I would picture it. You wouldn't bother Miranda Priestly with menial details, would you? As a subagent, you would only get the model what it needs. No faffing about. And since subagents are independent, they can run-in parallel. So everything we've looked at so far, offloading, summarization, subagents, all of that happens within one conversation. That's what we refer to as short term memory. Long term memory is what persists across conversations. Now in the deep agent's harness, long term memory is just a markdown file. Agents dot MD. You point the agent at it with one argument, and do you remember the middleware hooks? Before the agent starts, the file is loaded. Then on every model call, it's added to the system prompt so the model always has it. And when the agent learns something worth keeping, like a correction or a preference, it updates the file itself with the edit file tool. Load, inject, update. This is the entire loop. And the next conversation starts by loading the updated file, so the agent picks up where it left off. But that only works if the file is still there when the next conversation starts. So let's say your agent wants to save something. So it calls write file, but we can set it up so that before the file is saved, it goes through a router. In DeepAgents, this is called a composite back end. All it does is look at the file's path and decide where it goes. In our setup, if the path starts with memories, it goes to the store, and the store is persistent. So these files are available in every conversation. Everything else goes to the conversation state. That includes the offloaded tool results we saw earlier and any drafts the agent writes while it works. This is scratch space. Essentially, these files stay within one conversation and a new conversation starts without them. So to recap, the agent always uses the right file tool. The only thing that changes is the path, and the path decides how long that file lasts. If you put it in memories, the agent remembers it for the next time, so use this for things like important preferences or things that you want to carry on with you. And that's what makes memory long term. It's not actually the file itself, but where it's stored to make it last. Now since memory is just a file in your store, it doesn't belong to any specific model provider. Just like everything else with the deep agent's harness, memory is also model agnostic or model neutral. Say in one conversation, the agent learns that I like bullet points, and I wanted to use bullet points all the time, and it'll save this to the file. In the next conversation, I could switch to a completely different model, but it'll load the same file and it still knows. Stick to the bullet points. Without long term memory, every conversation starts from zero. I need to re explain my preferences and correct the same mistakes. All of that uses up context. And since memory is in every model call, the agent only saves what lasts, the preferences and corrections, not irrelevant small talk. And you can manage context and memory very easily with the DeepAgents harness, where middleware tools and other techniques are already built in for you and easily customizable. Okay. Let's get to the fun part. I'm going to demo the three techniques I just mentioned, and it'll make a little more sense when you see them in action. So I'll be covering offloading, sub agents, and summarization, and feel free to take a look at the collab. I believe this was sent out earlier in an email. But, honestly, it'll be easier just to watch me and follow along for now. The session is recorded, so you can always look back, and there will also be a separate take home assignment that you can play around with afterwards to practice your skills. So let's switch over to... Okay. Great. So here's our notebook. And part one of this notebook will use The Winter's Tale, which is a very long Shakespeare play, and it'll show how a deep agent works on its own. And then part two will use... I found a funny article about the emu war on Wikipedia. And this one, I'll show you how to change those defaults, for example, summarization so you don't have to stick to 85% so that you can customize your agent. Alright. So I've already installed these, but just install your packages, and this basically just wraps long output lines so that it's pretty and easier to read. Okay. This is the cool part. So I'm using an anthropic key here. So all you have to do is just go to secrets if you're using Google Colab. I will also send out a GitHub repo later that, will be available to you in case you cannot access Colab. But all you have to do in Colab is add your API key here and just make sure that whatever you use here matches what's here, and then just add your key in here. And then you have to give your notebook access. If you don't, it's, like, not putting it all, but give your notebook access, and that's really it. If I wanted to change this to OpenAI or, NVIDIA's Nemotron, whatever it is, super simple. I quite literally just change it here and then change my key here. So very easy. And these are the only two cells that ever need to change if you're changing your model. Everything else below, all the code you write, your entire agent, essentially, does not need to change. Just this. And here... Oh, let's actually just run those. And here, I'm using Sonnet five. But, again, super simple. If you wanna use GPT six, if you wanna use QAN, whatever it is, just change it here. Very simple. Alright. And I've also created these two helpers just to keep things neater. So show steps will print each tool call, the final answer, and the peak context. And peak context is the most tokens that an agent sees at once. Again, this is all just to keep it neater. You could totally omit this if you want. Alright. And now this chunk will download the two texts, and it'll wrap each one in a tool that the agent can call and print how big they are. So replay, specifically, will return the full text of The Winter's Tale, and then read emu war will return the full Wikipedia article on the emu war. Alright. So I ran those. These are just the tools. And... Yeah. So you can see here that the winter's tale is a 149,000 characters, and that's roughly 37,000 tokens. And the emus war is a lot smaller, at around 11,000 characters and 2,752 tokens. So deep agents offload any tool result over 20,000 tokens by default, so the play here is over the limit, but this is under. Again, we'll look at both in a second. Oh, but one thing to note, even a deep agent with no conversation and nothing actually happening, it starts at roughly 4,000 tokens already, and this is just the harness itself. Essentially, the system prompt, the tool definitions, and all the built in things. So if you see a peak at around, like, 5,000, only about a thousand of that is the actual work, just some context. Alright. So let's take a look at offloading. This is actually how you create your Deep Agent. It's super simple. You quite literally create your Deep Agent. And this model equals model here is what I was demonstrating earlier that makes it really easy for you to change. I can change anything up here because I've already set it to be this. I don't need to change anything from here on. And then I've also given it the tool replay so that we have access to our information. And then you invoke your agent here by just using agent dot invoke, and this is the question I've asked it. I'm asking my agent to read the play. How does Antigonus leave the stage in act three? Quote the stage direction. This is kind of famous. You may or may not have seen this before. But you can see that I didn't add any offloading settings anywhere, by the way. And the tool call, I called replay, and the result here is Antigonus leaves the stage in act three, act three scene three with the famous stage direction, exit pursued by a bear. And it's giving me a little context. This occurs right after he abandons the infant on the Bohemian Coast, delivering the memorable final line, etcetera, etcetera. And if you see here, the peak context was at 4,618 tokens. And here, we can see that it's given us large tool results. So file system middleware stepped in here. It saved the full play to this file, and then it gave the model a short note with just the file path and a preview. So, again, just the first few lines of the play. And it called the GREP, specifically, which is one of the, retrieval techniques that I spoke about where it's about the exact, with the pattern. However, if you notice, I actually asked, how does Antigonus leave the stage in act three. I did not use the word exit at any point, so it looked for the exact words exit pursued by a bear. That's a little weird because I didn't ask for that. Well, that's actually because the model picked this search term itself. This is a very famous text, and it already knew this play, the bear exit, specifically. So it guessed that the file would contain that exact text. Otherwise, normally, grep would just confirm the guess and fetch the exact line. If the model didn't know the play, it would have searched for something a little broader like exit or antagonist and read through the matches instead. But regardless, you can see the point of offloading. The agent didn't actually read everything. It just decided what to look for specifically and pulled in only that. So, again, peak context was 4618 when this play is actually thirty seven thousand tokens. It only looked at this much. So did a pretty good job, I'd say, of preventing context from entering the context window in the first place or unnecessary context. Alright. So that was offloading. And now if you take a look at sub agents, we can ask for a one sentence summary of each act twice, once from an agent that read the play itself and then once from an agent that sends each act specifically to a sub agent. And the subagent reads in its own context, if you remember my diagram earlier, or Miranda Priestly. So the main agent only sees the answers. It doesn't see all the working out and all the searching. The model already knows this play, though. Excuse me. That was rude. What on earth? This is like those forced updates that happen at work sometimes, and you just have to twiddle your thumbs. Okay. We're back. We're back. Amazing. Amazing. Alrighty. So, yes, let me just run these. So I'm asking this question twice. Summarize each of the five acts of the play in one sentence. So, again, it might skip the reading and answer from memory because this is a very famous play, and I just wanna make sure that the model doesn't actually just do that and answer from, like, its own memory. So I'm forcing the model to look at the text, and I've added this instruction. Answer only from the text that replay returns our tool from earlier, not from memory. Read as much of it as you need. So this is just me forcing it. If I had chosen a less, famous or prominent play, I wouldn't need to do this, but then copyright reasons. Yeah. So here we have our agent without a sub agent. We're creating this new deep agent, with the system prompt so that it makes sure to not answer from memory. And then here is our sub agent. So the way a sub agent works is actually very, very simple. Here we have the name, reader sub agent, and then the description is to read The Winter's Tale and answer one question about it. The system prompt is the text from earlier. Again, don't answer from memory. Use the tools. And to reply in one or two sentences. And then we've given it the tool read play specifically. By default, a sub agent will inherit whatever the main agent's tools are unless specified otherwise. So you can have it have a complete different set of tools or have the same ones. That's completely customizable and up to you. So here we go. If we take a look... Alright. There are five tool calls here. We see task, task, task. So this is for each act because I asked it to go through all five acts, and all of these ran in parallel. Each reader's subagent opened the play in its own context, read its act, and then sent back one sentence. So the main agent only ever sees these five sentences. It doesn't see all the other... What is going on today? It doesn't see all the other mess. And here we have the five sentence summaries. And if we take a look at the difference between the result with a sub agent versus without a sub agent, we can see that, okay. Yeah. The peak context without a sub agent is 64,000 tokens. Whereas with a sub agent, it stays at around 6,035. Even within this, roughly, as I mentioned earlier, 4,000 of those are just like the baseline harness. So you can see what a big difference it makes using a sub agent versus not, in terms of token usage, And you get the same result anyways. We're both just trying to see, you know, what happened in each of the five acts. So, yeah, that's one reason to use a sub agent, especially if you are doing a lot of long, deep research. You could have a sub agent per... If you were, writing a newsletter as my example earlier about, genres of music, you could have a sub agent per genre and just, like, filter through all of that. And that way, you keep your main agent clear and free to work on other things that actually require its tension. Okay. So that was a lot with Shakespeare's play, but let's say we wanna change the defaults. Deep agents is highly customizable, and that is what I love about it. Let's use the Emu War article, which I think is pretty fun. For context, this was essentially a war, I believe, by the Australian government where they were an invasive species, and it was a whole military, it was a whole military event. So I recommend you read more about it. I think it's kind of funny. But let... Let's do some research right now. So I I have my emu question. Read the emu war article. How many emus were killed before the gun jammed? This feels deeply unserious, but let's take a look. So I called the read emu war tool, which is what I had earlier. And on the 11/04/1932, during the ambush near a local dam where more than 1,000 emus approached, that's terrifying, the gun jammed after only 12 birds had been killed, allowing the rest of the flock to scatter before more could be shot. And we see here the peak context was 7,641 tokens. It... It's not going to trigger, any offloading tool, so we'll up... We'll lower that threshold so that we can take a look. Realistically, in real life, you know, a single article at around this number of tokens is fine. You wouldn't really need to execute any measures for context engineering. But if you were to pull in multiple of these articles, that's when you start having an issue because just one is fine. But if you have another 10 articles that are all 7,641 tokens just to find a bit of information, that adds up pretty fast. So it's also in context of not just the individual task you're working on, but overall how many things you'll need to look at. So now we can lower the limit to a thousand tokens by passing in our own file system middleware. So let's run this and... Yeah. Again, very simple. The same way we've added model and tools and back end, middleware here, file system middleware, we have set the limit to a thousand. Amazing. Alright. So now, again, we've called this tool to read our source, our data, and now it's looking for a jam because I asked about the gun jamming. And it has found... Again, same response. According to the EMEO article, during the ambush of the dam on the November 4, soldiers waited until the EMUs were closed, opened fire. 12 birds. But now to have 5,048 tokens, so it's lowered it from 7,641. And, again, as I said earlier, 4,000 of the tokens of this 5,048 are just from the base Deep Agent's harness anyways. So it's all of these small gains that you implement, if you're just mindful about it, can really help preventing that overall buildup. Okay. Great. So now let's take a look at summarization and summarizing sooner. So as I said earlier, the default is 85% of context. You don't have to stick to that. This is just something that we found tends to work best, but we can just make it summarize after 10 messages and keep the four most recent too. So, again, same thing. Super simple. You have your trigger so that your messages summarize once there are 10, and then you keep the four most recent. It's pretty intuitive. And the system prompt is, you're chatting about the emu war, reply in one or two sentences, and don't use tools. So let's take a look. I'm feeding it some information. This is all fake, but I'm preparing a five minute talk on the emu war for my team on Friday, as one does. And my favorite part is that the emu is basically one. And then here's just some more information. And now I'm going to ask, when is my talk and how long does it need to be? Okay. Let's take a look. And for context, let me see if there are So over here in the output, each turn will add two messages. Basically, mine and then the agent's reply. So here is that first message I was talking about. I'm preparing a five minute talk on the Amy War for my team on Friday. My agent thinks it's a snappy angle. And then you'll see around turn six here, we pass 10 messages because each turn adds two. And here, if you see this line specifically, it says model saw summary plus messages, and it's summarized. So what this means is that the model saw a summary in place of everything before message number seven and then the recent... So before message number seven and then the recent messages after it. The full history isn't lost. It's actually saved to a file under conversation history, and the agent can read it back if it needs to. But you'll see that despite all the chunk of information I gave it and all that it summarized because it went through all of this, it... When I asked when is my talk and how long does it need to be, it still remembered that my talk is scheduled for Friday and needs to be about five minutes long. And this is it seeing a summary before the thirteenth, like, most recent messages. Yeah. So that... This should have been the first thing that was gone from context, but the summary always records what the user is trying to do. So although it might seem counterintuitive to summarize some of the most earlier things because that might be where you're setting your goals or specific information that's really important, it doesn't actually go away. So it's a little smarter than that, and it knows to keep things like goals or specific projects or things that do actually need to remain within context. So you won't have to worry about losing important details, essentially. And if we see here, this is basically like that summary that the model sees. So instead of seeing the whole chunk of what I put in and the answers, it'll see this summary and then plus the messages that follow after. So this is just to let you see, like, what... What's going on behind the scenes. And... Yeah. So there are many different ways to set summarization. I just showed you how that works if you want it summarize after 10 messages instead of, for example, specifically 85% of the context window. You can also summarize when the topic changes. So, essentially, summarization tool middleware gives the agent a compact conversation tool, and we tell it to call the tool when the user switches topics. And then we'll pass a custom summary prompt, which controls what the summary keeps. Okay. Let's go through that. So here, we have summarized the conversation below in at most five bullet points. Keep the user's plans, deadlines, and decisions. Drop small talk. And here, we're gonna set it to something very high like 16, just so that it doesn't automatically fire on its own, and then we'll keep the two most recent messages. And then here, topic change, we've set a summarization prompt. When the user switches to a new topic, call contact conversation before you reply. So now it knows. As soon as there's a new topic, compress, summarize, and then we can move on. And it's the same thing. You just pass all of that in, summarization, topic change. And then I just wanna keep it concise, which is why I tell it to reply in one or two sentences. Okay. Did that run? Okay. Yes. And... Okay. Oh, and I think the only requirement is that... Hold on. Let me see. Did I miss something? Yes. Oh, and I've added this here. This is what the messages mean. This is just essentially the placeholder where the conversation gets inserted, and that is here. So here are a couple lines. I, again, start with, I'm preparing a five minute talk on the emu war for my team on Friday. More emu stuff. More emu. More emu. And then suddenly, new topic, can you suggest three Shakespeare comedies for a book club? And then going back to my talk for a second, when is it and how do I open it about the emu war? So, again, my response and my agent's response, and here, we can see we summarized at the topic change. I was talking about the emu, and then suddenly, can you suggest three Shakespeare comedies for a book club? There we go, and it's summarized. So as you can see, we can get it to summarize at a topic change, which is also very useful if you're completing multiple tasks at once in one session, and you just wanna close out the task that you're currently doing. You can just do that. So another very simple way... There's multiple ways you can customize summarization, whether it's token usage or conversation topic here. And summaries keep whatever the model said, mistakes included. So in one run, if the agent adds, like, a wrong date for, like, the gun jamming or something like that, that date is going to end up in the summary. So it's a good idea to keep your full history on file just so that you have this record and you can always check back again. But... Yeah. So, essentially, that was summarization. And if you wanted to see behind the scenes what the model actually saw in terms of the summarized part, here's where it is. And... Yeah. So, essentially, offloading saves large tool results to a file. You can change the limit, which is tool token limit before evict, and some agents read in their own context, so the main agent only sees the answers. And summarization replaces older messages with the summary. Change it when it happens with trigger and keep, and let the agent decide with summarization tool middleware and change what it keeps with summary prompt. I highly recommend you check out the Linkedin Academy deep agents course because there's actually so much more that we just simply cannot cover in a one hour session, and it goes into a lot of detail. But let me, I believe Jezell can send the link, or it might already be in the box with an assignment. Yes. I'm just gonna share my screen one more time really quick. Yes. But please make a copy of this. If you try to request edit access, that will be denied because if you can edit it, it's going to edit it for everyone. So please make a copy. Just click on file, make a copy, and the links will... Jezell have sent the links. And just to... Before you go, if you are interested in learning more about that first wave of defense that I mentioned at the beginning, I cover retrieval techniques in a workshop actually coming up next week. So retrieval, I would say, is the prequel to context engineering. It's how you make sure you gather the right information, whereas context engineering, a lot of it was dealing with the information that you already have. Yeah. And thank you so much for joining me. Here are a couple links, but, also, I believe Jezell is sending it in the chat. So I will let her take over now. Yeah. I just dropped it in the chat. It looks like... I'm taking a look at the the second poll question that I just launched at the end. I'm gonna put this on the screen. Do you wanna talk about it, Jess? I... Okay. Okay. I can scroll. After summarization, the agent needs an exact detail from early in the conversation that the summary left out. What can it do? Let me see. Nothing. Okay. I'll just go over it. Like, you can answer that. Nothing evicted messages are dropped once the summary replaces them. No. That would be pretty bad, just because we don't actually... A lot of the focus of context engineering is not to just actually delete everything. We just don't want it to be in the context window. It's totally fine if it's there somewhere floating around. We just don't want it to be exactly where it is. Think of it as, like, like, you you want... You wouldn't burn your textbook exam. Right? Like, you still want all that information there. You just don't need to memorize the entire thing for your exam. Ask the check pointer to replay the thread from its very first message. Call a built in expand summary tool to regenerate the full summary. Call refile... It's that last one. Call refile on the conversation history file, named in the summary. Yeah. Quite literally it. So everything is just sort of like a use the tool when it's necessary. So if you do need that full history again, call the refile tool. Go get what you need. But, otherwise, you can sort of leave it as is. Yeah. So if, sorry, I just saw what did you guys dress up as for Halloween. If anyone had some crazy tech related Halloween costumes, drop them in the comments. I'm always, eager to see more. Yes. I believe we've, finished that poll question. Alright. Awesome. Looks like most people got the answer right. Okay. Amazing. Great. Well, I am launching a feedback survey now, so please let us know how we did and just generally what kind of topics you'd be interested in learning about in the future. We actually launched today's session based off of feedback from previous workshops. So, definitely, you know, your your feedback does matter. And then I know we talk mostly about, like, content... Context management techniques here, but Jess Weng will be back next week to talk more about how these memories are retrieved and stored. And I have also dropped the link in the chat for that already, but I will drop it here again. So please come join us for that. And then one more thing. Make sure you tag us on LinkedIn if you feel like you learned anything useful and even if you didn't, maybe. And then use the hashtag hashtag l c a workshop. I will drop it in the chat here as well to let us know, like, what you learned, and then show us your take home assignment too. So we'll be keeping track of posts and raffling off a super, super secret prize. So TBD on that. And then, yeah, thank you all again for joining us today, and see you next week.