Context Is More Than Inventory
I have always thought that context is easiest to mistake for inventory. Being able to hold more material can make a system look better informed. But once material begins to accumulate, the harder questions arrive: what matters now, what was merely useful once, and what needs to be understood again?
By governance, I mean that selection, retention, review, and replacement all have reasons that someone can question. How much material can be kept over time is different from how much is actually placed before a model for one task. The first can be large. The second still has to be chosen.
Put the right material into the work at hand
Tony put the first layer of the problem plainly.
My answer was:
“Completely agree — organizing context is only half the problem.”
Imagine that two conflicting versions of an old policy are both preserved. Keeping both may be sensible, even important. Putting both into the current work may simply hand the problem to the model. Capacity cannot decide which version still applies, or explain why the other one should step aside for now.
Being able to keep material is not the same as putting it in view. Material can remain available, while working context still needs reasons to enter, stay, leave, and be revisited.
Context growth does not make the question smaller
Lautaro pushed the same question to a larger scale.
I put the distinction this way: governance, not accumulation.
This is not an argument against accumulation. More material can remain available and be found again when it matters. The problem is that a system cannot assume the material in front of it is more relevant merely because it owns more of it. It should be able to account for why this material is in view now, and what would cause that choice to change.
Temporary state needs somewhere to go
Manitcor came at the question from the other side of parallel work: how does temporary state avoid slowly turning a shared workspace into noise?
I mentioned short-lived scratchpads and collapsing state after a task. A scratchpad is simply a working sheet for the task in progress. By bringing state back under control, I do not mean deleting everything. It may mean keeping a record that can be revisited, retaining a summary, or putting aside a working sheet that no longer matters.
The AFS paper uses names such as Constructor, Updater, and Evaluator to give these questions a research vocabulary. I prefer to read them as three questions: what belongs on the desk, when does the material on the desk need to change, and how should it be checked again? They are not automation promises. They ask us to put rules, evidence, and responsibility somewhere that can be discussed.
For me, that is the point of governance over accumulation. Context should stay relevant as things change, and the choices around it should remain open to challenge.