How agents manage their own context window

A long-running agent writes its own context window full. Every tool result, every reasoning step, every retrieved document stays in the history by default, and by the time the agent is fifty turns deep the window is mostly exhaust. The question of what to do about that pile used to belong to the framework. The most interesting work of 2026 hands it to the agent.

Agent context management is the practice of deciding what stays in an agent’s working context window as a task runs. For most production systems today that decision is a fixed rule: truncate the oldest turns, keep the last N, or summarize everything when the window fills. A wave of recent research replaces that rule with a learned, runtime policy, and the agents that manage their own context this way outperform the ones running on heuristics. This is what that shift looks like and why it matters.

What “self-managed context” means

Self-managed context is when the decision about what to keep in the working window is made at runtime by a learned policy rather than a static rule in the harness. The distinction is who decides and when. A fixed rule fires on overflow and treats every token the same; a learned policy can act before overflow, weigh which tokens carry signal, and pick a different action for each piece of history. The five approaches below sit on that spectrum, from the framework deciding by rote to the agent deciding for itself.

These are not competing products. They are research directions converging on one idea: context management is a decision worth making well, and a fixed rule makes it badly. The rest of this post walks the spectrum from the bottom up.

Why fixed context rules break on long-horizon tasks

Fixed context rules break because they discard tokens by position, not by value. A long-horizon agent accumulates prior observations and reasoning traces in the prompt over successive steps, which causes roughly linear context growth, and that growth runs straight into the limits of attention well before it hits the token ceiling. Chroma’s study across 18 frontier models found accuracy falling from 95% to between 60% and 70% as input length grew, even on simple tasks, and the lost-in-the-middle effect means a model attends most strongly to the start and end of its context while the middle quietly stops mattering.

Against that backdrop, the common heuristics each fail in a predictable way. Keep-Last-N preserves the most recent turns and throws away an early constraint the task still depends on. Truncate-oldest does the same thing on a sliding window. Summarize-on-overflow waits until the window is full, then compresses everything at once, which is both lossy and badly timed, since the agent has already paid the attention tax of running near capacity. None of these rules know what the task needs. They know only how many tokens are present, and how many tokens are present is the wrong signal. This is one of the mechanical sources of agent drift: a constraint scrolls out of the window, the agent stops honoring it, and nothing in the harness noticed.

The agent as its own context manager

The most direct answer is to let the agent decide. AgentEvolver, from a team at Alibaba and Zhejiang University, gives the agent a self-context-managing template: when its running timeline exceeds a token limit, the policy model selects, for each message, one of three operations from the set keep, remove, or compress, where compression runs through an external summarizing model. The agent is not following a rule about which turns to drop. It is choosing, message by message, what its future self will get to see.

The paper frames the goal as fine-grained control over the token budget and reports that this setup encourages the emergence of self-regulated information filtering, meaning the agent learns to keep what it will need and discard what it will not, rather than applying a uniform cutoff. The keep, remove, compress vocabulary is worth dwelling on, because it cleanly separates the two ways to shrink a window. Remove relocates nothing and recovers nothing; it is a bet that the token is dead. Compress is the in-place reduction that context compression covers in depth, trading detail for room. The agent making that call per message, in flight, is the part that fixed rules cannot do.

Budget-aware compression under a token ceiling

The next refinement is to make the policy aware of how much room it actually has. ContextBudget, introduced by a team at Ant Group, formulates context management as a sequential decision problem with an explicit token-budget constraint, so the agent assesses the budget it has left before it incorporates a new observation and decides then how much history to compress. Its reinforcement-learning variant, BACM-RL, learns these compression strategies under varying budgets through a curriculum, rather than hard-coding a single threshold.

The numbers show why budget-awareness matters. BACM-RL reported over 1.6x gains over strong baselines in high-complexity settings on compositional multi-objective question answering and long-horizon web browsing, and the more telling result is what happened as the budget shrank: most methods showed a downward performance trend as they were given less room, while the budget-aware policy held its advantage. That is the practical case for treating the window as a context budget the policy reasons about, not a wall it hits. An agent that knows it has 8,000 tokens left makes a different and better compression choice than one that compresses only when forced.

Don’t commit to one strategy: route between them

A learned policy still commits to a single action at each step, and the action that looks best now can be wrong in hindsight. AgentSwing, a collaboration including Zhejiang University and Alibaba’s Tongyi Lab, attacks that by refusing to commit. Once accumulated context crosses a threshold, it expands several context-managed branches in parallel, each applying a different strategy such as keep-last-N, summarize, or discard-all, extends each branch forward for a few turns, and uses lookahead routing to continue from the branch that turned out most promising.

The result is that strategy selection stops being a guess. On long-horizon web agent tasks, AgentSwing matched or exceeded its baselines while using up to 3x fewer interaction turns, and it raised the ultimate performance ceiling rather than just trimming cost. The lesson generalizes past the specific method: which context-management move is right depends on what the task does next, and the only way to know that cheaply is to try a few and look ahead a short distance. This is the same instinct behind sub-agent context isolation, where parallel scoped windows let the system explore without one branch’s exhaust polluting another’s.

When the agent can’t be retrained: external managers

Every approach so far assumes you can train the agent’s own policy, which you usually cannot when the agent is a closed-source model behind an API. AdaCoM, from a group at Renmin University and Alibaba, handles that case by moving the manager outside the agent. It trains a separate model to manage a frozen agent’s context through flexible modification actions and end-to-end reinforcement learning, so the curation policy learns while the agent it serves stays untouched. The authors call this agent-compatible, by which they mean it deploys across diverse and closed agents without retraining any of them.

This is the deployment-shaped version of the idea. On web search and deep research benchmarks, an external manager substantially improved performance over running the frozen agent unmanaged, which is the realistic baseline for anyone building on GPT or Claude. The cost is an extra model in the loop and the latency it adds on every turn, so an external manager earns its place on long-horizon tasks where uncontrolled growth would otherwise wreck accuracy, and not on short ones that fit in the window with room to spare. It also makes context management a component you can improve independently, rather than a property baked into a model you do not control.

What this means for building agents

The through-line across all four papers is that context management has graduated from plumbing to policy. The teams pushing long-horizon performance in 2026 are not buying bigger windows. They are getting more deliberate about what occupies the windows they have, and they are increasingly letting a learned policy, the agent’s own or a manager’s, make that call per turn instead of a static rule making it on overflow.

There is a complementary move that makes self-management easier, which is to put less in the window to begin with. A learned policy can only curate what is already present, so the bulk it never has to reason about is the bulk that never entered. This is where keeping reference material outside the window pays off: an agent connected to a Wire container holds a container reference and pulls back only the entries a step queries, so its keep, remove, and compress decisions apply to a small working set instead of a corpus dumped into the prompt. That is offloading, covered in context offloading patterns, and it composes with runtime management rather than replacing it. It is also distinct from the offline approaches like ACE and meta context engineering, which shape context between runs rather than during them.

If you build agents, the actionable version is short. Stop treating the context window as storage with a truncation rule bolted on. Decide explicitly what each turn carries, make the decision against the budget you actually have, and prefer policies that can act before the window is full over rules that fire only when it overflows. The agent that finishes a long task is rarely the one with the most context. It is the one that managed what it kept.

Sources: AgentEvolver: Towards Efficient Self-Evolving Agent System · ContextBudget: Budget-Aware Context Management for Long-Horizon Search Agents · AgentSwing: Adaptive Parallel Context Management Routing for Long-Horizon Web Agents · Learning Agent-Compatible Context Management for Long-Horizon Tasks · Chroma: Context Rot · Lost in the Middle: How Language Models Use Long Contexts