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
An agent that never forgets anything won't stay alive; its context overflows and crashes. It's like a notebook with no room for new pages. You fix it by actively pruning memory: summarize old tool results, discard what you no longer need, and keep the working context lean.
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.
The correct remediation is implementing memory pruning by summarizing or discarding older tool results once they are no longer needed for the current task step. This gives the agent an active memory management strategy. This typically involves one or more of the following: summarization — after a step or group of steps completes, replace the raw tool outputs with a compact summary; pruning — discard tool results that are no longer relevant to the current step; 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.
Increasing the model's context window by switching to a model with a larger token limit is a common but misguided response. It 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.
Reducing the number of tools available to the agent so fewer tool calls are made per session 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.
Adding a hard limit of 50 tool calls per session and restarting the agent from scratch after the limit is reached is incorrect and counterproductive. Capping at 50 calls and restarting from scratch reintroduces the resumability problem 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.