Redundant Re-Exploration: When Context Compaction Makes an Agent Repeat Work It Already Did

Redundant re-exploration is the pattern where an agent, after its context has been compacted or truncated, repeats actions it already performed and re-derives facts it had already established, rather than treating the summary it was left with as sufficient. A coding agent that already listed a directory re-lists it two steps after a compaction event. A research agent that already fetched a page re-fetches the same URL because the compacted summary of that fetch no longer feels citable. The task can still finish correctly, but it finishes slower and at higher token and tool-call cost than the same task would have cost without the compaction, which is what makes this a cost and reliability pattern rather than a purely qualitative one: it shows up first in a trace log and a bill, before it shows up as a wrong answer.

This is a distinct angle on an already-covered mechanism. Context rot describes reliability degrading as a function of how much is in the window; redundant re-exploration is instead a side effect of the standard fix for context rot, compaction and truncation, misfiring. It differs from plan decay, where the plan goes stale because the world changed underneath it; here the world has not changed, only the agent's compacted record of its own prior actions has, and the agent responds by distrusting or forgetting that record rather than by executing a plan built on false premises. And it differs from state externalization, which is the mitigation this pattern argues for, not the failure itself.

Mechanism

Compaction and truncation are the standard countermeasures to a growing context window: replace an aging trajectory with a shorter summary, or drop the oldest turns outright, so the agent stays under its budget. Both are lossy by design, and a 2026 empirical study of exactly this trade-off found that the loss is not evenly distributed: it concentrates on the actions immediately following a compaction event. Testing two models, MiniMax-M3 and Kimi-K2.7-Code, against seven compression baselines and a full-context reference on 168 AppWorld tasks, the study measured the marginal effect of compression on the five actions right after a compaction point. The first post-compaction action carried a 0.108 higher rate of being blocked or erroring than the equivalent step without compression, and repeated, near-identical actions, re-issuing a call the agent had already made, started at a 0.031 excess rate and stayed elevated through the rest of the measured window. Every one of the five post-compaction steps showed a positive excess, which the authors summarize plainly: compression increases what they call regressive exploration (Min et al., arXiv:2608.06503).

The same study isolated where in the compaction pipeline the damage occurs. At a 2,000-token compaction budget, an agent working from a generated summary of its own history correctly recognized task completion and produced a well-formed stop signal only 37.3% of the time. An agent given the same budget but filled by simple FIFO truncation, dropping old turns wholesale instead of summarizing them, did nearly twice as well at 68.1%, and even beat a full, uncompressed history at 60.6%. Summarization, the technique built specifically to preserve information under a token budget, was the worst-performing condition for the agent's own confidence that it was done. A second measurement made the downstream cost concrete: as the compaction budget tightened, the gap widened between tasks solved in at least one of two repeated runs and tasks solved in both, meaning compression was converting agent runs that used to reliably solve a task into runs that solve it only sometimes, with the difference made up by the agent doing the work again from a worse starting point.

This is not a one-paper finding. A separate 2026 audit of agent trajectories on a production-grade coding agent found that useless, redundant, and expired information is widespread across real trajectories even without a compaction event forcing the issue, and that a system built to strip it, without touching the agent's actual decisions, cut input tokens by 39.9% to 59.7% and total computational cost by 21.1% to 35.9% while leaving task performance unchanged across two LLMs and two benchmarks (Xiao et al., arXiv:2509.23586). That result matters here because it shows the raw material for redundant re-exploration, redundant information that a well-designed process could have recognized and skipped, is already sitting in ordinary trajectories before compaction ever runs; compaction does not invent the waste, it disturbs the agent's ability to recognize what it already has and triggers a fresh round of the same waste.

A third data point points toward what actually fixes it. A reinforcement-learning approach that trains an agent's summary-writing jointly with its task execution, rather than treating summarization as a fixed, unlearned utility bolted onto the agent, produced measurably fewer tool calls per trace than baseline compaction and, in the authors' own framing, helped the model retain task-relevant information and "reduce redundant re-exploration after compaction" (Li et al., arXiv:2607.05378). The three findings fit one story: an untrained, generic summarizer degrades the specific information an agent needs to trust its own prior work, the agent responds by re-deriving that work at a real cost, and the fix has to touch either what gets kept during compaction or where the record of "already done" work lives, not just how good the model is at the underlying task.

How to detect it

• Track exact and near-exact repeats of a tool-call signature, name plus canonicalized arguments, within a single session, and check whether the rate rises specifically in the few steps after each compaction or truncation event rather than staying flat across the session. A rise localized to post-compaction windows is the direct signature the AppWorld study measured.
• Watch the agent's own stop or completion signal quality after compaction, not just its final answer. The 37.3% versus 68.1% completion-recognition gap between summarization and FIFO truncation was measured well before task failure was visible in the output.
• Compare tokens and tool calls per completed task across a session's lifetime rather than only at the end. A task that costs measurably more to finish late in a long session than an equivalent task early in the same session, holding task difficulty constant, is the cost signature of rework rather than of the model getting worse at the task itself.
• Re-run the same task twice under identical conditions at your current compaction settings and compare solved-once-of-two against solved-in-both. A widening gap as context pressure increases is the instability the paper's P@2-versus-P² measurement captures, and it is measurable without any code change to the agent.

Mitigation

Treat compaction as a lossy operation whose failure mode is specific and testable, not as a neutral token-saving utility. Before adopting a summarization strategy, run it through the same before/after tool-call-repeat check described above rather than only checking that final task accuracy holds up; accuracy can look fine while cost quietly climbs.

Prefer targeted, structured pruning over free-text summarization where the record being compacted has a natural structure, exactly what the redundant-information audit above found effective: strip what is verifiably stale or unused rather than re-narrate everything into prose that a later step has to re-parse and re-trust.

Externalize the specific facts an agent is at risk of re-deriving, already-fetched URLs, already-listed directory contents, already-verified preconditions, into the kind of durable, structured record described in state externalization, so that after a compaction event the agent can check a small ledger of "already done" instead of either trusting a lossy summary or defaulting to redoing the work. A ledger entry is cheap to check and expensive to regenerate; a compacted paragraph is neither reliably trustworthy nor cheap to re-verify.

Where the volume justifies it, do not treat the summarizer as fixed. The RL result above suggests that a compaction step trained jointly with the agent's own task objective learns to preserve what that specific agent will need next, which a generic, task-agnostic summarizer cannot do by construction.

Budget for the localized post-compaction window specifically. Since the excess error and repeat rate concentrates in the handful of steps immediately after a compaction event rather than spreading evenly across the session, a cheap intervention, re-anchoring the agent's immediate next step with a short, structured reminder of what it just established, has a narrower and more tractable target than trying to fix compaction quality in general.

Related terms

• Context rot: the input-length reliability problem that compaction exists to treat, and whose treatment produces this side effect.
• Plan decay: a different stale-state failure, where the world changes rather than the agent's record of its own past actions.
• State externalization: the durable-record pattern that gives an agent something cheaper and more trustworthy to check than a compacted summary.
• Behavioral state decay: the umbrella runtime phenomenon this cost pattern is one concrete, measurable instance of.

FAQ

Is redundant re-exploration the same thing as context rot? No. Context rot is the model's reliability degrading as more content sits in an uncompacted window. Redundant re-exploration happens after the standard fix for that problem, compaction or truncation, has already run; it is a side effect of the remedy rather than of the original overload.

Does this mean compaction should be avoided? No, the alternative, an unbounded window, reintroduces context rot and eventually a hard token-limit failure. The AppWorld study's own comparison shows FIFO truncation outperforming naive summarization on multiple measures, which argues for choosing and testing a compaction method deliberately rather than avoiding compaction altogether.

Can this be caught by ordinary accuracy evals? Not reliably. A drift regression test that only scores final task correctness can show flat, healthy accuracy while token and tool-call cost per completed task climbs underneath it, because a redundantly re-explored task can still land on the right answer. The cost-per-task and post-compaction-window metrics above are needed specifically because accuracy alone will not surface this pattern.

Is this only a coding-agent problem? The measured evidence above comes from coding-agent and API-use benchmarks (AppWorld, SWE-bench, Terminal-Bench), but the underlying mechanism, a lossy compacted record making an agent unable to trust or find its own prior work, does not depend on the domain being code. Any agent that both accumulates a long tool-use trajectory and compacts that trajectory to manage token budget is exposed to the same pattern.