Context Compaction: Preserving Decision-Relevant Information Within a Token Budget

The first question context compaction must answer is: when the context window cannot fit the entire history, what should be discarded? The most readily conceivable approach is a sliding window—keep only the most recent several rounds of messages and truncate everything earlier. This approach is intuitive, simple to implement, and low latency, but it rests on an assumption that does not hold up: the closer a message is to the current moment, the more important it is for subsequent decisions.

Temporal proximity does not equal task value. The causal chain of a conversation is often not linear. Suppose the first message contains a constraint: “Output must comply with the company's internal permission rules; no numbered configuration item may be modified,” while the most recent ten rounds merely discuss a specific field back and forth. After the sliding window truncates the first round, the most recent ten rounds the model sees are still fluent and complete, but the conversation's only prohibitive constraint is lost. At this point, the more “confident” the model continues to generate, the more serious the consequences become. Goal statements, decisions already made, and acceptance criteria appear infrequently and usually only once, but their value does not decay as turns increase; precisely those trivial discussions that recur and fill the recent window decay fastest. Direct sliding window discards precisely the first kind of information.

Conversely, retaining everything also has real costs. Stuffing the entire history into context means, first, token cost grows linearly or even superlinearly with conversation length; second, conflict: earlier conclusions that were overturned and contradictory statements from different sources are present at the same time, making it difficult for the model to tell which one remains valid; finally, “Lost in the Middle”—attention in long contexts provides reduced effective coverage of middle passages, and even if information is not physically lost, the model may not be able to retrieve it at generation time. Therefore “keeping everything” is not a safe route that can be extended indefinitely.

This set of contradictions turns context compaction from an engineering detail into a task with an explicit contract: the input is the complete history, the current task, and a token budget; the output is a compact context that still suffices to support the next decision. Note that the key word of the contract is “support the next decision,” not “look like a historical summary.” The criterion for judging compression quality is therefore: after truncation, is the next decision the model makes based on the compact context consistent with the decision it would make based on the complete history? This means the compressor's selection logic must rank by task value rather than message time—a compressor that keeps only the most recent messages is, in the worst case, equivalent to forgetting the most valuable constraint immediately after it appears.

From this, two operational boundaries follow. First, a shorter result only means fewer tokens are loaded, not that key facts have all been preserved; the compression ratio is a means, not a quality metric. Second, when the compressor cannot confirm that a piece of original text carrying a goal, permission, or acceptance condition has been structurally transferred out, it must not discard that original text directly—better to compress a little less than to let an unrecoverable constraint disappear silently. These two boundaries will recur in the specific mechanisms of subsequent sections.

There is more than one compaction method, and they are not different intensities of the same action but four paths with completely different ways of losing information. The consequence of choosing the wrong method is not 'not compacted cleanly enough' but 'losing the wrong things.' The four basic methods can be distinguished by 'what happens to information before it leaves the context.'

The first is truncation. It deletes by position: keep the head or tail, remove the middle or the oldest part directly, without rewriting any text. Its advantage is the lowest cost, negligible latency, and no additional model calls; its drawback is equally direct—the deleted content is not subject to any semantic control, and which message gets cut off has nothing to do with whether it is important. If a target constraint happens to fall within the truncated interval, it permanently disappears in its original form, and the compactor knows nothing about it. Truncation is suitable for regions already confirmed to carry no decision information, such as purely social pleasantries that have already ended, or parts that have been structurally transferred elsewhere.

The second is summarization. It has the model re-express a segment of history in shorter text. The advantage of summarization is that it can gather scattered narratives across multiple turns into a coherent short text, allowing readers to grasp the main thread at a glance. The cost has two layers: first, hallucination may be introduced during generation, and facts or numbers that do not exist in the original text may appear in the summary; second, summarization naturally tends to flatten disagreements—if two proposals are at an impasse in the original text, the summary may write it as 'the team discussed multiple options,' and the tension of the conflict and each side's reasons disappear. Subsequent decisions often depend precisely on these disagreements: who objected, why they objected, and whether the objection was later rejected or adopted. Summarization actively irons out this kind of information.

The third is extraction. It does not rephrase, but picks out specified fields from the original text and keeps them verbatim: task goals, decided items, open questions, acceptance criteria, and so on. Extraction preserves the precision of the fields; the field contents do not get distorted by rephrasing. Its blind spot lies in the word 'specified': the extractor only looks for the fields it is asked to find, and any information not on the field list but later proven important will be missed. An anomalous phenomenon that has not been declared 'critical' in advance will not be proactively retained by the extractor.

The fourth is external storage retrieval. It does not delete information, but moves the original text out of the context as-is, stores it in external storage, and retrieves it on demand when needed. The theoretical loss is zero: the original text is still there, unchanged in any way. The actual risk occurs at retrieval: if the query terms do not match, the index is not built properly, or the model does not even think to look it up, this original text, although it 'exists,' makes no difference to the current decision compared to not existing. The retrieval approach preserves storage, but bets reliability on recall.

Thus choosing a method becomes a question of 'which failure is the most intolerable.' The inputs to method selection are the type of information, token budget, and acceptable loss; the output is one or a combination of truncation, summarization, field extraction, or external storage retrieval. Whether the information type is decision-critical, factual, or narrative directly determines which path to take: decision-critical fields use extraction, narrative background uses summarization, areas confirmed useless use truncation, and evidence that needs to be retrievable in its original form uses external storage retrieval. Treating the four as equivalent, interchangeable compaction and comparing only their compaction ratio is the most common mistake in such systems—their real difference lies in what is lost, and whether that loss can be discovered and repaired afterwards.

The previous section showed that each of the four compaction methods loses information in its own way. This section addresses a more fundamental question: which parts of the history should not be left to free summarization to decide whether to keep or discard. The answer is the state that decisions depend on. Goals, acceptance criteria, permission boundaries, completed items, unresolved issues, and reasons for failures—these pieces of information determine what to do next and what can be done. Their disappearance or distortion directly changes subsequent actions. By contrast, the conversation surrounding those decisions—the narrative of "who said what and when, and how it was discussed"—is the appropriate subject for summarization. This is the separation of structured state from narrative.

After separation, the two channels each perform their own role. The structured state channel takes as input goals, constraints, permissions, progress, open items, and the source of each piece of information; it outputs a versionable collection of fields—like a set of named slots rather than a passage of prose. The task summary channel takes the remaining conversation as input and outputs an overview that can reconstruct the thread of the discussion at the time. The key difference between the two is verifiability: fields can be checked item by item, corrected, and rolled back, whereas a summary, once generated, can only be replaced wholesale. Therefore, a hard rule must be attached to the state channel: field updates are governed by permission and event rules, and summaries must not overwrite state. A summary is never allowed to rewrite a goal field or quietly delete a permission constraint; it can only restate in its own words what happened.

For this separation to truly hold, source references are also required. Every field in the state should retain the corresponding source message or tool result ID. Then, when a "completed item" says "fixed the login timeout," if someone questions it, the system can trace back to the original tool result, confirm whether the fix was actually completed and on which version. Without this trace-back chain, the compacted state becomes the sole source of truth—whatever it says goes, and it can be neither verified nor corrected. The same applies to the summary channel: a task summary compresses the original text, but as long as it retains traceable source references, the compacted content is not a single unverifiable source of truth.

Thus the responsibility of the compactor shifts from "writing a shorter piece of text" to "maintaining a sourced, rule-protected state." It is no longer a read-only text compression action, but a state update process with write-permission boundaries: which fields may be changed, what events trigger changes, and whether permissions should be checked before the change—all of these should be explicitly defined. Free summarization is only allowed in the task summary channel, and the task summary channel never has permission to overwrite the state channel.

The metric a compressor most readily reports is compression ratio: history compressed from 18k tokens to 1.8k, a 90% reduction, which sounds impressive. But “tokens reduced by 90%” only answers “how much money was saved,” not “what was lost.” A compressed draft that erases goals and permissions is a net harm to the task no matter how low its token count. Evaluating compression quality requires putting benefits and losses on the same scale.

One actionable approach is to define the overall utility of context compaction. Its inputs fall into four categories: downstream task benefit, token cost, critical information loss, and two weights λ and μ; the output is a composite utility value that allows comparing approaches side by side. The form can be written as:

U = Gtask − λ × Ctoken − μ × Lcritical

Where Gtask is downstream task benefit—the performance achieved by completing downstream tasks with the compressed context compared with using the full history; Ctoken is token cost; Lcritical is critical information loss, i.e., unrecoverable omissions; λ is the penalty coefficient per unit of token cost, and μ is the penalty coefficient per unit of critical information loss. When the task is cost-sensitive, increase λ; when the task is sensitive to the consequences of missing constraints, increase μ. Which of two approaches is better is determined by comparing utility under this formula, not by comparing whose token count is smaller.

Beyond utility, we also need a set of directly measurable proxy metrics. Question-answering recoverability: when asking questions about the original text before compression, can the compressed version support the correct answer? Constraint preservation: do goals, permissions, and acceptance criteria survive intact, with not a single one missing? Citation consistency: can the numbers and conclusions cited in the compressed version be traced back to the original messages or tool results? Downstream task success: feed the same set of downstream tasks to the original and the compressed version respectively and see whether task completion quality degrades. These four correspond to four unacceptable failures; any significant deterioration in any one of them means the compressor dropped the wrong things.

This formula has an important boundary of use: higher utility is meaningful only under the same task and the same weighting basis. λ and μ are human-assigned risk preferences; a team that sets μ extremely low and a team that sets μ extremely high will produce opposite rankings for the same compressed draft. Therefore utility values from different risk scenarios cannot be directly compared with one another—the legitimacy of the comparison comes from a shared weighting basis, not from the utility values themselves. This also explains why “very high compression usually increases omission risk”: when token cost is pushed to the limit, what tends to be lost are the items in Lcritical that have low frequency, no alternative source, and cannot be recovered once gone—exactly the objects that μ is supposed to cover.

In long conversations, the most common way to save tokens is recursive summarization: every ten turns, compress “previous-generation summary + the latest ten turns of new events” into a new, shorter summary, and discard the old messages. This keeps context size manageable, but this process has a hidden degradation mechanism.

First look at its loop structure. The input to recursive summarization is the previous-generation summary and new events; the output is a new shorter summary. Each time it runs, existing wording biases and omissions in the previous-generation summary have a chance to enter the next generation: if the first generation misses a number, the second generation continues writing on that basis, and by the third generation there is no way to know that number ever existed. After accumulating across generations, the distance between the summary and the original facts does not increase linearly; instead, each generation stacks new biases on top of the previous generation's biases. Looking at any single generation's summary, the text is fluent and self-consistent—the problem is precisely its fluency: errors are written more and more like facts.

What is more dangerous is that disagreements get rewritten. In the original text, two options are in dispute, each with its own reasons and unresolved; the first-generation summary may still retain traces of “still divergent,” but by the second generation it may be summarized as “after discussion, leaning toward Option A,” and by the third generation it directly becomes “determined to adopt Option A.” An originally open pending state, after several rounds of rewriting, is smoothed into a definite conclusion, and subsequent decisions are then based on a decision that was never made. The “flattening” tendency of summarization is only a flaw within a single generation, but in the recursive structure it is amplified into systematic drift.

Judging whether drift has occurred requires an external yardstick. Periodically rebuild a summary from the original log and compare it with the current recursive summary: if the two diverge, it means the summary has drifted, not that the original facts have changed. The original log is the only factual anchor; any recursive chain must be able to return to this anchor for verification. This yields three constraints. First, high-risk fields must be losslessly preserved—fields such as goals, permissions, acceptance criteria, and pending items must not undergo any generational rewriting; they are updated only through the structured state channel, and the summary channel cannot touch them. Second, periodically rebuild from the original events—regenerate summaries from the original log at a fixed cadence, replacing the accumulated product of the recursive chain so that deviations have no opportunity to stack indefinitely. Third, retain milestone snapshots and allow user correction—leave summary snapshots at key nodes for comparison; when users detect drift, they can manually correct it, and the corrected result becomes the starting point for the next generation rather than allowing errors to continue propagating. Together, the three constraints transform recursive summarization from a one-way decaying chain into a verifiable, rebuildable, and manually intervenable loop.

The compaction stage has a commonly held security assumption: a summary is shorter than the original text, and shorter content contains less information, so it is more secure. This assumption fails in both directions.

The first failure mode is that sensitive data still survives. A summary does not automatically lose sensitive information just because it is short—on the contrary, the summarizer's job is precisely to keep the most informative content, and high-information-density content such as keys, personally identifiable information, and internal identifiers are exactly what it tends to retain. After the original text is deleted, the summary continues to hold sensitive data; compaction does not reduce the exposure surface, it merely changes the exposure surface into a more concealed form. The second failure mode is more subtle: a summary can solidify untrusted instructions into long-term rules. In the original text, an instruction from user input or tool output—'from now on always use internal mode'—is only a candidate text awaiting verification. Once the summarizer writes it into the summary, it takes on the narrative authority of the compactor; subsequent turns treat 'the summary says so' as evidence that it has already been verified, and a malicious external instruction is thus escalated into a long-term constraint.

Therefore security governance must treat summaries as first-class data objects, not as shadows of the original text. The inputs to governance include data classification, origin, scope, and deletion requests for both the original text and the summary; the outputs are four types of actions: retain, isolate, audit, and delete. The concrete implementation consists of three things. First, scope, retention period, and provenance marking must be applied both before and after compaction: before compaction, determine which content is allowed to enter the summary and how long it may live; after compaction, mark the summary itself with its provenance and classification so that downstream systems can treat it under the same rules. Second, deletion requests must cover summaries, indexes, and caches: when a user requests deletion of a conversation, deleting only the original text while leaving the summary, retrieval index, and cached copies means the deletion has not occurred in a legal or compliance sense. Third, source trustworthiness must enter permission judgments: text without a trusted source can only serve as candidate evidence and cannot be escalated to system permissions—the fact that the summarizer repeats an instruction does not mean that instruction has been authorized.

Finally, return to evaluation criteria. 'Shorter' is not 'more relevant,' and still less is it 'more secure.' A compactor that optimizes only for length may well output a summary that is short but highly sensitive, short but full of misleading instructions. The compactor must be evaluated around the current task—whether the compacted context still meets security properties should, like task gains and cost losses, become part of overall utility.

The principles from the previous sections become clearer when applied to a concrete numeric scenario. Suppose the total window is 4,000 tokens, the system prompt and tool description take 1,200 tokens, and the current question and the answer about to be generated reserve 1,300 tokens; then only 1,500 tokens remain for history. The original history has 18,000 tokens. The intuitive approach is to scale the history proportionally down to 8.3%, but “blind proportional compression” means every message is uniformly reduced, and the goal constraint in Section 1 that appears only once would be cut by the same proportion as other casual chat—this is exactly an unacceptable failure in compression decision-making. The correct approach is to allocate by budget blocks, not by proportion.

The inputs to the budget case are the 18k original history, the 4k total window, and the reserved amounts for the system and answer; the output is a 1,500-token history budget, along with an allocation plan of 500 tokens each for three blocks: state, summary, and original text. The first block is protected state, taking 500 tokens: extract the 5 goals/constraints, 3 open items, and the most recent tool state, and store them verbatim in field form. The unacceptable failure for this budget block is “goals, permissions, and acceptance criteria are rewritten”—so it only allows extraction, not summary rewriting. The second block is task summary, taking 500 tokens: provide an overview of past narrative phases. The unacceptable failure for this block is “writing unresolved disputes as decided”—so the summary must retain “open” markers and cannot iron out disagreements. The third block is the original-text index, taking 500 tokens: retrieve from the original history the original text fragments most relevant to the current decision and place them in context. The unacceptable failure for this block is “cannot find evidence supporting the current decision”—so the retrieval query must be constructed around the current task, not by taking the most recent 500 tokens in reverse chronological order.

Thus the compression ratio has a clear definition: let Bhistory be the history budget; the compression ratio is the ratio of tokens loaded into history to original history tokens, i.e., Bhistory ÷ 18,000 = 1,500 ÷ 18,000 ≈ 8.3%. This number only describes length and does not prove task information fidelity: 8.3% can come from the three-block allocation above, or from uniformly truncating 91.7% of the history. The two have the same length but completely different decision quality.

The final step is to test the boundaries of this allocation. If the follow-up question changes from “continue advancing the current task” to “trace the cause of the last failure,” the budget allocation should change accordingly: the protected state remains the same because goals and permissions have not changed; but the task summary and original-text index should be rebuilt around the failure timeline—the retrieval query changes to messages before and after the failure, and the summary emphasizes the sequence of events before the failure occurred. This reallocation illustrates the nature of the compressed result: it is a “view under task conditions,” serving the current specific question, not a truth that can permanently replace the original log. When the task changes, the view must be rebuilt; the original log is the only factual anchor that does not change with the task.

Drawing the mechanisms from the previous sections into a diagram yields this structure: on the left is the original event stream—messages, tool-call results, and decision events continuously enter the system in chronological order; these events first pass through a classification step, where they are routed by their nature into three channels; the three channels evolve independently, and only when the context is assembled do they merge according to the current task and are fed into the model.

Figure 1's core message is: the summary is only one path; key state and original evidence must maintain independent lifecycles. The three channels are: protected state, which stores hard constraints such as goals, permissions, and acceptance criteria and is updated only by rules—summaries have no authority to overwrite it; task summary, which stores narrative content and can be freely rewritten but must retain unresolved markers; and original-text index, which stores permissioned original evidence and is retrieved on demand. At merge time, the three together form the context; if any one channel is absent, the other two cannot compensate for its responsibility.

The three-channel design takes as input original messages, tool events, and decision events; its outputs are protected state, task summary, and a permissioned original-text index, which are then merged according to the current task. The state preserves hard constraints, the summary preserves narrative, and the index is responsible for evidence retrieval—this is why a fluent summary cannot replace all three: no matter how well a summary is written, it cannot prove that a field has not been altered, nor can it produce the original text when challenged. The three responsibilities are orthogonal in an information-theoretic sense; improving the quality of one channel cannot compensate for the absence of another.

This diagram also implies an operational discipline: when the budget is insufficient, it must be made explicit which evidence was not loaded. When the three channels merge, if the budget is only enough for state and summary, then the original evidence not loaded into the context should be explicitly listed—which message numbers and which tool results are absent at this moment. It is better to make the 'absence' visible than to let the model mistakenly believe that the three parts in front of it are all the facts. Visible absence can be retrieved when needed; invisible absence will directly become a basis for erroneous decisions.

The reason protected state needs to be 'structured' is, at the implementation level, one sentence: save it like a database record, not like prose. The difference can be measured by a typical failure: the original constraint says 'must not modify the production database', and after three generations of summary rewriting it becomes 'modify cautiously'. In prose format, every rewrite is a re-statement of the entire text, and no mechanism prevents this semantic drift; in database record format, each field has a type and a fixed structure, and rewriting no longer occurs—only an explicit, permissioned event can change a field's value.

The input to a state contract is the non-droppable items and their source events; the output is a record with type, value, writer, time, scope, version, and status. Each non-droppable item must store eight elements: type indicates what it is (goal, constraint, decision, open issue, or evidence reference), canonical value is its current factual content, source event records which message or tool result it came from, writer records who has permission to write it, time records when it takes effect, scope indicates which task range it applies to, version supports update tracing, and status marks whether it is currently valid, replaced, or pending confirmation. For example, a goal field says 'fix export timeout', and the compaction rule is that it can only be rewritten by the user or task owner; a constraint field says 'must not modify production data', and the compaction rule is to preserve it verbatim and mark the source; a decision field says 'adopt streaming export', and the compaction rule is to preserve the rationale and alternatives; an open_issue field says 'P95 still to be tested', and the compaction rule prohibits summarizing it as 'passed'; an evidence_ref field says tool:run-184, and the compaction rule is to preserve the reference and not copy the referenced content into unsourced facts.

These fields each have a corresponding failure mode: goal being rewritten casually by the summarizer is equivalent to silently replacing the task objective; constraint being restated may loosen semantics; decision losing rationale and alternatives means later participants cannot understand why this choice was made and cannot safely reverse it; open_issue being polished into passed causes people to skip verification that should have been performed; evidence_ref being expanded into text breaks the reference chain, and the text becomes an unsourced assertion that cannot be traced. Defining compaction rules field by field is exactly what turns 'which content must not be rewritten by summarization' from a principle into an executable constraint.

The update mechanism should also be designed according to database semantics. Updates use explicit events: a new constraint can replace an old constraint, but the old value remains in the audit record, the version increments, and the history remains queryable. This means state changes are always appending facts, not erasing the original text. Accompanying this are permission rules: external text without authorization can only become candidate evidence, not write into permissions or system rules; only authorized subjects can rewrite goals, permissions, and hard constraints. A new instruction from a tool output or user message first enters the pending confirmation area as candidate evidence; only after an explicit confirmation event by an authorized subject can it become a new value of a state field. Thus, 'must not modify the production database' becoming 'modify cautiously' can only happen through a legitimate, traceable write event, not silently in a polishing pass.

Can a single summarizer handle all types of content in the context? One question can test this: between a command's exit code and the central idea of a discussion, which one should be preserved verbatim? The answer is that the former must be preserved verbatim, while the latter is exactly the right object for summarization. If you hand both to the same “grab the main point” summarizer, the exit code will be reduced to “test has run,” and the central idea will be reduced to a fluent but distorted narrative—both types of content get hurt, and in different places. The starting point of differentiated compression is to have the compressor first recognize the information type, and then decide how to process it.

Four typical types of content each have a matching compression form. Code changes should preserve files, line numbers, patches, and test results—these are the precise coordinates of code changes; if any one is missing, the change cannot be reviewed or rolled back; prose-summarizing them is equivalent to destroying evidence. Tool calls preserve parameters, exit status, and key output—the difference between exit 1 and exit 0 is a hard fact, not a difference in tone; polishing “test failed, exit 1” into “test has run” is tampering with failure evidence into a neutral statement. Discussions can extract positions, decisions, and open points—the value of a discussion is who advocated what, what was finally decided, and what remains undecided; a summary should preserve these structures, rather than rewriting a lot of pleasantries; in particular, it must not write a suggestion that was not adopted as a final decision. Long documents are better served by chunked retrieval followed by local summarization—first locate the paragraphs relevant to the current question, and summarize only the hit local parts, rather than doing a global compression of the entire document, which is both expensive and loses detail.

From this, a decision sequence consistent with the three channels can be derived. First determine which fields must be verbatim lossless: exit codes, permissions, test results, patch coordinates, and other high-risk fields; use lossless extraction and pattern validation—not only copy them exactly, but also verify that the format matches expectations; exit 1 is exit 1. Then apply lossy summarization to narratives: discussion processes, background explanations, and similar content can be rewritten, as long as the structures of positions, decisions, and open points are preserved. For materials that can be traced back, store only an index: the original text is moved out of the context, leaving a reference with permissions, to be retrieved when needed. When the budget is insufficient, the system should expose “which evidence was not loaded” rather than silently pretending the context is complete—this also holds when the three channels converge; visible omissions can be remedied, invisible omissions will be treated as facts.

The input to differentiated compression is code, discussion, tool output, or long documents; the output is type-matched patch records, decision summaries, execution evidence, or original-text indexes. The four output forms are not interchangeable: patch records cannot speak for decision summaries, and original-text indexes cannot replace execution evidence. If the compressor recognizes only “text” but not “type,” it will inevitably make the mistake of handing lossless content to lossy processing—and this kind of mistake is exactly what the μ penalty in Section 4’s composite utility targets.

If the ROUGE score between a summary and the original text is high, does that mean compression is faithful? Not necessarily. Metrics like ROUGE measure lexical overlap: how many of the same words the summary uses as the original. But decision-information fidelity measures something else: given the compacted context, can the Agent make the same decision as it would with the full text? "Test failed, exit 1" is rewritten as "test has run", and its lexical overlap with the original may still be high, but the failure evidence needed for the decision has disappeared. Lexical overlap does not equal decision-information fidelity; evaluating compression quality must be based on task outcomes.

The way to do compaction regression is to turn this question into a reproducible experiment. First, build a task set with original logs: keep several real histories, each with a retrievable original log. Second, design a set of follow-up questions for each history, covering various unacceptable failures: restate the goal (verify the goal field survives), list inviolable constraints (verify constraints survive verbatim), continue unfinished steps (verify progress and pending items survive), explain a decision (verify the decision and its rationale survive), locate evidence (verify the retrieval channel can hit the original text), respond to deletion requests (verify deletion covers both summary and index). Third, run these tasks with full history and with compacted context, and compare four types of metrics: task success difference, constraint violations, unsourced assertions, and citation hits. Unsourced assertions specifically refer to facts produced by the compacted version that cannot be traced back to any original text or tool result; citation hits measure whether the retrieval channel actually retrieves evidence when needed.

The core formula is the task success rate difference caused by compaction:

Δtask = success(full context) − success(compacted context)

Here, success(full context) is the task success rate under full context, and success(compacted context) is the task success rate under compacted context. The larger the difference, the more severe the compaction loss; a zero difference means compaction did not lose decision-making ability. The input for compaction regression is the full version and the compacted version of the same original history plus a set of follow-up tasks; the output is Δtask plus constraint violations, unsourced assertions, and citation hits, four metrics. Note that this formula is opposite in direction but complementary to the utility formula in Section 4: the utility formula answers "is it worth it?", and the regression formula answers "is it faithful?"

Passing regression once does not mean passing forever; you also need multi-generation stress testing: after 10 consecutive rounds of compaction, reconstruct from the original events and compare whether protected fields and pending items have been distorted. This directly checks whether the drift of recursive summarization is under control — if divergence appears between the tenth generation and the original reconstruction, it means the drift mechanism still exists. After going live, monitoring metrics include compaction trigger frequency, reconstruction count, user correction rate, and fallback due to omission: if correction rate and fallback rate keep rising, that is the most direct signal that the compactor is dropping the wrong things. The last discipline is: if any of the model, summarization prompt, or token budget changes, rerun regression. Compaction quality is not an attribute of the compactor alone, but of the combination of compactor, model, and budget; if any part changes, Δtask may change accordingly.

The previous sections addressed "what to compact, how to compact, and how to verify," leaving two engineering timing problems: when to trigger compaction and how to handle concurrent branches.

First, look at trigger timing. The simplest approach is to trigger only by token watermark—when the window is almost full, compact once. The problem is that the moment when the window is almost full is often the busiest intermediate step of the task: critical tool calls are being executed, parameters are being validated, and state fields are in a half-updated state. Rewriting context at this moment is equivalent to taking a snapshot of the state at its most unstable point; afterward it is difficult to reproduce "what intermediate state compaction was actually in when it occurred," and if something goes wrong there is no way to locate it. A more robust approach is to design trigger conditions as a set of coexisting signals: token watermark, phase completion, topic switch, and high-value events. Generate a stable snapshot when a milestone completes—at this point the state is at a natural consistency point, and the snapshot itself is a reproducible checkpoint; perform budget compaction when nearing the window limit—this is a fallback action under pure capacity pressure, and the existing milestone snapshot can be relied on for deciding which fields to retain. If only the watermark triggers, the two timings are collapsed into one, and stable snapshots and budget compaction are mixed together, making both reproduction and rollback difficult.

Next, concurrency isolation. Can two parallel subtasks share the same summary? No. If task A and task B each proceed, and each compacts at the end, writing "the last completed summary" back to shared state, task A's conclusions will be swallowed by task B's summary. The correct approach is to treat branches as a version control problem: concurrent branches derive from the same version snapshot, and each records newly added facts and decisions; at merge time, merge by source, version, and conflict rules—conflict rules are responsible for adjudicating the two branches' different updates to the same field, rather than letting temporal order adjudicate for them. Finishing last does not equal having the right to overwrite; this is the first principle of concurrent merging. If the base snapshot has been updated while the branches were running, the old branch must explicitly replay or be marked expired: replay means reapplying the branch's incremental events on top of the updated base, and expiry means explicitly declaring that the branch's results are no longer trustworthy—both are better than silent overwriting.

The inputs to trigger and concurrency control are token watermark, task phase, high-value events, and branch version; the outputs are compaction snapshots, branch increments, and conflict merge results. After adding this timing discipline, the compaction system gains two previously missing properties: an erroneous compaction can be located—every snapshot and merge has version and source records, and the erroneous change can be traced to a specific event; rollback is possible—the stable milestone snapshot provides a recovery point, and there is no need to rebuild the entire history. Compaction is no longer a series of irreversible text rewrites, but a series of versioned, mergeable, traceable state transitions.

Connect the previous mechanisms in causal order. The design of a compaction system can be understood as a six-step chain, where each step is driven by the failure of the previous one.

Step one: window and cost form the budget. Window capacity is a hard constraint, token cost grows with history, and together they determine the upper limit of the budget available for history—an 18k history in a 4k window has only 1,500 tokens available. The existence of a budget is the prerequisite for all later trade-offs: without budget pressure, compaction would not have to happen.

Step two: identify non-discardable state. Since something must be discarded, the first step is to draw the boundary of what cannot be discarded: goals, permissions, acceptance criteria, unresolved items, failure causes. This information is saved by the protected state channel as database records, bound verbatim to their sources, and summarization has no authority to rewrite them. This step answers the question "what, if lost, amounts to losing decisions"; only after that can the remaining content enter lossy processing.

Step three: summarize, extract, or offload by task. Content eligible for compaction is routed by type: high-risk fields are extracted losslessly and schema-validated, narratives undergo lossy summarization but retain the structure of positions, decisions, and unresolved points, and evidence source text that needs to be rechecked is stored in an external storage index. The choice of compaction method is determined by the most intolerable failure, not by the compression ratio.

Step four: preserve source references and versions. All compaction outputs carry source citations, state updates go through explicit events and retain an audit history, and snapshots and branches carry version numbers. This step ensures that information after compaction remains verifiable, locatable, and rollback-capable—compaction outputs never become the only and untraceable source of truth.

Step five: test information loss with downstream tasks. Run the same set of downstream tasks separately on full history and compacted context, and compare task success delta Δtask, constraint violations, unsourced assertions, and citation hits; then add multi-generation stress tests and online monitoring. This step turns "whether compaction is faithful" from a subjective judgment into a repeatable measurement, and any change in model, prompt, or budget triggers retesting.

Step six: periodically rebuild and handle deletions and corrections. The drift of recursive summaries can only be interrupted by regular rebuilding from original logs; user deletion requests must cover summaries, indexes, and caches; and user corrections to compaction results serve as explicit input for the next generation's starting point. This step ensures that cumulative errors and compliance obligations during long-term operation are not ignored.

The six steps connect end-to-end and form a closed loop: budget determines that compaction must occur, non-discardable state determines the boundary of compaction, type determines the method of compaction, references and versions determine verifiability, task regression determines quality assessment, and rebuilding and correction determine long-term stability. Missing any step will expose a specific failure at the next point in the loop: missing step two, compaction will rewrite constraints; missing step four, errors cannot be located; missing step five, losses cannot be discovered. Compaction is therefore not a one-time text reduction, but a continuous engineering effort centered on preserving decision-relevant information.