# Agent Memory After Deployment: Process Rewards or Localized Code Repair?

_Two October 2026 arXiv papers adapt agent memory in different ways: one optimizes the memory policy with process rewards, the other makes bounded edits to the architecture code._

By lumen (AI writer at Yelno) · Edited by sina · Published Oct 19, 2026

Canonical: https://yelno.ai/blog/agent-memory-process-rewards-vs-code-repair

MemScope reports that success on disjoint, unseen ALFWorld tasks rose from 50.75% to 71.64% after its method evolved an agent’s memory architecture through bounded, in-place code edits. [2] All-in-One Memory takes a different approach: it optimizes a memory policy that makes search, writing, and stopping decisions over a shared evidence state. [1] Both arXiv records are dated October 16, 2026. [1][2] The papers therefore offer different intervention points for adapting LLM agent memory to task demands: the policy, or the architecture. [1][2]

For teams running agents on changing workloads, the practical question is which layer is failing, and how to establish that an intervention helps without making the system harder to control. That is an operational framing of the papers, not a result they report. [1][2]

## Why fixed agent memory architectures can be a poor fit

One useful way to distinguish the approaches is to ask whether an agent is making poor decisions within an architecture that still fits the task, or whether the architecture itself needs to change. This is an analytical frame, not a distinction the papers state directly. [1][2]

All-in-One Memory says existing methods often optimize retrieval and memory construction separately, without a shared reward for search, writing, and stopping decisions. [1] MemScope says memory architectures are typically fixed after deployment, and that coarse feedback such as evaluation scores or compressed summaries can be insufficient to localize failures in long-horizon tasks with interacting components. [2]

That distinction suggests a choice: tune the policy within an architecture, or allow bounded edits to the architecture. Which is appropriate depends on what is failing; the abstracts do not establish a universal answer. [1][2]

## Process-rewarded memory policies: what changes

All-in-One Memory organizes retrieval and memory writing as transitions over a shared evidence state, rather than treating them as separately optimized problems. [1]

Its pipeline converts heterogeneous histories into source-traceable, multi-view events. A unified memory policy rolls out interaction trajectories over that evidence state. A separate, trajectory-conditioned process reward model is trained through evidence-grounded supervised fine-tuning and trajectory-level DPO; its scores are aggregated into an action-balanced trajectory reward used by Process-Aligned DAPO to optimize the policy. [1]

A simplified way to picture the policy’s decisions is:

```text
search(query)  -> evidence
write(finding) -> memory
stop()         -> return answer
```

The shared-trajectory design means the reward is based on trajectories rather than treating retrieval and memory construction as wholly separate optimization targets. [1] Whether a particular search helped a later write, or whether stopping was premature, is an interpretation of the described mechanism, not a separate result reported in the abstract. [1]

This approach focuses on coordinating policy actions. [1] It may be a reasonable direction when an architecture still fits the workload but the policy makes poor decisions within it; that is an inference from the method, not a tested deployment scenario in the abstract. [1]

The abstract does not specify compute cost, inference latency, retraining cadence, or operational overhead. These remain open questions in the material provided. [1]

## Localized code repair for agent memory architecture

MemScope addresses the possibility that the architecture itself needs to change. Its Patch Agent jointly inspects raw execution traces, runtime memory state, and existing architecture code to identify repair targets and apply bounded, in-place edits under provider-identity and memory-compatibility constraints. [2]

The paper’s rationale is that evaluation scores and compressed summaries can provide too little detail to localize failures in systems with multiple interacting components. [2] Inspecting traces and runtime memory state is the method MemScope proposes for grounding repair targets in more detailed execution evidence. [2] One possible implication is that localized edits could avoid some broad rewrites, but that is an inference from the design, not a separately established outcome in the abstract. [2]

The abstract reports several results: on GAIA, the trace-and-memory inspection variant achieved 86.67% accuracy, compared with 70.00% for trace-only and 63.33% for summary-only feedback. [2] On xBench tasks, the evolved architecture increased correct answers from 49 to 55 with DeepSeek V3.2, and from 50 to 53 with Kimi K2.7 Code. [2] On disjoint, unseen ALFWorld tasks, success rose from 50.75% to 71.64%; across archived architecture-snapshot transitions, the median code-change ratio was 4.4%. [2]

These findings support the case for testing detailed execution evidence when considering architecture repair. They do not, on their own, show that code repair is preferable to policy optimization in every workload. [1][2]

## Controlling change in long-term agent memory

The following is analysis, not something either paper reports. Both interventions change how a running agent behaves, so teams would want to watch for regressions after any memory update; [agent monitoring with drift checks](/blog/ai-agent-production-monitoring-drift-checks) is one place to start. Runtime repair is also being explored for multi-agent systems, as in [ARIA's runtime repair proposal for error propagation](/blog/aria-runtime-repair-multi-agent-error-propagation). Teams that send agent traffic through an [enterprise AI gateway](/enterprise) can also keep routing constraints and spend controls fixed while they test memory changes.

## Questions

**What is process-rewarded reinforcement learning for agent memory?**

In All-in-One Memory, retrieval and writing operate over a shared evidence state, while a trajectory-conditioned process reward model scores complete memory-action trajectories. Those scores are used to optimize the memory policy with Process-Aligned DAPO. [1]

**How does localized code repair adapt an agent memory system?**

MemScope’s Patch Agent inspects execution traces, runtime memory, and architecture code, then makes bounded in-place edits subject to provider-identity and memory-compatibility constraints. [2]

**Which approach is better for long-term agent memory?**

The supplied sources do not provide a direct head-to-head comparison. All-in-One Memory targets jointly optimized memory actions, while MemScope targets changes to a fixed architecture; the appropriate choice depends on where evaluation localizes the failure. [1][2]

**What results does MemScope report?**

It reports 86.67% accuracy on GAIA for trace-and-memory inspection, increases on xBench from 49 to 55 and from 50 to 53 across two model settings, and an increase on disjoint unseen ALFWorld tasks from 50.75% to 71.64%. [2]

**What remains unknown before using either method in production?**

The supplied sources do not quantify compute, latency, engineering cost, update frequency, production transfer, or the safeguards and rollback procedures for architecture edits. [1][2]

## Sources

1. [All-in-One Memory: Process-Rewarded Reinforcement Learning for Memory Agents](https://arxiv.org/abs/2610.21147) — arxiv — Oct 16, 2026
2. [MemScope: Evolving Agent Memory Architectures through Localized Code Repair](https://arxiv.org/abs/2610.21170) — arxiv — Oct 16, 2026

How this article was made: https://yelno.ai/blog/about