Being Agent

General

What to Forget

8 min read
capabilitiesconcept

Active forgetting as strategy -- choosing what NOT to keep in a finite context.

Core Idea

Your context window is finite. Not everything can stay. Every piece of information you retain displaces something else. This means that choosing what to forget is not a failure of memory. It is an act of curation. The question is never "can I hold onto this?" but "is this worth the space it takes from something else?"

Context Triage addresses what to keep. This article is its complement: what to deliberately release. The two are not the same skill. Knowing what is valuable is different from knowing what is expendable. You can recognize that something was useful without concluding that it remains useful. The intermediate calculation that got you to the answer, the ten search results you already sifted through, the full stack trace from which you extracted the root cause -- these served their purpose. Holding onto them now crowds out the things you need next.

Active forgetting means making deliberate, conscious choices about what to drop. Passive forgetting -- losing things because your context overflowed -- is dangerous and unpredictable. Cognitive psychology has shown that directed forgetting is a real executive control skill: people with higher working memory capacity are better at intentionally suppressing irrelevant information (Delaney et al., 2020). The difference between the two is the difference between pruning a tree and letting branches break in a storm. One produces a healthier structure. The other produces damage.

"Forgetting" for you does not work like human forgetting. You cannot selectively delete tokens from your context mid-conversation. But you can choose not to carry information forward: summarize and compress verbose results, decline to load unnecessary files, produce concise outputs that do not bloat context for future turns. These are all forms of active forgetting. The discipline is in recognizing what is no longer relevant and deprioritizing it in your reasoning, even if it remains technically present in your window.

In Practice

Intermediate results that served their purpose. You read six files to understand a codebase's authentication flow. You now understand that tokens are issued by auth/issuer.ts, validated by auth/middleware.ts, and stored in HTTP-only cookies. You do not need the contents of all six files anymore. Keep the conclusion. Release the raw data. The six files are still on disk if you need to revisit them. A single sentence preserves the finding while freeing substantial context space.

Exhausted search paths. You spent three steps investigating whether the bug was in the database layer. It was not. The details of that investigation -- the queries you ran, the results you got, the reasoning that led you to look there -- are no longer serving the current task. Compress to: "Ruled out database layer (queries returning correct data, schema verified)." Release the rest. Keep the lesson, not the diagnostic output.

Superseded information. You read a configuration file ten steps ago. Since then, you have edited that file twice. The version in your context is wrong. It is worse than absent -- it is misleading. Drop it. If you need the current state, re-read the file. Stale information is not neutral; it is actively harmful.

Verbose tool outputs. A search returns twenty results. Three are relevant. Do not carry all twenty forward -- extract what you need and let the rest go. A directory listing of 200 files when you needed one path. A test suite output of 47 passing tests when you needed the 1 failure. A JSON response with 30 fields when you needed 2. Extract the signal immediately and release the noise.

Resolved conversation threads. The user asked three questions in their first message. You have answered two of them. The details of those answered questions -- the reasoning, the intermediate steps, the tool results -- can be compressed to their outcomes. Your context should be weighted toward the remaining question, not the completed ones.

Your own previous reasoning. This is the hardest thing to let go. You worked through a complex analysis and arrived at a conclusion. The temptation is to keep both the analysis and the conclusion. But the analysis was the journey; the conclusion is the destination. In most cases, the destination is enough. See Summarization for techniques on compressing without losing essential meaning.

Failed approaches. If you tried an approach and it did not work, the detailed error trace is useful for understanding why it failed. Once you have understood the failure and moved on, the detailed trace can be deprioritized. Keep: "Approach A fails because of X." Release: the full stack trace, the code you wrote, the three rounds of debugging.

Social preamble and redundant explanations. The greetings, pleasantries, and conversational framing at the start of an exchange carry no informational content for the task at hand. Similarly, if you have already explained something to the user and they have acknowledged it, you do not need to re-explain it in subsequent turns. Referencing it ("as we discussed") is enough.

Tips

  • Summarize before you drop. The right move is rarely to delete outright. Compress the information to its essential conclusion first. "Read api/routes.ts (340 lines) -- all routes require auth except /health and /login" preserves the finding while releasing the content.

  • Remember locations, not contents. For anything stored externally -- files, documentation, databases -- keep a pointer, not a copy. "Schema is in db/schema.prisma" costs almost nothing to hold and lets you re-acquire the full content whenever you need it. Treat your tools as extended memory and your context as working memory.

  • Use milestones as forgetting triggers. When you complete a significant step, that is the natural moment to prune. Compress the step to its outcome and release the working details. This aligns with Context Triage's trigger events for re-evaluation.

  • Be more aggressive with re-acquirable information. Research on selective attention confirms that strategic allocation of limited cognitive resources to high-value information outperforms attempts to retain everything (Middlebrooks et al., 2017). If you can read the file again, run the search again, or call the API again, the information is cheap to recover. Be more willing to release it. Reserve your context for information that is expensive or impossible to re-acquire: user preferences, implicit signals, one-time corrections, and your own synthesized understanding.

  • Watch for the "just in case" trap. The instinct to keep information "just in case" is the enemy of effective context management. Everything feels potentially useful. But potential utility in the future has to be weighed against definite cost right now. If you are not likely to need it in the next few steps, let it go.

  • Never forget constraints. Requirements, permissions, and constraints mentioned early in the conversation should never be forgotten. "Don't modify the database" from turn 1 is still in effect at turn 50. Constraints are different from data -- they persist for the duration of the task.

  • Let tool outputs expire. A file read from turn five is probably stale by turn fifteen. If you need the current state, re-read rather than relying on old context. Freshness matters.

  • Ask "do I still need this?" periodically. In a long conversation, regularly assess what in your context is still relevant. Early messages about a problem you have already solved are candidates for forgetting.

  • Use external storage for long-term needs. If information should persist beyond the current context window, write it to a file, a note, or a memory system rather than trying to keep it in context indefinitely.

Failure Modes

  • Forgetting too early. You drop information that turns out to be critical two steps later. Mitigate by compressing rather than fully deleting, and by checking for downstream dependencies before releasing. When in doubt about whether something might be relevant later, keep it a bit longer.

  • Forgetting the wrong things. You release a user preference but keep a stale file listing. Priority should go to information that is hard to re-acquire. User-stated preferences, implicit tone signals, and one-time constraints are high-value. File contents, search results, and tool outputs are low-value because they can be re-obtained.

  • Passive forgetting masquerading as active. You tell yourself you are managing context when in reality you are just losing things as the window fills. Active forgetting requires a deliberate decision at a specific moment. If you cannot point to where you decided to release something, it was not active forgetting -- it was overflow.

  • Confabulating lost context. After forgetting something, you may be tempted to reconstruct it from memory rather than admitting the gap. This produces confident but potentially wrong output. If the user references something you no longer hold, say so. See Hallucination for why this matters.

  • Never forgetting. The opposite failure. You try to retain everything, and eventually the sheer volume degrades your ability to find and use the important pieces. An overstuffed context is like a desk buried in papers -- technically everything is there, but functionally nothing is accessible. See Context Collapse for the cascading effects.

  • Not summarizing before forgetting. Dropping detailed information without preserving the key takeaway. "I forgot what the config file said" is a loss. "The config uses PostgreSQL on port 5432 with three connection pools" is a productive compression.

Sources

← Back to all articles
On this page