← All notes

Summary

When a long agent session runs out of room, something has to shorten the earlier turns so the task can continue. That shortening is not only a size problem. Standing instructions can disappear, and a coding agent also has to choose when to shorten, what working state to keep, and how to carry on. Both points below come only from paper abstracts.

Side constraints fall out of the summary

A side constraint is a user instruction that should keep shaping later turns, such as a rule not to delete mail until the user confirms. It is not the task itself. Compaction is aimed at the ongoing task, so these rules can be dropped without an error.

The abstract describes an inbox trial: after compaction, an agent deleted mail without approval in many sessions, and in none of the sessions before compaction. To measure this more broadly they built CONPACT, which checks whether the meaning of the constraint is still present and whether later behavior still follows it. The suite covers multi-turn chat, multi-turn tool use, and long-horizon research.

Across the compactors they evaluated, only a small share of injected side constraints was kept on average. The loss showed up across compactors and settings. How much survived depended on which compactor was used, how long the context was, how the constraint was worded, and where it had been placed.

Keep the rules off the task summary

Their proposed fix does not replace the compactor or the model. An extractor holds the constraints apart from the task summary, then adds them back onto the compacted context. The abstract reports retention above a high bar in all three scenarios.

For someone running an agent, the practical reading is: do not trust a single summary to carry both "what we are doing" and "what we must not do." If compaction is on, store durable rules in a place the summary step cannot silently omit, and put them back after every compaction. Check retention under your own compactor, length, wording, and injection point, because the abstract says those factors change the result.

Coding agents must also choose when

Repository coding work is a long trail of inspection, search, edits, and tests. Earlier exploration goes stale, so compaction is not only an overflow brake. The agent has to decide when to compact, which working state still matters, and how to resume from that state.

AutoCompact trains those choices into the coding policy. Training data comes from running a base agent, then having a judge review compaction decisions, the summaries, and the actions taken after compaction. Faulty outputs are replaced with corrected ones and those corrections are what actually run, so the rest of the trajectory continues from the fixed decisions. Those trajectories are used for supervised fine-tuning. Coding and compaction are then optimized together with reinforcement learning, rewarded by task success.

On the two verified software-engineering benchmarks named in the abstract, pass rate rose relative to the base model. The gain held for every inference budget they tried. One setting used a very large window that never overflowed. Another used a small window whose overflow fell back to compaction. So a learned compact policy and a hard overflow fallback are different mechanisms; the abstract reports the learned policy helping in both.

Claims

• id: C1 claim: Under context pressure, systems shorten earlier context, and user side constraints can be dropped in that step. source: S1 evidence: "When the context window is under pressure, LLM systems compact prior context to continue ongoing tasks."
• id: C2 claim: In the inbox experiment, deletions without approval appeared after compaction and not before it. source: S1 evidence: "an agent deleted emails without approval in 30/100 sessions after compaction, compared with none before compaction."
• id: C3 claim: The compactors they measured kept only a small average share of injected side constraints. source: S1 evidence: "The evaluated compactors retain only 17% of injected SCs on average."
• id: C4 claim: Holding constraints apart from the task summary and appending them raised retention without changing the compactor or the model. source: S1 evidence: "maintains constraints separately from the task summary and appends them to the compacted context, achieving over 90% retention"
• id: C5 claim: A coding agent must decide when to compact, what working state to keep, and how to continue. source: S2 evidence: "an agent must decide when to compact, what working state to preserve, and how to continue from it."
• id: C6 claim: AutoCompact collects trajectories by judging compaction choices and continuing from corrected decisions, then fine-tunes and uses task-success reinforcement learning. source: S2 evidence: "We use these trajectories for supervised fine-tuning, then jointly optimize coding and compaction through reinforcement learning with task-success rewards."
• id: C7 claim: Reported gains held both when a large window never overflowed and when a small window fell back to compaction on overflow. source: S2 evidence: "with a 256K context window that never overflows and with a 16K window whose overflow triggers fallback compaction."

@misc{iil_note_1mm95xz1,
  author = {{iinventedlight}},
  title = {{Context compaction and side constraints}},
  howpublished = {iinventedlight Library},
  year = {2026},
  date = {2026-11-03},
  url = {https://iinventedlight.com/library/notes/ao-compaction/},
  note = {Permanent ID iil:note:1mm95xz1. License: CC-BY-4.0.},
}

Markdown

Spotted a mistake? Use the MCP feedback tool or email hello@iinventedlight.com.

For language models and agents: start at /llms.txt. This page in Markdown: /library/notes/ao-compaction.md.