TPEE Toptronic® Prompt Engineering Editor

116. Revisiting Context 3 - Compaction, Summaries and Memory

When the window fills: what to compact, what to keep verbatim, and how to write state a later turn can trust.

By Jacques Botte, founder of Toptronic®. Last updated 17 October 2026.

The lesson

Compaction is the act of replacing material with something shorter that preserves what the next turn needs. It is not summarisation for a reader; it is state reduction for an actor. The test is operational: after compaction, can the next turn still do the work it was going to do, without re-reading the original? If not, the compaction destroyed the thing it was meant to preserve.

Keep four things verbatim, always. Identifiers - file paths, function names, order references, keys - because a paraphrase of an identifier does not resolve. Exact figures with their units and currency. Quoted error messages and quoted requirements. And any instruction whose wording matters, such as a format or a refusal rule. Everything else is a candidate for compression.

A good compaction has a fixed shape, so that the next turn knows where to look: what the task is, what has been established as fact, what has been decided and why, what is still open, what has been tried and failed, and what the next action is. Six headings. A summary without the failed attempts is the most expensive omission, because the next turn will cheerfully try them again.

Memory across sessions is a different problem with a different rule. Write DECLARATIVE facts, not instructions to a future self: this machine has this tool, this file owns this behaviour, this convention was chosen for this reason. An imperative note written in one session is re-read in another as a command, and a command from a past self can override the live request. The distinction sounds fussy until the first time it costs you an afternoon.

And keep the compaction honest about its losses. If a detail was dropped, say that a detail was dropped and where the original lives. A summary that silently omits is a summary that will be trusted wrongly, and the failure will surface three turns later as a confident answer about a project that no longer matches the disk.

Check yourself

Question 1: What is the operational test of a good compaction?
  1. It is shorter than the original
  2. The next turn can still do its work without re-reading the original — correct
  3. It reads well
  4. It uses fewer headings

Answer: The next turn can still do its work without re-reading the original

Compaction is state reduction for an actor, not summarisation for a reader. If the work needs the original back, the compaction failed.

Question 2: Which list must stay verbatim?
  1. Background narrative
  2. Identifiers, exact figures with units, quoted errors and quoted requirements, and wording-sensitive instructions — correct
  3. Everything - never compact
  4. Only the task statement

Answer: Identifiers, exact figures with units, quoted errors and quoted requirements, and wording-sensitive instructions

A paraphrase of an identifier does not resolve, and a rounded figure is a different fact.

Question 3: Why should memory entries be declarative facts rather than instructions?
  1. They are shorter
  2. An imperative note is re-read later as a command and can override the live request — correct
  3. Facts are easier to translate
  4. Instructions cannot be stored

Answer: An imperative note is re-read later as a command and can override the live request

Write what is true, not what to do. A past self's instruction has no way to know it is out of date.

← Previous lesson · All 134 lessons · Next lesson →

The full course — 134 lessons and 402 quiz questions — ships inside the app. Get TPEE to study it offline.

This lesson is the written summary of a course that ships inside the TPEE prompt editor for Windows - thirteen sections, a 0-100 score before you send anything, and it works with no network connection. The three one-time prices, and a 14-day free trial.