After deploying a long-running research agent, you notice it consistently fails with a context window overflow error after approximately 50 tool calls. Inspection shows the agent appends every tool result in full to its running context and never removes or compresses any of it. Which remediation best solves this problem?
Select an answer to reveal the explanation.
Short Explanation and Infographic
An agent that never forgets anything will eventually forget everything — because its context overflows and crashes. It's like a notebook with no room for new pages. The fix is active memory pruning: summarize old results, discard what's no longer needed, and keep the working context lean. A bigger notebook is a temporary workaround, not a solution.
Full explanation below image
Full Explanation
Unbounded context growth is one of the most common failure modes in long-running agentic systems. When every tool result is appended to the context in full and nothing is ever removed, the token count grows linearly with the number of tool calls until it exceeds the model's maximum context length.
Option B is correct: the agent needs an active memory management strategy. This typically involves one or more of the following: (1) Summarization — after a step or group of steps completes, replace the raw tool outputs with a compact summary; (2) Pruning — discard tool results that are no longer relevant to the current step; (3) Offloading — move detailed results to an external store and only bring them back into context when explicitly needed. This keeps the working context window manageable regardless of how long the session runs.
Option A is a common but misguided response. Switching to a model with a larger context window delays the problem but does not solve it. If the agent appends without pruning, it will eventually overflow any context window — just at a higher tool call count. This is a design fix, not a hardware upgrade.
Option C is incorrect: the number of tools available is not the issue. The problem is how tool results are handled after each call, not how many tools exist. Reducing available tools would cripple the agent's capability without addressing the memory architecture.
Option D is incorrect and counterproductive. Capping at 50 calls and restarting from scratch reintroduces the resumability problem (q021) and provides no benefit over the current behavior — the agent already fails at 50 calls. The restart would also lose all progress, starting the session over at step one. The goal is to handle arbitrarily long sessions gracefully through pruning, not to institutionalize the failure point.