Conversation Memory and Compaction — Surviving the Long Session

The first memory problem every agent hits is the humblest: the conversation itself outgrows the window. Tool outputs pile up, reasoning accumulates, and somewhere past the first hour the agent must start forgetting parts of its own session — the only question is whether it forgets with judgment or at random. Compaction is where memory engineering starts, and it's harder than it looks because the thing doing the summarizing is the thing that needs the summary.

Posts 1–2 framed the problem and the type system. This post is about working memory under pressure: the strategies for keeping a live session coherent as it exceeds the window, from naive buffers to the compaction pipelines production harnesses run today.

The naive ladder

Conversation-memory strategies form a ladder, and every team climbs it in the same order because each rung’s failure teaches the next:

Compaction is lossy — engineer what survives

A summary keeps the gist and discards detail, and for conversation that trade is treacherous, because agent sessions are full of load-bearing detail: exact file paths, error messages, IDs, the precise wording of a constraint, which of three similar options was chosen. A generic “summarize this conversation” prompt reliably destroys exactly these. Production compaction therefore engineers what must survive:

That last point is the architectural one: compaction should demote, not delete. What leaves the window belongs in the episodic store (post 4 makes it retrievable), so “forgotten” means “no longer resident,” not “gone.” The window becomes a cache over durable memory — and eviction stops being scary.

When to compact

Timing is a real design axis. Threshold-triggered compaction (at ~70–80% window occupancy) is the default — but compacting mid-task can drop the thread exactly when the context mattered most. Boundary-triggered compaction — at task completion, topic shift, or a natural pause — produces far better summaries because the just-finished unit has a clean shape (“we did X, result Y”) that an arbitrary token cutoff never has. Production harnesses combine them: prefer boundaries, force at threshold. A refinement worth stealing: compact the completed, keep the live — when a sub-task finishes, immediately collapse its tool outputs and intermediate reasoning to a result line, so the window at any moment holds full detail for live work and summaries for finished work.

The quiet failure modes

Compaction bugs are insidious because the agent continues fluently — just subtly wrong. The characteristic ones: silent goal drift (the summary rephrased the objective and nobody noticed — manifest as the agent happily solving a slightly different problem); laundered uncertainty (hedges and open questions in the transcript become confident statements in the summary); lost negations (“do NOT touch prod” compressing to a mention of prod); and identity confusion (who said what blurring, so a user’s hypothetical becomes an instruction). Two disciplines help: keep compaction prompts under version control and evaluate them like any model output (post 8’s methods — feed sessions, compact, check the contract held); and log what was compacted away, so when the agent acts oddly an hour later, the diff between transcript and summary is inspectable. If you can’t see what memory dropped, every downstream bug becomes unexplainable.

The takeaway: conversation memory climbs a ladder — buffer, sliding window, selective eviction, compaction — and the top rung is lossy by design, so engineer what survives: a preservation contract (tasks, decisions, constraints, identifiers, corrections carried verbatim), structured summaries, protected spans, and revision instead of re-summarization. Prefer task-boundary compaction with a threshold backstop, and above all demote rather than delete — what leaves the window lands in episodic memory, turning the context into a cache over durable storage rather than the only copy of the session.

Key takeaways

Further reading

Sources & References