A developer diagnoses a GitHub Copilot agent with context bloat: the agent is accumulating the full text of every file it reads into its working context, causing token costs to spike and later reasoning steps to degrade as earlier instructions get pushed out of the context window. Which memory refinement strategy best addresses this problem?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Context bloat is like a backpacker stuffing every item they encounter into a single pack — eventually the weight slows everything down and the important stuff gets buried. The fix is to travel light: summarize what you need from each file, drop the raw content, and keep the context focused on facts that still matter for the next step.
Full explanation below image
Full Explanation
Context bloat occurs when an agent accumulates more information in its working context than it needs, causing two interrelated problems: increased token costs (every API call is more expensive) and degraded reasoning quality (the model loses access to earlier parts of the context as new content pushes it out of the window).
Option B is correct because it addresses the root cause directly: the agent is retaining full file text when it only needs extracted information. By instructing the agent to summarize or extract key facts immediately after reading a file and then discarding the raw text, the working context stays compact and focused. This is the standard memory refinement pattern for read-heavy agentic tasks.
Option A (larger context window) treats the symptom rather than the cause. Expanding the window delays but does not eliminate the bloat problem. Costs continue to grow with each additional file read, and the fundamental inefficiency remains.
Option C (limit files read per task) constrains the agent's capability as a workaround. This may cause the agent to fail tasks that legitimately require reading many files. The problem is not how many files are read but how much of each file is retained.
Option D (gzip compression) is not applicable to LLM context management. The model processes text tokens, not binary data. Compressed content cannot be understood by the model and would need to be decompressed before use, resulting in no net savings.