Memory Transfer Learning

Memory transfer learning is the design pattern where agents reuse memories from heterogeneous prior task domains, not just the current benchmark or problem family, so that transferable operational knowledge can compound across different kinds of work.

Why this matters

Many memory systems for agents assume the useful unit of reuse is local similarity: the agent solved a similar task before, so retrieve that experience again. This paper contributes a stronger claim. In coding agents, different task domains often share enough infrastructure that memory from outside the immediate domain can still help.

That matters because real coding work is heterogeneous:

• repository-level software engineering
• function-level competitive programming
• ML or scientific code generation
• terminal-heavy debugging and environment work
• domain-specific code tasks with different benchmarks and conventions

Despite those differences, the same agent often interacts with:

• Linux-like shells
• programming languages and file systems
• dependency graphs and interfaces
• tests, validators, and execution environments
• failure patterns around tooling, APIs, and verification

The paper’s durable contribution is the argument that memory systems should exploit this shared substrate instead of trapping memory inside single-domain silos.

Core thesis

The strongest ideas in the paper are:

• cross-domain memory can improve coding-agent performance, not just same-domain memory
• the most transferable value is usually meta-knowledge, not task-specific code fragments
• abstraction level is the main determinant of transferability
• highly concrete traces can cause negative transfer when they drag task-specific detail into an unrelated problem
• memory pools can improve as they grow across more tasks and domains, if retrieval stays relevant
• memory transfer is not tied to one base model, and some gains persist across different models
• the most reusable memories often encode disciplined operating patterns such as inspect, edit, verify, and submit rather than narrow solution content

A useful synthesis is that good transfer memory teaches the agent how to work under coding constraints, not merely what answer worked once.

Framework / model

1. Cross-domain memory is different from ordinary self-evolution

Most self-evolving agents reuse experience from the same benchmark or task family. The paper argues that this is too narrow.

The better framing is:

• an agent accumulates memories from heterogeneous domains
• those memories are pooled into one retrieval space
• a new task can retrieve useful knowledge even when the source memory came from another benchmark
• the transferred value often comes from shared coding infrastructure rather than shared problem statement

This shifts the memory question from:

• "Have we solved this kind of task before?"

into:

• "What prior experiences contain reusable operational knowledge for this task shape?"

2. The paper compares four memory representations

A key contribution is the comparison of four memory formats with different abstraction levels.

Trajectory

A detailed action-observation trace from the full attempt.

• high detail
• high task specificity
• useful for local replay
• poor transfer when specificity becomes distraction

Workflow

A compressed action sequence focused on meaningful reusable steps.

• less noisy than raw trajectories
• preserves a reusable sequence of moves
• still partly task-shaped

Summary

A compact explanation of the task, environment, actions, and why the run succeeded or failed.

• more abstract than Workflow
• useful for retaining lessons and context
• better suited to reuse than raw trace storage alone

Insight

A deliberately generalized memory item with title, description, and task-agnostic content.

• highest abstraction
• most transfer-friendly in the paper’s results
• strongest format for cross-domain reuse

The durable lesson is that memory representation is not cosmetic formatting. It directly governs transfer quality.

3. Abstraction dictates transferability

This is the paper’s clearest design principle.

The result is not simply that more memory helps. It is that more abstract memory helps more reliably across domains.

High-abstraction memories transfer better because they preserve:

• strategy
• validation habits
• environment-handling rules
• interface discipline
• procedural guidance

They suppress:

• benchmark-local file names
• overly specific action orderings
• narrow code details that do not generalize
• noise from failed or irrelevant local exploration

This gives a useful architectural rule:

• use raw trajectories mainly for local inspection or diagnosis
• use distilled summaries and insights for cross-domain transfer

4. Transferable value is mostly meta-knowledge

The paper’s most important qualitative finding is that cross-domain benefit comes primarily from meta-knowledge.

Examples include:

• inspect the structure before editing
• verify aggressively after changes
• respect interface and API contracts
• prefer minimal patching over uncontrolled rewrites
• generate quick local tests when official tests are missing
• anticipate environment and toolchain failures early
• follow stable routines for search, edit, validation, and submission

This matters because it suggests memory systems for coding agents should prioritize reusable working methods over narrow code snippets.

A strong transferred memory often says something like:

• create a quick self-contained test first
• check file and interface assumptions explicitly
• make small edits and verify incrementally

rather than:

• copy this exact implementation detail

5. Negative transfer is a real memory failure mode

The paper gives a useful counterweight to optimistic memory narratives.

Low-level traces can hurt performance because they carry too much specificity:

• irrelevant files and commands
• benchmark-specific execution details
• brittle local heuristics
• misleading analogies to superficially similar tasks

This creates negative transfer, where memory retrieval injects noise or false confidence instead of help.

A durable lesson for memory design is that more recall is not always better. Memory has to be filtered by representation quality and abstraction level.

6. Heterogeneous memory pools can outperform narrower ones

The paper shows that a unified memory pool from multiple coding domains can outperform more siloed same-domain setups.

This matters because heterogeneous pools increase the chance of retrieving:

• environment-level know-how
• robust debugging habits
• reusable validation routines
• structural inspection patterns
• general coding discipline that transcends any one benchmark

The important subtlety is that the benefit comes from shared foundations across domains, not from pretending all tasks are interchangeable.

7. Transfer can work across different models

Another useful result is that memory transfer is not only a within-model trick.

The paper reports gains across multiple models, suggesting that some memories encode reusable externalized knowledge that is portable across model families.

That makes memory less like a hidden property of one model and more like a reusable layer in the wider agent system.

Important examples / reference points

• The paper evaluates across six coding benchmarks, spanning repository engineering, function-level coding, terminal-heavy work, and domain-specific code tasks.
• The average gain from cross-domain memory transfer is modest but meaningful, around 3.7% in the main setting, which is large enough to matter in already-competitive coding benchmarks.
• Insight memories perform best among the compared memory formats, reinforcing the value of abstraction.
• The paper’s case study where a transferred LiveCodeBench insight helps on SWE-Bench is especially valuable because it demonstrates procedural transfer rather than content copying.
• The comparison with ReasoningBank and AgentKB is useful because it suggests that memory quality and transfer design can beat both narrow in-domain memory and much larger but less targeted memory pools.

Failure modes / limitations

Treating all memory as equally reusable

Raw traces, workflows, summaries, and insights are not interchangeable. Their abstraction levels change what transfers.

Confusing code reuse with knowledge reuse

The strongest transferred value is often not reusable code content. It is reusable operating discipline.

Letting retrieval favor specificity over generality

Similarity search can over-select memories that look close lexically but carry the wrong level of detail.

Overvaluing same-domain memories by default

Same-domain memories can still be weaker than cross-domain memories if the latter capture better generalized procedure.

Ignoring negative transfer

A memory system that only measures retrieval success and not retrieval harm will overestimate its value.

Assuming bigger memory pools automatically solve the problem

Larger pools help only if the system can still retrieve relevant, appropriately abstract memories.

Practical implications

For coding-agent builders

• store memory in multiple representations rather than one flat format
• prefer distilled insight-style memories for cross-domain reuse
• treat validation routines, environment handling, and interface discipline as first-class memory content
• evaluate for negative transfer, not only positive recall
• consider heterogeneous memory pools instead of domain-isolated stores

For memory-system design

• separate local debugging trace storage from transfer-oriented memory
• explicitly measure the abstraction level of stored memories
• use retrieval that favors operationally relevant meta-knowledge, not only nearest-neighbor text similarity
• treat memory as a portable external system layer that may survive model swaps

For evaluation

• benchmark memory formats, not only memory presence versus absence
• test cross-domain transfer directly rather than assuming in-domain success generalizes
• inspect whether gains come from reusable procedure or benchmark-specific leakage

Tensions / open questions

• How should agents decide when to retrieve raw trajectory detail versus abstract insight?
• What is the best retrieval strategy for mixed memory pools containing highly different representation types?
• How should memory systems detect and suppress likely negative transfer before it harms the active run?
• Which kinds of coding tasks benefit most from cross-domain transfer, and which still need highly local memory?
• How should transfer-oriented memories be refreshed, merged, or retired as the agent and model stack improve?