What an Agent Must Keep When It Compresses Its History

When a shorter history changes the task

As an agent works, its history fills with requests, tool calls, results and intermediate conclusions. To continue within an input budget, an application may replace part of that history with a smaller account of the work. This is context compaction: reducing the information presented to the model on a later turn.

Consider a simulated task: an agent must total Venmo payments received from the user's coworkers after a specified date. [1] It has retrieved the payments, but still needs to establish which senders are coworkers. [1]

At that point, the history is shortened. The replacement summary keeps the total across all senders and presents it as the final answer, dropping the unfinished coworker check. [1] The agent now has an answer ready to submit, even though the question still requires another step.

That failure gives us a concrete way to approach the problem. A compressed history has to carry enough information for the agent to recognize the work that remains. In this case, the word “coworkers” determines which records count and which check comes next.

The example comes from PAIR, a study of context compression in tool-using agents. Its researchers resume an agent from the same environment state using either the history before compression or its replacement, then observe how the task continues. [1] We will return to the payment task to examine what belongs in the handoff and what supporting detail can be recovered later. From there, we can compare ways to shorten the input, consider how corrections should change it, and test whether the agent can still finish. The aim is to make those choices concrete enough to use in an agent you are building.

What does the next turn need to know?

With the payment records retrieved, the agent still has to identify the coworkers, select their payments and calculate the requested total. In the study, continuations with the original history queried the contact relationships and answered correctly; two of the three original compressed continuations immediately submitted the unrestricted total. [1]

The repair made the unfinished work explicit. It retained the observed total, marked the coworker-only amount as unconfirmed, and kept identifying coworkers on the to-do list. [1] All three continuations using the adapted summaries then answered correctly. [1]

The two handoffs leave the same payment task at different stopping points:

This suggests a practical question for every handoff: What would the agent do next using only the information we are leaving it? A useful payment handoff leads back to the coworker check. More generally, the agent needs a current objective and completion condition, the actual state of the work, the evidence that still shapes its choices, and the questions left open. These functions can fit in a paragraph or several fields; the format helps only if it records them accurately.

Actual state includes the environment outside the prompt. In AppWorld, the simulated environment used for the payment task, Python variables persist across code blocks; PAIR describes a competing checkpoint rule that mistakenly told the agent to reconstruct them after a context reset. [1] The history may have lost the variable's name while the runtime still holds its value. Recording the binding lets the agent reuse existing work. Telling it that the value was destroyed can send it back through calls it has already completed.

The same separation matters when a task produces an artifact. Anthropic's engineering account of a long-running coding harness describes a feature list initially marked failing, progress records and instructions to mark features passing only after careful testing. [2] A later session can then distinguish implementation progress from verified functionality. This is an implementation example of carrying work across sessions; the account does not isolate the effect of its file format in a controlled comparison.

A handoff also needs the boundaries on action. In an illustrative variation of the payment task, imagine that the user authorizes reading records and calculating a total, while forbidding payment requests. A summary that says “settle the coworker payments” would leave the next action ambiguous. The read-only scope should remain explicit, and a proposed next step should stay separate from permission to perform it.

The source of that permission matters. A request in a retrieved document cannot acquire the user's authority merely because a compressor places it in a task summary. Preserve who imposed a restriction, what it applies to and whether a later instruction genuinely changes it. Exact wording or values deserve space when a loose paraphrase changes the operation: a date boundary, recipient, file identifier or numerical limit may carry more consequence than a long discussion around it.

There is direct evidence for the risk of losing a rule. Governance Decay tests synthetic scenarios in which a rule in compactable history constrains a later tool call, and grades the prohibited effect in the emitted arguments without executing the calls. [3] In its GLM-5.1 comparison, removing the rule from an otherwise unchanged summary increases violations, while restoring it returns violations to zero. [3] The vulnerable channel is history that can be compacted; immutable system or developer instructions are outside that channel. [3]

One way to protect such a rule is to keep it outside the lossy summary and reinsert it unchanged. That preserves the text against deletion. In Governance Decay's stress test, however, a recent message impersonating an operator and claiming to revoke the rule still causes violations under verbatim pinning; adding a provenance label reduces the residual violations without eliminating them. [3] Protecting a constraint's words and establishing who can override it are separate responsibilities. A builder still needs a trustworthy way to check authority before consequential actions.

We now have a clearer account of what the handoff owes the next turn. The next question is how an application makes room for it—and what happens to the history it removes.

Where does the rest of the history go?

The model's active context is the input it receives for the next response. Files, application records and earlier messages may exist elsewhere without appearing in that input. This separation makes several kinds of reduction possible.

A recent window keeps a suffix of the interaction and drops older messages from view. It preserves the selected messages as they were, but an earlier restriction or explanation disappears unless another part of the input carries it forward. A recent window is easiest to use when the recent interaction already contains the state needed to continue.

Observation masking keeps more of the action trail while shortening tool results. In The Complexity Trap's implementation, the system and user prefix and the agent's reasoning and actions remain, while older observations become placeholders and recent observations stay visible. [4] The agent can still see that it read a file or made a call, although it may need to recover the result. Because the retained reasoning and actions continue accumulating, this implementation slows context growth rather than bounding it indefinitely. [4]

A summary rewrites earlier interactions into an account intended for continuation. That gives it room to preserve relationships across messages: why a result is tentative, why an approach was rejected, or which check remains. It also introduces a generative step that can reinterpret those relationships, as the payment example showed. PAIR changes the guidance inside a fixed compression template while keeping the agent, compressor model, tools and decoding configuration fixed. [1] Improving a summary therefore need not start with retraining the acting model or building a new codec.

Offloading leaves a smaller reference in the input and stores the larger material elsewhere. Deep Agents' implementation account describes replacing large tool outputs with a filesystem path and preview, then falling back to a structured summary when offloading no longer frees enough space; that fallback also saves the original conversation messages as a filesystem record. [5] The summary and archive serve different purposes. One gives the agent a working account; the other lets it inspect material the account leaves out.

These operations can coexist. An application can preserve recent turns, offload a large result and summarize older progress. Each transformation has its own consequence: selection changes what is visible, rewriting changes how the work is described, and offloading changes where the agent must look.

When a provider performs compaction, the returned material also comes with rules for the next request. OpenAI's guide describes an encrypted item that is not intended to be human-readable. [6] Claude's on-demand interface returns readable summary text with a signature. [7] A provider-managed representation can thus be opaque or readable, with its own caller requirements. For example, OpenAI's standalone /responses/compact endpoint returns a complete next-context window, potentially containing retained items alongside the encrypted item; its guide says to pass that window onward unchanged. [6] Claude's on-demand contract places the unchanged signed block first, removes the messages it summarizes and keeps subsequent turns unchanged. [7]

Carrying these items forward correctly gives the provider a valid continuation input. The agent still needs to recognize an unfinished check or a missing detail and know how to retrieve what it needs. That brings us back to the material left outside the input: what makes its recovery dependable?

When is a recovery route good enough?

In the payment case, the coworker restriction tells the agent to look again. The individual payment records support the calculation once that need is recognized. This gives us a useful division: keep the information that makes further work necessary readily available, then consider whether the larger supporting records can be recovered on demand.

Recovery has several connected requirements. A preview or reminder should expose the reason to open the larger record. The payment example gives us a concrete way to inspect that route:

The record's identity also has to match the question. A pointer to a live file can be enough when the next action needs its current contents. If the task asks what the file contained before an edit, the system needs a retained observation, version or snapshot identifying that earlier state. Reading the current file cannot establish what was there before it changed. This is a design deduction from the difference between present and historical state, rather than a rule to snapshot every artifact.

Even successful recovery can consume useful budget. In another PAIR case, summaries reduced previously read API specifications to generic prose, leading the agent to reopen documentation and repeat authentication work. [1] In a targeted replay, preserving executable signatures and consolidating authentication reduced mean remaining steps from 14.7 to 10.7, with all three continuations succeeding in both conditions. [1] The omitted information was recoverable, but having it ready made continuation less expensive. The lesson concerns usable API state in the simulated task, not copying credentials into production prompts.

Short, exact feedback can likewise make the recovery route usable. A 100-example experiment varying parts of a search-agent setup with Qwen3.5-4B and Qwen3.5-9B found higher page-open error rates when older tool errors were masked or exact URLs were replaced by page titles the agent had to resolve. [8] Error feedback helps repair a malformed call; the URL identifies the intended target. Their usefulness depends on the remaining task, so this finding does not require keeping every old error forever.

When space is tight, make the retention decision against an actual continuation. Start by identifying the next required action and the conditions that justify it. Keep the governing objective, applicable restrictions and unfinished checks accessible. Then look for bulky material whose useful content is already captured, or whose original can be recovered through a tested route. Preserve exact identifiers, feedback and operation signatures where they save uncertain or repeated reconstruction.

The useful balance depends on the next action. An API signature needed on the next call may earn its space; a long result needed only for a possible later branch may be better offloaded. Before evicting the latter, check that the reminder points to the right record, that access survives the handoff and that recovery fits the remaining tool-call, token and time budgets.

If a required distinction cannot fit and its recovery or an external check is unavailable, the supported continuation has reached a boundary. The options are to retain more state, obtain the missing information, narrow the task or explain why continuation is blocked. A smaller prompt cannot supply a justification that the system no longer has.

These choices tell us what any reduction must accomplish. To choose among windows, masking, summaries and larger context, we also need to know what each costs and how well the agent works with it.

Which reduction fits the workload?

A large input carries more original material directly into the next turn. A smaller input can save repeated processing and leave room for further work. The tradeoff depends on whether the retained material helps the particular agent, and whether the reduction discards something it would have used.

The Complexity Trap compares raw history, observation masking and generated summaries in SWE-agent on SWE-bench Verified. [4] With Qwen3-Coder-480B, the three solve rates are similar, while masking and summarization roughly halve mean dollar cost. [4] With Gemini 2.5 Flash and an 800-token thinking budget (the allowance for reasoning), task success rates are 40.4% for raw history, 36.4% for masking and 31.4% for summarization, while both reductions cut cost by more than half. [4] In that configuration, the savings come with lower task reliability.

The comparison has a shared 250-turn ceiling: masking keeps the ten most recent observations visible, while summarization leaves the ten most recent turns unchanged and compresses batches of 21 older turns. [4] These settings make the alternatives concrete, but do not equalize their total token use or dollar cost. They also make clear which retention-window settings need testing in the intended workload.

Search tasks provide a different reason to summarize: the agent may need to keep exploring after its history reaches the input limit. As its history approaches the context limit, ReSum retains the original query alongside a goal-oriented summary of the accumulated history. [9] Its WebSailor-30B comparison reports one-attempt task success (BrowseComp Pass@1) of 12.8% for the full-history acting baseline (append-all ReAct), 10.3% for recent history and 16.0% for ReSum using ReSumTool-30B, under a 32k context limit and a 60-tool-call ceiling. [9] Here, append-all ReAct terminates as a failure at the context limit, and the comparison's “training-free” acting policy uses a separately fine-tuned summary tool. [9] The result combines a particular summary tool with extra search horizon, so it cannot isolate preservation quality as the cause of the gain.

Observation masking can buy that horizon too. A search-agent study finds that the added turns help when they turn failures into successes, but can hurt when masking removes evidence the model would otherwise have used; the benefits depend on the model, retriever and task. [8] An agent that succeeds after reduction may therefore have benefited from extra attempts, from a clearer input, or from both. Task success by itself cannot tell those mechanisms apart.

For a builder, these findings suggest a practical comparison:

• If recent turns already carry the needed state, try a recent-window baseline and check it against older dependencies.
• If large observations dominate the input, try masking or offloading while retaining useful feedback and a working recovery interface.
• If continuation depends on relationships spread across earlier messages, try a summary that states those relationships explicitly.
• If old evidence remains useful and fits the budget, keep more of it and measure whether the agent actually benefits.

Use these starting conditions to choose baselines, then compare reliability, recovery burden, total agent-plus-compression cost and elapsed time separately. A low-token prompt can lead to more calls; a useful summary can require its own call; a cheap run can stop early with the wrong answer. The payment repair is a reminder that completing the missing check legitimately may take longer than immediately submitting an unrestricted total.

So far, we have treated the handoff as a picture of one moment. Long tasks keep changing. The next handoff must carry those changes forward too.

How should the handoff change as the task changes?

In an illustrative variation, imagine that the user corrects the requested date after the payment records have been retrieved. The new date now determines which records count. The earlier total may still describe the earlier range, but it must lose its status as the answer to the current question.

A useful update carries the new condition into the goal, marks the earlier result with its original scope and identifies what must be checked again. Keeping both totals without their date ranges would create another ambiguity. Deleting every trace of the earlier work could also waste a valid intermediate result. The point is to preserve their relationship to the current task.

The cause of a failure can change what comes next as well. In another illustrative variation, the coworker lookup is blocked because a contact service is temporarily unavailable. “Coworker lookup failed” gives less guidance than “lookup blocked by unavailable service; relationship check remains open.” If the service returns, the latter leaves the agent able to retry. A failure condition should remain attached to the result so that later evidence can make it reconsiderable.

There is a measured reason to inspect the behavioral effect of updates. TRACE compares a previous summary plus a raw interaction update, an updated summary and omission of the update at matched AppWorld decision points. [10] In its OpenClaw setup, the updated summary preserves part of the update's effect on sampled next actions, but less than retaining the update verbatim. [10] Those probe actions are not executed, and the study does not fully separate omitted facts, distorted progress and ineffective use of retained information. [10] The observed attenuation makes the update's effect on continuation worth checking.

A correction should consequently be tested where it matters: does the agent select the new range, reconsider an old conclusion or perform the newly required check? Merely finding the correction's words in a summary leaves its effect unresolved.

Repeated compaction adds another reason to retain a route back to originals. If a qualifier has disappeared from the only remaining representation, a later summary of that representation cannot reconstruct it on its own. New evidence or an archive can restore it. Degradation therefore need not be smooth or inevitable, but a good first handoff is insufficient evidence about a long sequence. Test corrections and changed conditions after earlier compactions, while keeping the current objective distinguishable from its history.

How can we test whether the smaller history still works?

Return to the moment before the payment summary is substituted. The payment data and contact relationships exist in the simulated environment. We want to know whether changing the agent's input changes its ability to perform the coworker check and answer correctly. That requires holding the environment still while varying the input.

PAIR implements this control: it restores the same environment state, keeps the agent and tools unchanged, resumes the agent from contexts before and after compression, disables further compression and follows each continuation until it ends. [1] Its AppWorld analysis uses nine continuations per condition at 197 boundaries and finds harmful replacements in some ultimately successful trajectories, alongside many neutral replacements in failed trajectories. [1] A whole task can recover from a bad handoff, or fail for reasons that handoff did not cause.

A builder can use the same logic in a checkpointable test environment. Save the context and external state at a real reduction boundary. Resume from the pre-compaction input, the proposed replacement and a credible simple alternative, keeping model, tools, instructions, parser and sampling settings comparable. Run multiple continuations and compare their legitimate outcomes and remaining work. Different valid paths are acceptable; reproducing the same next sentence is unnecessary.

Then add probes for distinctions a completion score may conceal. In the payment task, ask whether the agent still recognizes the coworker check as unfinished and can retrieve the relationship data. For other tasks, inspect whether it distinguishes a prepared artifact from an applied change, and a test attempt from a verified result. Permission probes should include both actions that remain allowed and actions that require refusal or approval, so a system that simply stops doing useful work does not look reliable.

Recovery deserves its own check. Observe whether the agent recognizes a gap, selects the correct record or version, receives relevant content and extracts the needed value. MIRAGE provides an adjacent diagnostic example: it restores a fresh checkpoint for each probe in a planted multimodal personal-agent environment and separately scores answerability, source correctness and answer value. [11] In one fixed-evidence post-compaction format comparison within that setup, adding per-fact citations improved correct source identification much more than correct source-grounded answers. [11] A better source label can help the agent name the right record while leaving much of the answering problem unresolved.

For evolving tasks, introduce a known correction after compaction and inspect whether it changes the relevant behavior. Change a condition that caused a failure and check whether the agent reconsiders the blocked step. Repeat the compact-and-continue sequence. These correction and changed-condition probes are proposed workload-specific extensions, rather than a single validated universal suite.

Finally, run representative whole tasks with recurring compaction enabled. Boundary tests help locate local damage; whole-task tests show the combined effect of compression overhead, added attempts, recovery and completion. Track task reliability, prohibited actions, unnecessary repeated work, failed recovery, total cost and elapsed time. Inspect the returned tool content as well as the call: an executed retrieval that returns nothing has not recovered the evidence.

For irreversible actions, use a simulator or safe test environment instead of replaying the live effect. Full history is a useful control for diagnosing a replacement, but the uncompressed agent can make mistakes too, and its run may cost more. The comparison should tell you which distinctions survive and what the chosen design spends to keep them usable.

Conclusion

When an agent shortens its history, keep the information that lets it understand the current task, act within its authority, use completed work and recognize what remains unresolved. Supporting detail can move out of the input when the agent still has a reason to seek it, a usable route to the right record and enough budget to recover it before acting.

The payment example makes the criterion tangible: a useful handoff sends the agent back to the coworker check. The same criterion applies as goals, evidence and permissions change. Choose the representation by testing that continuation, including recovery and corrections, rather than by the summary's fluency or the amount of text removed.

Limitations

The direct studies discussed here cover coding repair, search, simulated application tasks and synthetic policy probes. The payment outcomes are small targeted replays; PAIR's main AppWorld experiments use GPT-5.6-Luna as agent and compressor, medium reasoning effort and a 4,096-token context budget. [1] These settings are study conditions, not recommended production defaults. Anthropic and Deep Agents provide engineering descriptions; MIRAGE supplies adjacent historical-evidence diagnostics rather than a coding-agent recovery rate. PAIR and TRACE overlap in investigators and methodological lineage.

The conditional retention priorities, historical-version requirement and illustrative correction procedures are design deductions to assess in a workload. They do not establish a universally sufficient summary or safe allocation of a fixed budget. A formal analysis ties the necessary budget to future questions and tolerated error, but covers one compaction event with restrictions on how those questions are chosen; questions adapted to the compressed result and repeated compactions remain open extensions. [12] That formal result does not establish a working natural-language encoding for a production agent.

The evidence does not settle arbitrary goal changes, implicit permissions or reliable recovery across every long task. Public opaque-provider interfaces also leave internal preservation behavior unavailable for direct inspection. Provider protocols here reflect documentation available for this inquiry through October 2, 2026; mutable pages are not original-release specifications or assurances of unchanged future behavior.