COMPACTION AND SUMMARIZATION

EXAMPLES Example 1: A compaction worked example. Suppose an agent has been helping a user set up a small website, and the conversation has reached 50 turns. The harness decides to compact. It keeps turns 41 through 50 in full detail, because that is where the live work is. It sends turns 1 through 40 to a summarizing step with a template. The returned summary reads, in three short paragraphs. First paragraph: the user requested a simple website for a bakery with a menu page and a contact form. Second paragraph: the agent tried to use a form-handling service but it failed because the free plan does not allow file attachments, so the agent switched to a simpler form that stores messages in a spreadsheet. Third paragraph: the agent is now attempting to connect the form to the spreadsheet, and the menu page is complete. The harness replaces turns 1 through 40, which might have used 35,000 tokens, with this summary, which uses perhaps 400 tokens. The agent continues as though nothing happened, but now has room to work. Example 2: A token-threshold trigger. A team runs an agent on a model with a 200,000 token window. They set the compaction rule at 80 percent, which is 160,000 tokens. During one run, the context climbs steadily. When it crosses 160,000 tokens, the harness pauses the loop before the next model call, runs the compaction routine, and shrinks the context to about 40,000 tokens. The agent resumes. Without the trigger, the next tool result, which was 50,000 tokens long, would have pushed the context past the limit mid-task and caused an error. With the trigger firing at 80 percent, there was a 40,000 token margin, and the team had also set a rule that very large tool results are trimmed before being added, so the system stayed safely below the limit. Example 3: Preserving a critical decision. Imagine a user told the agent on turn 12, "Use PostgreSQL, not MySQL, for the database." PostgreSQL and MySQL are two popular database programs. Turn 12 will be summarized away during compaction. A careless summary might say, "The agent and user discussed database options," which loses the decision completely. Later, the agent might choose MySQL and waste hours. A good compaction summary explicitly keeps a line such as "Decision: we are using PostgreSQL, not MySQL, per the user's instruction on turn 12." Notice that the line includes the decision, the alternative rejected, and the source. The harness can enforce this by using a template with a Decisions heading, and a check that every message tagged as a user constraint appears in the summary. Example 4: Autonomous compression with a scratchpad. An agent doing a long data-cleaning job is instructed to update a file called progress notes every ten steps. The notes list which data files have been cleaned, which problems were found, and what comes next. At step 60, the harness needs to compact. Because the notes are already well organized, the compaction step simply reads them and drops most of the raw history. When the agent resumes, the first thing it does is re-read its notes, and it carries on correctly. Had the agent relied only on an automatic summary written under time pressure, it might have lost track of which files were done. The agent that took notes as it worked made the whole system more reliable.