Compaction vs. Tool-Result Clearing vs. Persistent Memory
Three context-management primitives, three different bottlenecks. Which one your agent needs depends on whether dialogue, tool results, or cross-session knowledge is filling the window.
The short answer
What Each Primitive Actually Does
Compaction takes a conversation nearing the context-window limit, summarizes its contents, and reinitiates a new window with that summary. It requires an inference pass and is lossy on obscure specifics — high-level facts and decisions survive, fine detail doesn't.
Tool-result clearing removes bulky, re-fetchable tool results — file contents, API responses — while preserving the record that the tool was called. It's a server-side edit with zero inference cost. The tradeoff is a pure token/recall one: the agent must re-call the tool if it needs the cleared content again, but nothing is permanently lost since the underlying source is still fetchable.
Persistent memory is a file-backed store an agent writes to and reads from across separate sessions, not just within one long conversation. Quality depends entirely on the agent's own note-taking discipline — garbage notes in, garbage recall out.
Side-by-Side Comparison
| Dimension | Compaction | Tool-Result Clearing | Persistent Memory |
|---|---|---|---|
| Solves | Long dialogue nearing window limit | Tool-result token bloat | Cross-session knowledge persistence |
| Cost | One inference pass per compaction | None — zero-inference server-side edit | Tool-call overhead on every read/write |
| What's lost | Fine detail; high-level facts survive | Nothing permanent; re-fetch if needed | Nothing inherent; depends on note quality |
| Scope | Within one session | Within one session | Across separate sessions |
The Decision Rule
Diagnose which bottleneck is actually active before reaching for a fix. If tool calls — file reads, API responses — are the dominant source of token growth and the dialogue itself stays well within the window, clearing alone is often enough. Add compaction once the conversation itself, not tool output, starts approaching the limit. Add memory only when the agent needs to recall something after this specific conversation ends — a short-lived task agent that completes and terminates may never need it at all.
In practice, production agents commonly stack tool-result clearing and compaction together within a single session, with memory layered on separately for anything that must survive past it. Picking one primitive as a universal fix is the mistake — each solves a different bottleneck, not a different severity of the same problem.
For the full reference architecture — including sub-agent isolation, which sits alongside these three as a fourth, architecture-level pattern — see Context Engineering for Production AI Agents. For the documented failure modes this discipline exists to prevent, see How Long-Context Agents Fail.
Not sure which primitive your agent needs?
The wrong context-management choice shows up months later as silent quality drift, not a clean failure. Get the diagnosis right first.