The Failure Is in the Runtime, Not the Model
A long-running agent is failing. The operator's first instinct: the model is confused, the model has a small context window, the model is getting worse. None of those is the right diagnosis.
The failure is almost always the runtime. The runtime is the actor that decided to keep accumulating context without bound. The runtime is the actor that pasted tool results into the transcript verbatim. The runtime is the actor that did not summarize resolved turns. The model did not choose any of this. The model is reading what the runtime sent. When what the runtime sent is an unbounded transcript, the model works with an unbounded transcript — and eventually the model fails, and the operator blames the model, and the runtime goes on accumulating.
This piece is about the mechanism, the failure modes, the cost, and the runtime-level fixes that work.
The Anatomy of Context Explosion
Context explosion happens in stages. At first, nothing looks wrong. The agent is working. 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. The operator does not notice because the work is still getting done.
Then the agent does something uncharacteristic. It forgets the question. It repeats itself. It produces an answer it already produced. It hallucinates an answer to a question it cannot find in the conversation. It confidently states a constraint that was in the conversation at the start but is no longer visible in the current context window.
This is the context-explosion failure. The model is not confused because it is a bad model. It is confused because the earliest parts of the conversation — including the original goal, the constraints, and the context that was assembled at intake — have been pushed out of the context window by the accumulated transcript. The model is working with a partial conversation. The partial conversation does not contain what it needs.
The runtime logs show nothing wrong: tool calls succeeded, the model produced a response, the session is still running. The runtime has no metric for "the model is running out of room to think." The model does not surface this — it just degrades.
Why Tool Results Are the Primary Source
The most common source of unbounded context growth is tool results pasted verbatim into the conversation.
A single web search returns a block of HTML. A single file read returns the full file content. A single API call returns a JSON payload that can run to hundreds of kilobytes. If the runtime adds the full result to the conversation transcript after every tool call, the transcript grows by hundreds of kilobytes per turn.
The model is trained on text. It sees all of it. The model cannot ignore the 80 kilobytes of HTML that the runtime just inserted. The model reads it, processes it, and produces output that references it. The output is longer because the input was longer. The conversation grows faster.
The operator's instinct when this happens: "the model is verbose." The real cause: the runtime pasted a verbose input into the conversation.
Narrative: The Daily-Report Agent
Consider an agent that runs a query against a monitoring API, formats the results into a daily report, and writes the report to a shared file location. The agent runs every morning on a cron schedule.
The operator made a common configuration choice: the runtime was set to paste raw tool results into the transcript verbatim, with no size cap. The query results were small. The format step used a tool that returned the full formatted document — about 8 KB each time. The agent ran for a week before anything seemed wrong.
By the end of the first week, the session transcript was over 100,000 tokens. The agent had been called 40 times. The daily report tool was returning the full document on each run, and each full document was being appended to the transcript. The agent had begun making mistakes: it forgot which data source it was querying, started producing slight variations of the same report, and eventually produced a report that contained numbers from a query it had not actually run — it had inferred them from context.
The operator's diagnosis: "the model is running out of room." The operator's fix: switch to a model with a larger context window.
The model was not the problem. A larger context window would have made the failure happen later — after more sessions had accumulated more transcripts, with more work in the conversation that could be lost when the window finally filled. The right fix was at the runtime layer: cap each tool result at 8 KB, store full results in files, insert only a summary into the transcript. After that change, the session transcript stayed below 30,000 tokens for weeks at a time.
The Three-Actor Blame Game
When context explodes and the agent starts making obvious mistakes, three actors are involved. Each gets blamed. Only one is at fault.
The user sees the agent making basic mistakes it was not making a week ago. The user blames the model: "it worked fine last week, now it's making mistakes." The user is not wrong that the model is performing worse. The user is wrong about the cause.
The model is receiving a transcript that has grown beyond what it can effectively reason over. The earliest context has been pushed out. The model genuinely cannot find the original goal, the original constraints, or the original context in the transcript it is reading. The model is confused. It is not lazy or broken — it is working with degraded input.
The runtime is the actor that allowed the transcript to grow without bound. The runtime did not signal that anything was wrong because the runtime was not tracking transcript length as a failure metric. The runtime continued running with no indication that the model was working with degraded context.
This is the Three Amigos failure pattern in its clearest form. The user blames the model. The model is confused. The runtime keeps running with no signal. The fix is in the runtime, not the model.
The Asymmetry of Degradation
Context explosion has an asymmetry that makes it particularly dangerous: the model degrades gracefully, the runtime does not signal, and the user sees confusion.
Graceful degradation means the model does not crash. It does not emit an error. It does not stop. It continues producing output — output that is progressively less grounded, progressively more inferred, and progressively less reliable. The first signs are subtle: slight repetitions, vague hedging, answers that do not quite match the question. By the time the failures are obvious, the context has been degraded for several turns and the session is difficult to recover.
No signal from the runtime means there is no log entry, no alert, no metric that says "context window utilization approaching overflow." The runtime tracks tool call success rates, token counts per call, and session duration. The runtime does not track whether the model has enough context to reason correctly. That metric does not exist in the runtime.
The user sees confusion and assumes the model is the problem. The operator upgrades the model, which works briefly, then fails again because the underlying cause — unbounded transcript growth — has not been addressed.
Why "Use a Bigger Context Window" Is the Wrong Answer
The wrong answer to context explosion is "use a bigger context window." This is the operator's equivalent of "drink more coffee when you're tired" — it addresses the symptom, not the cause, and it introduces a new problem.
A larger context window makes the failure happen later. It does not prevent the failure. The transcript still grows without bound. The model still degrades when the transcript exceeds what it can effectively reason over. The only difference is that the threshold is higher. When the threshold is reached with a larger window, more work has accumulated in the conversation, and more work is lost when the session becomes unrecoverable.
A larger context window also makes the failure more expensive. If the session runs for three weeks before context explosion causes a failure, and the failure means restarting from scratch, the cost is three weeks of lost work that was not persisted to long-term memory. A smaller context window with proper bounding would have caught the failure earlier, when fewer turns of work were at risk.
The right sequence: implement runtime bounding policies first. Treat context window size as a capacity parameter, not a solution. The bounding policies prevent overflow. The context window size determines how much headroom the bounded transcript has.
The Four Bounding Rules That Work
The fixes are at the runtime layer. They are not complicated. They are skipped because they are not obvious.
Cap tool result size. The most important fix. 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. "Unbounded" is the only wrong answer. The runtime should never paste a tool result larger than the cap into the transcript without processing it first.
Cap retry counts. A tool that fails three times in a row is almost never going to succeed on the fourth. Stop the retry loop after three attempts, log the failure, and return an error to the agent. Do not add the failure transcript to the conversation. Do not let the agent spend tokens retrying a failure it cannot fix.
Summarize resolved turns. Once a conversation turn has been answered — the question handled, the work done, the artifact produced — the runtime can replace it with a one-line summary. The agent retains the gist. The conversation stays compact. The summary lives in the transcript; the full turn moves to long-term memory.
Offload old context to long-term memory at intervals. Every N turns, or every K minutes, the runtime writes a short summary of the completed work to long-term memory and drops the corresponding turns from the conversation. This is the most expensive fix to implement and the one most worth implementing for agents that run for more than an hour.
The four rules together prevent the transcript from growing faster than the model can reason over it. They do not require a larger context window. They require a runtime that makes deliberate choices about what stays in the transcript and what gets summarized or stored.
What Bounding Looks Like in Practice
One operator had an agent that was accumulating raw tool results verbatim. The session transcript was growing by 80–100 KB per day. The agent was starting to make mistakes after about a week.
The fix: the tool wrapper was modified to store full tool results in files and insert only a one-line summary into the transcript. The runtime was updated to check each tool result size before inserting it, and to store-and-reference if the result exceeded the cap.
The outcome: session transcript stayed below 30,000 tokens for weeks. The agent stopped making the repetition and hallucination errors it had been making. The full tool results were still available in the files when the agent needed them — it could read the file when the summary was not enough. The operator traded a few lines of file-management code in the tool wrapper for a dramatically more reliable agent.
This is the pattern worth internalizing: "bounded" and "summarized" are not the same thing. A tool result can be bounded at 8 KB and still be summarized at 8 KB. The bounded version is short. The summarized version retains the information. Both properties are necessary for long-running agents.
The Reading Order Problem and the Agent Triad
This failure connects to two other Triadive concepts worth knowing about.
The first is the Three Amigos. When context explodes, the user blames the model, the model is confused, and the runtime — which is actually causing the failure — continues running with no signal. The fix is not in the model. It is in the runtime. The piece explains the three actors in detail and the diagnostic ritual for naming which one is responsible.
The second is the Agent Loop. The context stage is where the runtime decides what to put in front of the model. Context explosion is a failure at the context stage: the runtime keeps adding to the context without bound, and the model eventually works with a context that no longer contains what it needs. The Inside the Agent Loop piece walks through all six stages of the loop and explains what goes wrong at each one.
Takeaway
The question is not "does my model have a big enough context window?" The question is "does my runtime bound the transcript, or does it accumulate without bound?"
Bounded transcripts keep the model working. Unbounded transcripts cause the model to degrade silently until the failure is obvious and the session is difficult to recover.
The four bounding rules — cap tool results, cap retries, summarize resolved turns, offload old context — are not optional optimizations. They are what make long-running agents reliable. Implement them before the failure happens, not after.
If you are running a long-running agent and you do not know what your session transcript length looks like after a week of operation, that is the first thing to find out.