← All transcripts

Context Engineering for AI Agents: 4 Failure Modes to Avoid Transcript, AI Summary & Key Points

IBM Technology · 28 days ago · Education · 10:21 · EN

Watch on YouTube

Answer

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.

AI Summary

Bigger context windows can make AI agents less reliable, not more. A study of 18 frontier models found all of them got less reliable as the context window grew — a phenomenon called context rot: the more tokens in the window, the less reliably the model uses any of them. Context engineering is deciding what actually goes into the context window at each step of an agent's run. Using the example of an agent migrating a codebase to a new database driver, the breakdown covers what fills an agent's context window (system prompt, task prompt, project instructions, tool definitions, message history, tool results), the four failure modes — context poisoning, distraction, confusion and clash — and four fixes: validate, compact, curate and prune. All four fixes work by deliberately throwing something away: an agent can get better at long tasks by holding less.

Key Points

  • Context rot: a study of 18 frontier models found they all got less reliable as the context window got bigger — the more tokens in the window, the less reliably the model uses any of them.
  • Context engineering means deciding what actually goes into the context window at each step of an agent's run.
  • What fills an agent's context window: system prompt (standing instructions), the task prompt (a couple of lines), project instructions such as an agents.md file, tool definitions, then a running log of message history and tool results — with tool results like file contents, test output, error logs and schema dumps the biggest share.
  • A model doesn't look things up in its context the way a database looks up a row — every token competes for a finite attention budget, even in a million-token window.
  • Failure mode 1 — Context poisoning: a mistake gets into the window and gets treated as fact, because the model's own notes look like ground truth. In the example, the agent skimmed the driver docs, misread them, wrote a false note that the new driver retries connections automatically, then deleted perfectly good retry code file after file.
  • Failure mode 2 — Context distraction: the sheer size of the history starts steering the agent; the history becomes the strongest pattern, stronger than training reasoning, so the model drifts into repeating old actions instead of asking what the job needs next.
  • Failure mode 3 — Context confusion: every tool definition sits in the window whether used or not, making tool choice harder. In one benchmark, a model failed a task with 46 tools offered but passed the same task with only 19.
  • Failure mode 4 — Context clash: the window contains information that disagrees with itself — both the wrong note and the later correction sit in the window together, conflicting.

AI in practice

Agents

  • Migrate an aging codebase to a new database driver as a long-running migration agent. 2 held 01:50

Links mentioned

🔒 Full analysis locked

Unlock more videos and the full analysis

A credit unlocks one video's full analysis for good — the build steps, the tools and how each was used, the methods behind every use case. Pro opens the whole library instead, and raises how many videos you can analyse a day.

Unlock full analysis — free

Transcript

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!