Summary (Overview)

• SWE-MeM is a training framework that equips long-horizon software engineering agents with proactive and on-demand memory management, allowing the agent to decide when, what, and how to compress its context based on trajectory state, task progress, and remaining context budget.
• The framework introduces a flexible memory tool (compress) with arguments for analysis, step range, summary content, and remaining work, enabling selective compression of low-value context spans rather than rigid full-history summarization.
• Training combines synthesized proactive memory-management trajectories, curriculum fine-tuning (two stages: general tool use, then targeted proactive behavior), and Memory-aware GRPO with memory-aware trajectory splitting and step-level credit masking.
• On SWE-Bench Verified, SWE-MeM achieves 43.4% resolve rate with a 4B model and 60.2% with a 30B model under a 32K context budget, outperforming existing memory management baselines in both performance and efficiency.
• Ablations confirm that proactive triggering, selective span compression, curriculum SFT, and Memory-aware GRPO each contribute meaningfully; removing the memory tool drops performance even with a 256K context window.

Introduction and Theoretical Foundation

Background and Motivation. Long-horizon software engineering agents typically follow a ReAct-style append-only paradigm where interaction history accumulates indefinitely. In software engineering tasks, lengthy environment feedback, verbose logs, and numerous intermediate actions quickly exceed LLM context windows, and even when history fits, agents struggle to effectively utilize task-relevant information from long, noisy trajectories.

Limitations of Existing Methods. Prior memory management approaches suffer from two key limitations:

1. Inflexibility: Fixed compression rules (threshold-based summarization, subtask-level folding, or window-based compression) cannot adapt to the heterogeneous value of information. Lengthy execution logs can be safely compressed at any point, while early code inspections may remain essential for later reasoning.
2. Suboptimal optimization objectives: Existing methods optimize context reduction rather than task-solving efficiency. As shown in Figure 1(c), they reduce peak context length but dramatically increase total token usage or interaction steps.

Key Insight. The authors argue that effective memory management should be learned as a decision-making capability—the agent should decide when to compress, what to compress, and how to summarize—jointly optimized with issue resolution capability.

Methodology

1. Memory Management Tool Design

The interaction history at time step $t$ is represented as:

$$C_{t} = \langle p, \{a_{1}, o_{1}\}, \{a_{2}, o_{2}\}, \ldots, \{a_{t-1}, o_{t-1}\} \rangle \tag{1}$$

where $p$ is the problem statement, $a_i$ is the agent action (text, reasoning, tool calls), and $o_i$ is the environment observation augmented with metadata (step number, remaining context length).

The agent invokes the memory tool:

compress(analysis, start_step_number, end_step_number, content, remaining_work)

• analysis: assessment of current progress and unresolved subtasks
• start_step_number $s$ and end_step_number $e$: span to compress
• content $c$: summary replacing the selected span
• remaining_work $f$: remaining subtasks appended to the end of the trajectory

The compression operation transforms the context as:

$$C_{t} \xrightarrow{\mathcal{M}} C_{t}^{\prime} = \langle p, \{a_{1}, o_{1}\}, \ldots, \{a_{s-1}, o_{s-1}\}, \{c\}, \{a_{e+1}, o_{e+1}\}, \ldots, \{a_{t-1}, o_{t-1}\}, \{f\} \rangle \tag{2}$$

2. Trajectory Synthesis and Curriculum Fine-Tuning

Synthesis Workflow. The base model generates task-solving rollouts; a proprietary model (GPT-5.1) handles only proactive-trigger judgment and memory-tool argument synthesis. A context monitor triggers compression based on two conditions:

• Context budget pressure: probabilistic scheduler—trigger probability becomes non-zero below 20% remaining budget, reaching 1 at 5%.
• Proactive memory management: three cases detected via LLM-as-a-judge:
  • Subtask completion: retain only the conclusion
  • Low-information density: verbose logs or irrelevant exploration
  • Focus degradation: long noisy context distracts from the core issue

Quality Filtering. Rejection sampling retains trajectories passing test cases, then rule-based cleaning masks defective assistant messages (rather than discarding whole trajectories). Filters include:

• Inappropriate reduction ratio (above 80% or below 20%)
• Overly short compression ranges
• Range misalignment (summary doesn't match declared step range)
• Low-quality responses (empty, repetitive, truncated, invalid tool calls)

Curriculum Learning. Two-stage training:

1. Stage 1: Train on full filtered synthetic trajectories to learn basic tool format and usage.
2. Stage 2: Targeted training on proactive memory trajectories (rubric-filtered) mixed with budget-based compression trajectories (filtered for effective information reuse), preventing catastrophic forgetting.

3. Memory-aware GRPO

Trajectory Splitting. Rollouts are checkpointed at compression steps and split into sub-trajectories, each starting from the exact compressed prefix observed online. Loss aggregation averages token-level objectives within each rollout first, then averages rollout-level losses across the batch:

$$\mathcal{L} = \frac{1}{S} \sum_{i=1}^{S} \bar{\ell}_{i}, \quad \bar{\ell}_{i} = \frac{1}{N_{i}} \sum_{k=1}^{K_{i}} \sum_{t=1}^{T_{i,k}} \ell_{i,k,t} \tag{3}$$

where $N_i = \sum_{k=1}^{K_i} T_{i,k}$ is the number of valid tokens in rollout $i$, and $S$ is the batch size.

Step-level Credit Masking. The Memory-aware GRPO objective is:

$$\mathcal{J}_{\mathrm{MGRPO}} = \mathbb{E}_{i} \left[ \frac{1}{M_{i}} \sum_{k=1}^{K_{i}} \sum_{t=1}^{T_{i,k}} m_{i,k,t} \times \min \left( r_{i,k,t} \hat{A}_{i}, \operatorname{clip}(r_{i,k,t}, 1-\epsilon, 1+\epsilon) \hat{A}_{i} \right) \right] \tag{4}$$

where $m_{i,k,t} \in \{0,1\}$ controls gradient contribution, and $M_i$ is the number of unmasked valid tokens. Masking strategies:

• Memory Management Action Quality: mask steps with poor reduction ratios, short ranges, or misalignment
• Late Memory Management: mask compression actions occurring after budget drops below threshold $\tau$
• Overflow Failure: in overflow trajectories, penalize only steps where budget is below $\tau$ but no compression is invoked
• Invalid Tool Usage: mask steps with invalid tool calls or repetitive content

Empirical Validation / Results

Main Results (SWE-Bench Verified)

Efficiency Comparison

SWE-MeM achieves the best performance while maintaining the lowest token usage among memory-management baselines, and uses fewer tokens than the base ReAct agent.

Ablation Study

• Proactive vs. threshold-based invocation: replacing proactive triggering drops resolve rate from 58.8% to 57.4%
• Selective vs. full-trajectory summarization: replacing selective span selection drops to 57.6%
• Curriculum SFT vs. vanilla SFT: improves from 40.8% to 41.6% (4B model); proactive invocation proportion increases from 2.3% to 16.1% (4B) and 4.1% to 14.7% (30B)
• Memory-aware GRPO vs. vanilla GRPO: consistently outperforms on both model scales
• Memory tool removal: with 256K context and no memory tool, 4B model drops from 43.4% to 37.6%—memory management provides a cleaner working context, not just overflow prevention

Cross-Benchmark Generalization

Learned memory management transfers across programming languages and provides clear gains on longer-horizon tasks.

Theoretical and Practical Implications

Theoretical Implications.

• The work reframes memory management as a learnable decision-making capability rather than a fixed engineering heuristic, aligning with the broader trend toward trainable agent policies.
• Memory-aware GRPO introduces a principled approach to credit assignment in settings where the context state changes mid-trajectory, addressing a fundamental challenge in RL for agents with state-modifying actions.
• The two-stage loss aggregation prevents length bias in RL training—a general issue when rollouts have highly variable lengths.

Practical Implications.

• SWE-MeM demonstrates that smaller models with effective memory management can compete with or exceed much larger models using larger context windows (4B model with 32K context achieves 43.4% vs. 30B models with 128K context at similar levels).
• The framework reduces token usage below base ReAct agents, directly lowering inference costs.
• The curriculum training approach and quality filtering pipeline provide a practical recipe for training agents with tool-use capabilities.
• The Workflow-only variant (no training, external LLM for compression decisions) achieves 58.4%, offering a cost-effective deployment option before investing in fine-tuning.

Conclusion

SWE-MeM presents a comprehensive framework for training long-horizon software engineering agents with proactive, on-demand memory management. The key contributions are:

1. A flexible memory tool enabling agents to decide when, what, and how to compress based on trajectory state.
2. A training pipeline combining trajectory synthesis, curriculum fine-tuning, and Memory-aware GRPO that jointly optimizes memory decisions and task-solving performance.
3. State-of-the-art results on SWE-Bench Verified (43.4% with 4B, 60.2% with 30B under 32K context), outperforming existing memory management methods in both performance and efficiency, with demonstrated transfer to SWE-Bench Multilingual and SWE-Bench Pro.

Future directions implied by the work include: extending the approach to other long-horizon agent domains beyond software engineering, exploring more sophisticated credit assignment mechanisms, and investigating whether the learned memory policies can transfer across different base models or scaffolds. The authors also suggest that memory management does more than prevent overflow—it provides a cleaner working context that improves reasoning quality—which opens questions about the interaction between memory organization and model reasoning capabilities.