1 Introduction↩︎

The practical success of large language models (LLMs) [1]–[4] in real-world scenarios has been largely enabled by agents [5]–[8]. In the classic ReAct [5] paradigm, LLMs usually act as the central brain that repeatedly reasons about the current task state, calls external tools, and integrates tool responses. The generated information at each step is appended verbatim to the trajectory. As task complexity grows, trajectory length increases linearly [9]–[12]. This poses major challenges for models with a fixed window size, leading to information density dropping, attention dispersing, and reasoning quality degrading. Therefore, agentic context management has become indispensable for solving complex and long-horizon tasks.

A range of techniques[13]–[15] has been proposed to address the long-context bottleneck. The simplest, truncation [16]–[18], retains the most recent content while discarding the more distant historical context using a sliding window. This achieves zero computational cost at the expense of semantic integrity. Unlike truncation, compression does not discard content blindly but rather rewrites raw history into shorter forms. Existing work in this vein adopts three distinct designs. Threshold-triggered compression rewrites the history when a length budget is exceeded or a subtask is completed [19]–[22]. Recurrent compression maintains a fixed-size memory state that is updated via learned mechanisms at every timestep [23]–[25]. Agent-controlled compression places the compression decision in the hands of the LLM itself, exposing context management operations as actions or tools it can invoke [26]–[28].

These methods suffer from common flaws: inflexibility and irreversibility. In agent workflows, the relevance of a given historical step to the current decision evolves flexibly over time. Some steps are critical, offering unique details required at the present moment. Others are redundant, as their content is fully contained or overwritten by later steps. The remainder are simply dispensable. However, truncation and compression treat each historical step equally, ignoring the varying importance of different information, and foreclose the possibility of adaptation. Once content is dropped by truncation or abstracted by compression, the original information cannot be recovered. This becomes problematic when a previously discarded message turns out to be critical, or when a compressed summary fails to preserve a necessary detail.

The above analysis highlights a key requirement: at each decision step, the main LLM that acts as the agent’s primary reasoning module should receive high information density, achieved by adaptively rendering each historical message in its optimal form. Accordingly, we propose the Adaptive Context Elasticizer (ACE).

As shown in Fig. 1, ACE distinguishes two layers: a message maintenance layer, which maintains the raw messages and compressed abstraction of each historical step, and a context orchestration layer, which produces the context that the main LLM actually receives. Before each step, ACE inspects the current task state and assigns one of three decisions, i.e., raw, abstract, or drop, to messages at each step in the message maintenance layer. These states collectively determine the composition of the context orchestration layer at the current step, ensuring the main LLM of the agents receives the most informative view of the trajectory for the decision at hand. Moreover, the presentation format of information from all historical steps is not fixed and can be adjusted on demand in any subsequent step. Given that the message maintenance layer remains immutable, an abstraction that is chosen for use in one step can be reversibly expanded to the full original information in another step. Similarly, information that is dropped in one step can be reversibly reassembled into the context in any subsequent step upon demand. This elastic context orchestration adapts synchronously with the agent’s evolving focus of attention as the task progresses.

By this design, the inflexibility issue could be resolved as ACE is elastic, with the context orchestration layer rebuilt freshly based on the re-evaluated set of states at each step; and the irreversibility issue could be addressed as ACE is lossless, with the message maintenance layer never overwritten by any state assignment. To facilitate simple and flexible integration of ACE into various agent frameworks without substantially altering their native action spaces or message flow, we cast ACE as an external wrapper that encloses the reasoning loop of the original agent framework, thereby providing a more informative context at each step.

Experimentally, based on the classic ReAct agent framework [5], we compare the proposed ACE against truncation and compression methods, showing that ACE can manage the context more effectively than the baseline methods. Moreover, as a training‑free, plug‑and‑play module, ACE is adapted to three other distinct agent frameworks: DeepAgent [29], WebThinker [30], and MiroFlow [31]. Across various benchmark evaluations, ACE consistently improves the performance over the original frameworks.

We summarize the contributions as follows:

1. Decoupling Actual Context from Raw Messages. We devise a maintenance layer for raw messages and compressed abstractions, and an orchestration layer for actual context. This lossless design enables reversible expansion of abstracts and recovery of dropped messages in later steps.

2. Per-step Elastic Context Orchestration. We reorganize every historical message into Raw, Abstract, or Drop based on the current task state at each step, then rebuild the context orchestration layer to minimize redundancy and maximize information density without altering storage.

3. Training-free Plug-and-Play Integration. We implement ACE as an external wrapper around an existing agent’s reasoning loop without modifying action space, message flow, or training, and adapt it to four diverse frameworks: ReAct, WebThinker, DeepAgent, and MiroFlow.

4. Empirical Analysis and Ablation. ACE outperforms truncation and compression on ReAct, and improves performance over the original frameworks when adapted to WebThinker, DeepAgent, and MiroFlow. Further ablation studies confirm the efficacy of the mechanism in the proposed ACE.

2 Related Work↩︎

2.1 Agentic Context Management↩︎

Existing approaches to agentic context management follow four broad designs. Truncation [16]–[18] methods discard trajectory content by position or length, which is entirely content‑agnostic. Threshold‑triggered compression methods, such as ACON [19] and ReSum [20], invoke a compression LLM to summarize the accumulated history when the context length surpasses a budget. The resulting summary then replaces the original trajectory. Recurrent compression methods, exemplified by MEM1 [23], MemAgent [25], and IterResearch [24], train the primary reasoning LLM end‑to‑end to emit a fixed‑size summary state at each step. Agent‑controlled compression methods expose context management to the main LLM as explicit actions or tools. For example, AgentFold [27] introduces a fold action that retrospectively condenses individual steps or consolidates multi‑step sub‑tasks, whereas Memory‑as‑Action [26] formulates precise compression operations as actions governed by a trained policy. Across all four families, every compression decision is final and cannot be revised in later steps. Moreover, recurrent and agent‑controlled methods modify the underlying framework, extend the action space or tool set, and require additional training. These two limitations motivate ACE, which retains the full trajectory in a separate storage layer so that every assignment remains revisable and flexible, and operates as an external wrapper so that no change to the original agent frameworks or any further training is needed.

2.2 Agentic Foundation Models↩︎

To elevate agent performance, a complementary line of work is to enhance the intrinsic agentic abilities of foundation models [1]–[4]. The key design axis is context scaling, which extends the maximum context length that the model can ingest, for instance via sparse or recurrent attention [16], [32]–[34] or via positional interpolation [35], [36]. These advances increase the maximum trajectory length an agent can handle before hitting the window limit, yet they fail to resolve a deeper problem: even within the supported window, models attend non‑uniformly to long inputs and their performance drops well before the nominal bound [37]–[39]. ACE takes an orthogonal approach: it stays within the LLM’s existing context limit but focuses on raising the information density of the presented context, rather than expanding the window size.

3 Method↩︎

In this section, we present the Adaptive Context Elasticizer (ACE) in detail. We first propose to decouple the construction of the actual decision-making context from the step-wise raw messages within an agent framework in Sec. 3.1, in which we devise the two-layer framework for message maintenance and context orchestration in ACE. Subsequently, we describe ACE’s paradigm of elastically orchestrating historical messages into context at each step in Sec. 3.2. Finally, we demonstrate how to adapt ACE to existing agent frameworks in a plug-and-play manner in Sec. 3.3.

3.1 Decoupling Actual Context from Raw Messages↩︎

Given a task \(\mathcal{T}\) to be resolved by the agent, at each step \(t\), it outputs the reasoning \(r_t\) on the current state, produces an action \(a_t\) for tool invocation, and receives the observation \(o_t\). Then, the newly generated information at step \(t\) is packed as \(h_t^{\text{raw}} = (r_t, a_t, o_t)\) and will be appended into the trajectory. We denote \(\mathcal{H}_t = \{h_1^{\text{raw}}, \dots, h_{t-1}^{\text{raw}}\}\) as the raw messages accumulated before step \(t\), under the ReAct paradigm, the input of the agent at step \(t\) is \(\mathcal{H}_t\). With the accumulation of raw stepwise information over a trajectory, the growing redundancy and surging volume pose significant challenges for the main LLMs of agents in reasoning and making decisions effectively. Existing agent frameworks often manage \(\mathcal{H}_t\) in place through linear concatenation, threshold-triggered compression, or recurrent rewriting. In such designs, any decision becomes irrevocable: once a step is truncated or compressed, the original information is permanently lost.

To this end, we propose to decouple the raw messages \(\mathcal{H}_t\) from the context \(\mathcal{C}_t\) that the agents actually receive at step \(t\). To effectuate this decoupling design, we devise a two-layer framework in ACE, including a message maintenance layer for storing raw messages and compressed abstractions, and a context orchestration layer that provides the agent with the actual context.

Message Maintenance Layer. We denote this layer by \(\mathcal{M}\), and it is formulated as: \[\begin{align} \label{eq:mm95layer} \mathcal{M} = \bigcup_{i=1}^{t}(h_i^{\text{raw}}, h_i^{\text{abs}}), \end{align}\tag{1}\] where \(\bigcup\) is the union operator. Upon completion of a step \(i\), the raw message \(h_i^{\text{raw}}\) generated from that step, including reasoning, actions, and observations, is recorded in \(\mathcal{M}\). In addition, we also preserve a compressed abstraction \(h_i^{\text{abs}}\) summarized by an auxiliary LLM for each step. The abstraction leads with a conclusive result; preserves task‑critical facts such as numbers, URLs, dates, IDs, formulas, quotations, and tool schemas; renders tool call failures explicit by stating the attempted action, the cause of failure, and the measures to avoid; and retains explicit follow‑up signals. Furthermore, once the raw information and compressed abstraction \((h_i^{\text{raw}}, h_i^{\text{abs}})\) of this step are recorded, they are never modified, thereby preserving the completeness and traceability of the information from each historical step.

Context Orchestration Layer. Unlike existing agent frameworks that feed the main LLM with either a lengthy concatenation of raw messages, or irreversibly compressed or truncated content at each step, we adaptively tailor the context to the evolving task state. Specifically, the actual context \(\mathcal{C}_t\) consists of three segments:

The task description \(\mathcal{T}\) is placed at the start of the context and remains free from any summarization or truncation. This guarantees that the agent’s reasoning and action execution stay aligned with the task.

As for the historical steps ranging from \(1\) to \(t-2\), we adaptively incorporate their information into the context in different forms, conditioned on the current task state. For historical steps that contain the specific details and essential justifications required for the current decision step, their raw messages are selected. For steps that provide transitional content or high‑level overviews relevant to the current decision step, their compressed abstraction is selected. For steps that are irrelevant to the current decision step, or whose information has been modified or superseded by subsequent steps, they are omitted from the current context entirely.

The final part of the context is fixed as the complete information of the last step, enabling the current decision step to have a full understanding and assessment of the latest state of task execution.

This design reduces the redundancy that occupies the context window, leading to more effective reasoning and action execution. Formally, the actual context \(\mathcal{C}_t\) is mainly orchestrated through the function \(\phi\): \[\begin{align} \label{eq:col} \mathcal{C}_t =\; \text{Concat}\;(\mathcal{T}, \phi\left(h_1^{\text{raw}},h_1^{\text{abs}},\,d_1^{t}\right), ..., \phi\left(h_{t-2}^{\text{raw}},h_{t-2}^{\text{abs}},d_{t-2}^{t}\right), h_{t-1}^{\text{raw}}) \end{align}\tag{2}\] where \(d_i^{t} \in \{\text{Raw},\,\text{Abs},\,\text{Drop}\}\) denotes the decision made at step \(t\) regarding how the information of historical step \(i \in [1, t-2]\) is orchestrated in the actual context \(\mathcal{C}_t\) input to the agent. The function \(\phi\) then applies the per-step selection according to the decision \(d_i^{t}\), which outputs the raw data \(h_i^{\text{raw}}\) when \(d_i^{t}\) is , or the compressed abstraction \(h_i^{\text{abs}}\) when \(d_i^{t}\) is , or nothing when \(d_i^{t}\) is .

3.2 Per-step Elastic Context Orchestration↩︎

Building upon the complete preservation of historical information by the message maintenance layer and the composition of the actual context by the context orchestration layer, we present the detailed mechanism of ACE’s per-step elastic orchestration from historical information to the actual context.

The core is the step-wise decision \(d_i^{t} \in \{\text{Raw},\,\text{Abs},\,\text{Drop}\}\) predicted by the elasticizer \(\mathcal{E}\), which is instantiated as an LLM. Its input is the task description \(\mathcal{T}\) together with the abstractions \(\{h_i^{\text{abs}}\}_{i=1}^{t-1}\) drawn from the message maintenance layer \(\mathcal{M}\), formulated as: \[\begin{align} \label{eq:els} d_i^{t} = \mathcal{E}(\mathcal{T},h_1^{\text{abs}},...,h_{t-1}^{\text{abs}}). \end{align}\tag{3}\]

Through this design, the elasticizer gains full visibility into all historical information while keeping its input length within the sum of per‑step abstraction lengths. As a result, the elasticizer can reliably predict orchestration decisions within the effective context window. It is worth noting that the elasticizer’s decisions are advisory for the interior portion of the context, i.e., steps ranging from \(1\) to \(t-2\), but have no effect on the fixed boundary positions. Consequently, the most recent step \(t-1\) is always included in its raw messages as formulated in Eq. 2 , irrespective of the elasticizer’s output.

Due to the decoupling of historical information from the actual context and the per‑step orchestration of the context, ACE provides reversibility and flexibility. A historical step compressed at one decision step can be restored to its raw form in subsequent decision steps when necessary, and a discarded historical step can be retrieved as needed. Hence, the non‑boundary part of the context becomes genuinely elastic, modulated by the agent’s dynamically evolving states.

3.3 Training-free Plug-and-Play Integration↩︎

Since ACE runs completely on top of its own two‑layer architecture without altering the agent’s state, action space, or control flow, its adaptation to existing agent frameworks requires no training and is plug‑and‑play. Specifically, after the agent completes its reasoning, action execution, and observation acquisition at each step, the raw messages and generated corresponding abstraction from each step are stored in the message maintenance layer. Then, before the agent begins its reasoning at each step, the actual context is organized by the context orchestration layer. This lightweight interface enables the instantiation of ACE on four agent frameworks with distinct structures: ReAct [5], WebThinker [30], DeepAgent [29], and MiroFlow [31]. Collectively, these frameworks span single‑agent, main‑auxiliary, and multi‑agent architectural topologies.

4 Experiments↩︎

We begin by detailing the experimental setup in Sec. 4.1. Then, Sec. 4.2 presents a comparison between our proposed ACE method and baseline methods based on the ReAct framework. In Sec. 4.3, we validate the plug‑and‑play adaptability of ACE across multiple agent frameworks beyond ReAct by applying it to DeepAgent [29], WebThinker [30], and MiroFlow [31], and demonstrate the resulting performance improvements. Furthermore, we present a series of analytical experiments on the per-step input token length in Sec. 4.4, elastic type evolution of historical steps in Sec. 4.5, ablation on the composition of elastic types in Sec. 4.6, and ablation on whether to keep the last step as raw in Sec. 4.7.

4.1 Experimental Setup↩︎

In our experiments, we choose GPT-4.1 and Gemini-3.1-flash-lite-preview as the main LLMs of the agent frameworks for generality. As for the proposed ACE, the elasticizer \(\mathcal{E}\) is set to be the same as the main LLM, and the auxiliary LLM used for generating the compressed abstraction is uniformly set to GPT-4o. Regarding the tools, to support the web search, we use the Google Serper API. The page browsing is implemented using the Jina Reader API. Besides, for comprehending the images, the multimodal understanding model is also implemented using GPT-4o. Considering the benchmarks, in the comparison with baseline methods in Sec. 4.2, we select GAIA [40], HLE [41], and WebShop [42] for evaluation. In experiments adapting ACE to more agent frameworks in Sec. 4.3, we select the benchmarks adopted by the original agents. In detail, GAIA, HLE, and WebShop are selected for evaluation in DeepAgent; GAIA, WebWalkerQA [43], and HLE are selected for evaluation in WebThinker; GAIA, xBench-DS [44], and BrowseComp-ZH [45] are selected for evaluation in MiroFlow. All experiments are implemented from scratch by our setups.

4.2 Comparison with Context Management Baselines↩︎

Based on the classical ReAct paradigm, we compare our proposed ACE method with existing context management baselines, including no context management, truncation‑based management, and summarization‑based management. Specifically, no context management refers to the original design of ReAct. As for the implementation of the truncation method, we retain the raw messages of the latest 5 steps, while others are discarded. Besides, we implement the summarization method such that the raw messages of the latest 5 steps are retained, while others are summarized. We set the main LLMs as GPT-4.1 and Gemini-3.1-flash-lite-preview for generality, and limit the maximum action steps to 50. The experimental results are presented in Table 1.

As reported in Table 1, ACE achieves the best overall performance among all compared methods under both main LLMs across the three benchmarks. For example, on GAIA, ACE improves the overall score from 38.8 to 42.4 when using GPT‑4.1, and from 46.1 to 52.7 when using Gemini‑3.1‑flash‑lite‑preview, outperforming the baselines. The baseline behaviors corroborate our motivation. Truncation consistently degrades performance on GAIA, whose tasks may require evidence from earlier steps that a sliding window irreversibly discards; yet it improves performance on HLE relative to vanilla ReAct, indicating that the redundancy in raw trajectories indeed dilutes information density. Summarization partially mitigates information loss on GAIA with GPT‑4.1 but fails when we use Gemini‑3.1‑flash‑lite‑preview, suggesting that a one‑shot, irreversible summary may omit details whose importance only becomes apparent later. By reassessing the optimal form of every historical step at each turn and losslessly restoring or dropping content on demand, the proposed ACE sustains high information density in the context, thereby enabling more effective reasoning compared with baselines.

4.3 Adapting ACE as a Plug-in to Multiple Agents↩︎

ACE is designed to be a plug‑and‑play context manager that can be seamlessly integrated into different agent frameworks. To verify its generality, this section adapts ACE to three frameworks beyond ReAct, including DeepAgent [29], WebThinker [30], and MiroFlow [31]. The performance is evaluated on the same benchmarks as those originally reported for each.

Table 2 reports the results on DeepAgent after its native memory fold mechanism is replaced with ACE. On GAIA, ACE raises the overall performance from 40.0 to 41.8 with GPT‑4.1 and from 46.7 to 51.5 with Gemini‑3.1‑flash‑lite‑preview, while also achieving consistent improvements on HLE and WebShop. These findings indicate that ACE successfully outperforms the original memory fold mechanism. As reported in Table 3, ACE brings larger gains when applied to the WebThinker. The overall performance of GAIA increases by at least 8 points, accompanied by a marked improvement on the L2 subset. This pattern is consistent with the view that extended trajectories are especially vulnerable to redundant information, which our method successfully alleviates. Beyond GAIA, ACE also yields performance improvements on WebWalkerQA and HLE. These findings suggest that for WebThinker, which does not incorporate any context management by default, the adoption of ACE leads to consistent performance gains. Furthermore, when ACE is adapted to the MiroFlow framework, consistent performance improvements are observed across two models and three benchmarks in Table 4. Notably, on the GAIA benchmark with GPT‑4.1 as the main LLM, ACE achieves a substantial performance advantage of nearly 10 points. These results demonstrate that ACE effectively reduces redundant information in each decision‑making step, thereby enhancing the final performance.

Across all four agent frameworks, i.e., ReAct, DeepAgent, WebThinker, and MiroFlow, ACE consistently improves the performance with neither training nor modification to the native action spaces. This indicates that ACE is a genuinely plug‑and‑play context manager, its effectiveness being agnostic to the underlying agent architecture. The combination of generality, seamless integration, and consistent gains positions ACE as a readily deployable enhancement for existing and future agent frameworks.

4.4 Analysis on the Per-Step Input Token Length↩︎

To further investigate how ACE influences the adaptive organization of context during task execution, we conduct a comparative analysis using Gemini‑3.1‑flash‑lite‑preview as the main LLM on the GAIA benchmark. Specifically, we compare the average per‑step input token length of the main LLM on all tasks across four settings, including ReAct, ReAct with truncation, ReAct with summarization, and ReAct with the proposed ACE, under maximum action step limits of 50 and 100. The results are presented in Fig. 2.

Under both maximum action step constraints, vanilla ReAct without any context management exhibits a continuously increasing trend in per‑step input token length as the number of executed steps grows. This leads to challenges such as exceeding the LLM’s context window and accumulating redundant information. For the two baseline methods, summarization and truncation both retain only the raw messages of the most recent five steps. Additionally, summarization includes a summary of information from steps beyond the most recent five, whereas truncation does not, resulting in the per‑step input token length of summarization being slightly higher than that of truncation. Consequently, both approaches maintain per‑step input token length within a relatively low range, effectively suppressing the linear growth of input tokens. However, as shown in Table 1, suppressing the growth of the input context may incur negative performance impacts. For example, when Gemini‑3.1‑flash‑lite‑preview is used as the main LLM on GAIA, both ReAct with truncation and summarization achieve lower overall performance than vanilla ReAct. This indicates that these two context management approaches lack flexibility and inevitably cause irreversible loss of important information from distant steps, thereby compromising overall task performance.

As for the proposed ACE method, similar to the two baselines, it achieves a per‑step input token length significantly lower than that of ReAct. When we compare ACE with the two baselines in the early steps, ACE exhibits a slightly lower average input token length. This is because the baselines have not yet activated their management mechanisms at the early stage, thus retaining raw historical messages throughout, whereas ACE’s elastic orchestration naturally yields a shorter input. As the task proceeds, ACE’s average input token length overtakes that of the baselines and exhibits a gradually increasing yet fluctuating trend. This observation indicates that ACE does not rigidly constrain the input length within a fixed range. Instead, it adaptively and dynamically orchestrates the presentation form of each historical step for the current decision step according to the evolving task state, flexibly discarding redundant messages, retaining necessary information, and even reversibly recalling information that was discarded in previous decision steps.

In summary, simply relying on truncation or summarization to reduce context pressure is not an optimal solution, as it may lead to information loss. The effectiveness of our proposed ACE method, which flexibly and elastically organizes the context according to the task state, is thus fully validated.

4.5 Analysis on the Elastic Type Evolution of Historical Steps↩︎

Beyond the analysis of per-step input token length, observing and analyzing how the elastic type of each historical step evolves within the context of each decision-making step as the task progresses can further advance the understanding of the mechanism of ACE. Therefore, in the setting where Gemini‑3.1‑flash‑lite‑preview serves as the main LLM and ACE is adapted to the ReAct framework, we select one task from GAIA and one from HLE. Based on their trajectories, we visualize the evolution of the elastic type of historical steps over the decision steps, as shown in Fig. 3.

By design, the last step in the context is always retained as raw messages. Therefore, all diagonal blocks are marked as raw. Proceeding horizontally from left to right illustrates how the elastic type of the same historical step evolves across updated decision steps as the task progresses. The manifestation of a historical step in future decision contexts is not fixed. Raw messages may become a compressed abstraction or even be dropped as irrelevant in the next decision step. Conversely, information that has been compressed into an abstraction or dropped may be reinstated as raw in the next step.

Furthermore, viewing from bottom to top along the vertical axis reveals, within a single decision step, the elastic type composition of information ranging from the earliest steps to the most recent steps. Evidently, the agent neither demands that all steps be raw messages nor that all steps be compressed abstractions; in fact, some historical information may be entirely ignored by the current decision step. Crucially, this pattern of multiple elastic types is not fixed but evolves over time. Additionally, we observe that the proportion of non‑drop information also fluctuates across different decision steps, which further corroborates the slowly fluctuating growth trend of the per‑step input token length of ACE reported in Sec. 4.4.

These findings underscore the necessity of adaptively organizing the context in accordance with the task state as the agent proceeds. By contrast, existing approaches rigidly employ truncation or summarization solely for reducing context length, while neglecting the organization of effective context.

4.6 Ablation Study on the Composition of Elastic Types↩︎

To further analyze the impact of different elastic type compositions on ACE’s performance, we compared three additional combinations, including \(\{\text{Raw},\,\text{Abs}\}\), \(\{\text{Raw},\,\text{Drop}\}\), and \(\{\text{Abs},\,\text{Drop}\}\), under the setting where ACE is adapted to the ReAct framework. The comparison results on GAIA are presented in Table ¿tbl:tab:elas95type?.

It is apparent that any of the compared combinations leads to a performance degradation of ACE. Among them, although \(\{\text{Raw},\,\text{Abs}\}\) minimizes information loss, it inevitably introduces task‑irrelevant redundancy that hampers effective reasoning and decision making, thus leading to performance drops. As for \(\{\text{Raw},\,\text{Drop}\}\), it is similar to truncation in that each historical step can only be either raw messages or dropped. Nevertheless, ACE with \(\{\text{Raw},\,\text{Drop}\}\) still possesses a flexibility edge over truncation, yielding a modest overall advantage. Specifically, when GPT‑4.1 is used as the main LLM, the average performance is 37.6, compared with 37.0 for truncation in Table 1; and when Gemini-3.1-flash-lite-preview is used as the main LLM, it achieves 44.8, compared with 43.0 for truncation in Table 1.

In addition, the \(\{\text{Abs},\,\text{Drop}\}\) setting is associated with the greatest degree of information loss. With this configuration, the agent is perpetually unable to extract adequate detail from raw messages, and is forced to perform reasoning and decision making based solely on abstracted information. Consequently, its final judgments are severely affected, leading to the lowest average performance among all compared settings.

r0.48

It is imperative for agent context management to adaptively orchestrate historical step information across the three distinct elastic types in accordance with task progression. The omission of any single type inevitably incurs either accumulation of redundant information or excessive loss of detail, leading to performance deterioration. These observations further corroborate the validity of the proposed ACE framework.

4.7 Ablation Study on the Elastic Type of Last Step↩︎

Another important design feature in ACE is that we always retain the information of the most recent step as raw messages when elastically orchestrating historical steps to build the context for each decision step. This ensures that the latest and most complete task state is available. To assess the necessity of this design, we conduct a comparison on GAIA under the ReAct‑based ACE setup, evaluating two settings: one with adaptive orchestration of the last step, and the other with it kept as raw. Table [tbl:tab:last95step95abla] summarizes the comparison results.

From the experimental results, we observe that preserving the information of the last step in its raw message form throughout the context leads to robust performance improvements. Conversely, allowing adaptive adjustments to the last step carries the risk of misrepresenting the latest task state, compelling the agent to reason from outdated states and thus adversely affecting task progress. Thus, the effectiveness of the design that retains the last step as raw is validated.

5 Conclusions↩︎

We propose the ACE, a training‑free and plug‑and‑play context elasticizer that addresses the inflexibility and irreversibility of existing agent context management methods. By decoupling lossless message storage from per‑step elastic orchestration, ACE allows historical information to be adaptively presented as raw, abstraction, or dropped according to the evolving task state, while preserving the ability to recover previously discarded or compressed content when needed. We integrate ACE into four diverse agent frameworks without modifying their native architectures, and demonstrate consistent performance improvements across GAIA, HLE, WebShop, and other benchmarks.

References↩︎