The lesson, in one sentence

An unbounded agent loop will eventually consume the entire context window, and the failure mode is silent until it isn't.

What it looks like in practice

The agent is working. The agent has been working for a while. Tool calls succeed, tool calls fail, the model retries. Each retry adds text to the conversation. Each tool result adds text. The session transcript grows. Nothing seems wrong.

Then the agent does something uncharacteristic. It forgets the question. It repeats itself. It hallucinates an answer it already had. It claims to have done something it hasn't done.

This is the context-explosion failure. The model's context window is full, and the middle of the conversation — including most of what the agent was supposed to remember — has been pushed out.

Why the runtime is to blame, not the model

It is tempting to think "the model just has a small context window" or "the model is getting confused." Both are wrong. The model is doing exactly what it was trained to do. The runtime is the actor that decided to keep accumulating context without bound.

A well-behaved runtime bounds context growth in three places:

1. Tool result size. A tool call that returns 80 KB of HTML should not be pasted into the conversation verbatim. Summarize, trim, or store-and-reference instead. 2. Retries. A tool that fails three times in a row is almost never going to succeed on the fourth. Stop the retry loop, log the failure, and ask the user. 3. Old turns. Once a conversation turn has been "answered" or "resolved," it can be summarized. The summary stays in the conversation; the full transcript can move to long-term memory.

These are runtime decisions. The model can't make them. The model sees what the runtime sends. If the runtime sends an unbounded transcript, the model will use the unbounded transcript — and eventually the model will fail, and the operator will blame the model, and the runtime will go on doing what it was doing.

How the failure hides

The dangerous part of context explosion is that it doesn't show up in logs. From the runtime's perspective, everything is working:

  • Tool calls succeed. ✅
  • The model produces a response. ✅
  • The conversation continues. ✅

The runtime has no metric for "the model is running out of room to think." The model also doesn't surface this; it just degrades.

The first visible signal is usually user-visible: the agent forgets, repeats, hallucinates. By that point, the context is already past the point of easy recovery. The agent has lost the thread, the conversation has to be restarted, and the work in the session is gone unless it was saved to long-term memory earlier.

The small bounding rules that help

The fixes are not complicated. They are boring, and they are at the runtime layer, and that's why they're often skipped.

Cap tool result size. A reasonable first cap is 8 KB per result, with a runtime choice to summarize or store-and-reference anything larger. The exact number depends on the model's window and the kind of work, but "unbounded" is the only wrong answer.

Cap retry counts. Three retries on the same tool call is usually enough. Past three, the agent is wasting context on a failure mode it doesn't understand.

Summarize resolved turns. Once a turn has been handled — the question answered, the work done — the runtime can replace it with a one-line summary. The agent still has the gist. The conversation stays compact.

Move old context to long-term memory at intervals. Every N turns, or every K minutes, the runtime can write a short summary to long-term memory and drop the corresponding turns from the conversation. This is the most expensive of the four fixes and the one most worth doing.

What this looks like from the operator's chair

If you are running a long-running agent and you suspect context explosion:

1. Check the session transcript length. If it's growing without bound, you have the bug. Find the runtime's transcript-storing code. 2. Check tool result sizes. Sort tool calls by result size. The largest few are usually where the explosion comes from. 3. Check retry counts. Look for any tool that has been called more than three times with the same arguments. That's a candidate to be capped. 4. Add one bounding rule. Pick the one with the lowest cost to implement. Cap a single tool's result size, or cap retry count on one class of failure. Ship it. Measure.

You don't need to fix all four at once. You need to fix one and verify the agent still works. Then the next one.

What this lesson is not

This lesson is not "use a bigger context window." Bigger context windows make the failure happen later, not less. They also make the failure more expensive when it does happen, because more work is in the conversation that gets dropped.

This lesson is also not "use a smarter model." Smarter models sometimes surface the failure better — they ask for more information instead of hallucinating — but they don't prevent it. The runtime is the actor that bounds the work. Smarter models just make the bounds more useful when the runtime enforces them.

A note on the human / agent / robot triad

When the context explodes and the agent forgets the question, the user blames the agent. The agent blames itself. The runtime, which actually caused the failure, keeps running with no signal that anything was wrong.

This is one of the cleanest cases of the three amigos showing up in practice. The fix isn't in the model, and it isn't in the user. It's in the runtime. Every agent operator should be able to find their runtime's transcript-length cap in under a minute. If they can't, that's the bug to fix first.