Bigger context windows do not make AI agents better — a study of 18 frontier models found they all got less reliable as the window grew (context rot), and better agents often require less context, not more.
Searchable transcript of Context Engineering for AI Agents: 4 Failure Modes to Avoid — IBM Technology (10:21). Search for a phrase, then click its timestamp to jump straight to that moment in the video.
Captions sourced from the original video on YouTube, published by IBM Technology. The video, its captions and all related intellectual property remain the property of their respective owners; AINotes claims no ownership. Provided for research, accessibility and search — see the Transcript Notice and Copyright Policy.
00:00 Context windows have grown from, well, a few thousand tokens to, well a lot bigger, like a million or more. And that's room for more stuff, more instructions, tool results, docs, you name it. So, if we think about AI agents, and we give them access to this big old context window, well, they should probably be get, getting better at long running tasks, shouldn't they?
00:33 I mean, the more context, the better job they can do. Well, a recent study looked at 18 frontier models and it turned out that they all got less reliable as the context window got bigger. Researchers have taken to giving this thing a name, and that is context rot. The more tokens in the window, the less reliably the model uses any of them. And this is the problem that context engineering is there to solve.
01:05 Context engineering is deciding what actually goes into this context window at each step of an agent's run. Now there are many ways an agent context can go wrong and I'm going to cover four of them, the four failure modes that you can encounter when working with these big context windows. And because I feel nice, I will also suggest how to fix each one.
01:31 And the funny thing about those fixes is they involve deliberately throwing away information. So how does an agent get better by holding less context? Well, to answer that, we should first take a look at what's actually filling up these giant context windows. So let's say an AI agent was given the job to migrate an aging code base over to a new database driver.
01:58 So I'm talking about here, we are building a migration AI agent. Now, at the beginning of the context window, the first thing most likely in here, is the system prompt. That's the standing instructions for how the agent operates in general. Now the agent task itself, that will also be stored in here as well, just as a prompt on its own. And it might not be very big, it might only be a couple of lines.
02:30 Then, many agent harnesses also pull in a bunch of project instructions. Now these are things like an agents.md file explaining how this particular project is built. Then after that, we might have some tool definitions, a description of every tool the agent can call. And from here on in, the context window turns into a bit of a running log. So we're going to have a message history here.
03:01 This is every step the, the agent has taken. And, after let's say an hour of running, well, this could get pretty big. That's going to be a lot of steps. And then the biggest band is probably the tool results that we store here. Which is things like file contents and test output and error logs and schema dumps. So, the job description, the prompt, is a few lines near the front and pretty much everything else is the stuff that the agent kind of piles up along the way.
03:33 Oh, and buried in this as well, there happens to be a note. This is a note the agent wrote itself, it says that the new driver retries failed connections automatically, so the old retry code can be deleted. So the note just basically says, "Hey, don't bother with writing any retry codes." Why do I mention that? We'll come back to that. Anyway, why is a full context window a problem?
04:03 Well, a model doesn't look things up in its context the way a database looks up a row. Every token in the window is competing for a finite amount of attention. Essentially, an attention budget, and to me, this is kind of the crux of it. The window might hold a million tokens, but the attention spread across those tokens is finite. Now, what about those failure modes?
04:34 Let's start with the first one. Number one, that is context poisoning. So I cryptically mentioned the agent wrote itself a note about the new driver retrying failed connections automatically. Well it turns out that that note, is completely wrong. The agent shouldn't have done this. It basically skimmed the driver's documentation, it misread it and then it's written down a false conclusion and that's all poisoning is.
05:00 A mistake gets into this context window somewhere and then gets treated as fact because to the AI model, its own notes, they look like the ground truth. So, file after file our agent has been deleting perfectly good retry code. Next, number two. That is context distraction. This is where the sheer size of the history starts steering the agent. Now, a language model at its heart is just a pattern continuation machine.
05:34 And when the context holds at, say, an hour of an agent's own past actions, that history becomes pretty much the strongest pattern around, stronger than the reasoning it picked up in training. So... instead of asking what the job needs next, the model might drift into doing more of what is already done in this message history. Agents in this state can get stuck just kind of going over old ground.
06:00 What about number three? And that is context confusion. And this one comes from the tools. Our agent here is wired into quite a lot of stuff. There's probably some amount of version control here. It might be access to a database console, maybe it also is logging tickets into a ticketing system. And each of these tool definitions is in the window, whether it actually gets used or not.
06:33 And having more of them makes choosing the right tool a bit harder. And in one benchmark, a model failed a task when it was offered 46 tools, but it then passed the very same task, when it was only offered 19 tools. That is tall sprawl at work. Okay, number four. That is context clash, which is when the window contains information that disagrees with itself.
07:02 So take that note with the bad information. At some point, our agent is gonna see that no retries are happening, and it's gonna figure out that that note was wrong. And it will probably make a note of that into its message history as well. But the problem then, is we now have both versions sitting in the window that are presenting conflicting information.
07:22 So these are four different ways a context window can go bad. All right. So what about some potential fixes? Well, for poisoning, one of the fixes is to ...validate. Before a conclusion gets written down into this context window, check it against something real. So one quick connection test and our agent would never have written this new retry code note.
07:53 What about... distraction? Well, the fix there is really to compact. When the history gets really, really long, the agent can summarize it, which is to say it throws the full log away and starts again from the summary, a shortened version of what was in this message history in the window. Now, compaction is lossy. A summary of the summary can start to drift like a photocopy of a photocopy.
08:22 Consider moving as much out of the context window as possible and put them into permanent files instead. Detailed information can be retained in those files, and then it can be pulled into the context window only when it's actually needed. All right, what about context confusion? Well, that is a curation problem. So the fix is to ... curate. The agent doesn't need 46 tools for database migration, so just give it the handful that the job calls for and then it can always go and fetch others if it actually needs them.
09:02 Then finally context clash, well the fix there can be to prune. So when information gets superseded, just delete the old version, rather than leaving both in the window. We could have deleted this guy entirely. Or go further and start a fresh window, just restating the current corrected state of the job, and leave the poison stuff behind. So if a false conclusion gets saved, that's poisoning.
09:32 So you can validate if the history has taken over, that's distraction, so compact, if the agent has more tools than the task needs, that's confusion, so curate. And if the context disagrees with itself, that is a clash, and the fix is prune. And all four fixes work by throwing something away. An agent can get better at long tasks, by holding less. Now I'd love to know how you keep an agent's context lean, do you have your own context-engineering fixes? Let me know in the comments!