Skip to content

Agent Memory Is Turning Into a Systems Problem: Five Papers on Skills, Consolidation, and Time

#llm-agents #agent-memory #skill-selection #self-improvement #temporal-retrieval #experience-consolidation

Agent Memory Is Turning Into a Systems Problem: Five Papers on Skills, Consolidation, and Time ​

Most agent stacks I audit have the same hole. The agent finishes a task, writes a summary, and by tomorrow that summary is a 4,000-token blob pasted into a system prompt nobody reads. Retrieval helps a little. Then the same domain comes around again and the agent repeats the three mistakes it made last week, because nothing in the stack turned those mistakes into anything reusable.

A batch of five preprints landed on the same problem from different angles. GLOBE treats memory as a field-scoped handbook of behaviors. Darwin-Claw distills episodes into prototype vectors instead of replaying them. TIDER moves temporal constraints into the retrieval stage where candidates actually get selected. SkillBrowser makes skill loading itself a skill. CDSE splits each skill into four functional pieces. And LM2LM trains a model to propose improvements to other models using a frozen LLM as a stand-in for a lab.

PaperUnit of memoryWhat evolvesHeadline result
GLOBEField-scoped behavior entriesBehavior text, scoped per listing fieldStructured behaviors beat monolithic prompt optimization
Darwin-ClawPrototype vectors plus skill patchesOperational skills and durable memorySubstantial gains on WildClawBench
TIDERTemporal window plus evidence setRetrieval policy, not the generator61.52% LifeBench, 78.96% LoCoMo
SkillBrowserSkill loaded on demandQuery formulation via meta-skillBeats static retrieval and LLM selection on six SRA-Bench subsets
CDSEFour-part skill (Meta, Experience, Tool, Script)Component-specific updatesBest score in all 36 settings
LM2LMProposal policyImprovement proposals for LMsQwen3.8-27B beats GPT-6-sol at 33% lower data-generation cost

The table is the whole argument in miniature. Six systems, six different answers to "what exactly is the thing you're storing," and every one of them beats a baseline that stores raw text.

GLOBE: behaviors beat one big prompt ​

GLOBE works on e-commerce listings optimized for generative search. An Editor agent applies stored behaviors to a listing, the listing gets ranked, and a Reflector turns that rank feedback into behavior updates. The interesting design choice is that behaviors are field-scoped. A behavior attaches to the title, or the bullet points, or the description, not to "the listing."

That scoping does work that's easy to miss. It gives you a natural place to assign credit. When the title rewrite moves rank and the description rewrite doesn't, the Reflector can update one entry instead of rewriting a giant prompt and hoping.

Two more pieces matter for anyone running this in production. A Moderator removes redundant proposals before the Curator commits them, so the handbook doesn't fill with near-duplicates. Harmful behaviors get deactivated rather than deleted, which keeps the audit trail. Most memory systems I've seen can only append. An agent with append-only memory drifts, and you find out six weeks later when someone reads the prompt.

The transfer result is the one to watch. Behaviors learned on some product categories stayed effective on unseen ones. That is the difference between memorizing a catalog and learning a craft.

Darwin-Claw: consolidate, don't dump ​

Darwin-Claw opens with a complaint I've heard from every team that tried to build self-improving agents. Injecting raw interaction trajectories into memory or skill modules obscures behavioral patterns and makes updates hard to control. You end up with a pile of transcripts and no way to say which part of the pile changed your agent's behavior.

The framework distills each episode into fine-grained error attributions, then generalizes those into dynamically updated prototype vectors. Those vectors do two jobs. They act as interaction patches that shape context-sensitive perception, and they act as explicit optimization signals for skill refinement. An actor and an evolver-critic co-adapt across iterations, so the critic's job is to improve the actor's operating skill, not to grade answers.

The claim about where the bottleneck sits is the part worth quoting at your next planning meeting: as base model reasoning improves, the limiting factor shifts from accumulating generic knowledge to managing situational experience. You can't out-scale that with a bigger context window. A 1M-token window full of undifferentiated transcripts is still undifferentiated.

Darwin-Claw also runs without manual curation, which matters more than benchmark numbers. Any memory scheme that needs a human to tag episodes will not survive contact with a real product.

TIDER: the retrieval stage is where time gets lost ​

If you've built a memory store for a long-running agent, you've hit this. The user asks what happened with the vendor contract. The retriever returns five chunks about vendor contracts, all from the wrong quarter, all semantically excellent. The right chunk exists. It got crowded out.

TIDER's diagnosis is precise: existing approaches inject temporal cues during memory organization or answer generation, but not during retrieval, which is where candidate selection happens. That's the root cause of displacement, and it's a design flaw you can fix without touching your generator.

The mechanism is an RL-trained temporal interval locator. It infers the window in which the answer probably lives, then that window defines a second retrieval channel alongside the semantic one. Candidates from both channels get merged and reranked by proximity to the window. The RL part is doing something unusual: window localization is a discrete, non-differentiable decision, so they optimize it directly with composite rewards that convert sparse answer supervision into fine-grained retrieval feedback.

The numbers: 61.52% on LifeBench, up 8.82 points, and 78.96% on LoCoMo, up 3.66. Those gains come from a 1.7B parameter locator. That size means the locator runs on the same GPU as a mid-size agent model, so the cost is one extra forward pass per query rather than a second frontier model in your retrieval path.

Key numbers from the five papers

  • LifeBench 61.52% and LoCoMo 78.96% for TIDER, up 8.82 and 3.66 points.
  • 1.7B parameters in the temporal locator, small enough to co-locate with the main agent.
  • 96.8% of 500 top-ranked skill packages carry knowledge across at least two functional roles.
  • CDSE takes first place in all 36 benchmark, model, and harness combinations.
  • 33% lower data-generation cost for LM2LM against the comparison baseline.

SkillBrowser: showing less is a skill ​

Skill libraries have an exposure problem. Progressive disclosure dumps metadata for the whole library into context and calls it discovery. That's context pollution with extra steps. Static retrieval limits what you show, but it fixes the query at the start of the task, and the capabilities you need at step seven are usually not the ones you predicted at step one.

SkillBrowser turns exposure into a meta-skill. The agent identifies its current capability need, formulates a targeted query, and loads the skill on demand. Across six SRA-Bench subsets and five LLMs, that beats static retrieval and LLM-based selection, including on multi-step tool use. It also reduces accuracy loss on instances the base agent could already solve, which is the quiet win. Every skill you shove into context costs you something on tasks that never needed it.

ApproachWhat the model sees up frontWhen the query formsDominant failure
Progressive disclosureMetadata for the entire libraryNever, it just growsContext pollution
Static retrievalTop-k skills from the first queryTask startMisaligned with needs found mid-task
LLM-based selectionCatalog summary, then picksTask startSame misalignment plus selection cost
Meta-skill browsingNothing until a need appearsMid-reasoningUnder-invocation and extra round trips

The authors are honest about the limits, and the honesty is useful. Benefits vary by model and task. The two named failure modes are under-invocation and added latency. Under-invocation is the bigger hazard for production systems: a skill the agent never loads costs you accuracy silently, while a skill it loads unnecessarily costs tokens you can measure on a dashboard.

Quick Take: The real split across these papers is between storing experiences and storing the rules those experiences imply, and the second approach is winning on every benchmark reported here.

CDSE: a skill is four things, not one ​

CDSE starts from an observation about existing skill-evolution work: it organizes knowledge around whole skill artifacts and ignores functional heterogeneity inside a single skill. The authors analyzed 500 top-ranked skill packages and found that 96.8% contain knowledge spanning at least two functional roles.

So they split the skill. Meta holds when and why to use it. Experience holds evidence from prior runs. Tool holds the executable interfaces. Script holds the procedure. Updates become component-specific, with validation and cross-component coordination, plus adaptive invocation at use time.

Winning all 36 settings is the kind of result that usually means the baseline was weak. Here the strongest competing method in each setting is the comparison, and CDSE still clears it by 2.6 points on average, 7.6 over the base agent. The ablation studies point at functional differentiation and adaptive invocation as the sources of the gain, which fits the design story.

If your skills are single undifferentiated markdown files, this paper explains why maintenance hurts. You cannot fix the Script without risking the Meta, so nobody fixes either one.

LM2LM: learning to propose improvements ​

LM2LM is the odd one out because the thing being improved is the model, not the agent. The framing is recursive self-improvement, and the cost math is the reason it's hard. Training a proposal policy with real feedback means evaluating tens of thousands of proposals, each potentially a full training run. At ten GPU-hours per run, reward collection alone eats hundreds of thousands of GPU-hours.

Their fix is a research world model: a frozen LLM that predicts a proposal's gain from measured experimental records placed in its context. That prediction becomes the RL reward. The obvious failure mode is reward hacking, where the policy drifts toward proposals the world model overestimates. They handle it by periodically executing the current policy's top-ranked proposals for real and appending the measured outcomes to the world model's context, which re-anchors the surrogate to reality on a schedule.

Across eight autoregressive and diffusion LM development environments, Qwen3.8-27B with LM2LM beat GPT-6-sol on held-out tasks, even when GPT-6-sol got 300 measured experimental records in context, at 33% lower data-generation cost. It also generalized to a model family never seen during training.

That 33% is the number to carry into a planning doc. The expensive part of self-improvement research is running experiments, so a surrogate that cuts a third of them while staying calibrated changes what a small team can afford to try.

What the community is saying ​

I wired a cut-down version of this loop into an internal support agent back in the spring, and the failure modes lined up with what people keep filing issues about.

The first was memory bloat. Our store grew roughly 4,000 entries in six weeks, and retrieval quality fell as it grew. We had no removal path. GLOBE's Moderator and deactivation step would have caught it.

The second was temporal drift. Users asked about "the migration" and got the wrong migration, because nothing filtered by date. A cheap window filter fixed most of it, which is the same instinct TIDER formalizes with a learned locator instead of a heuristic.

The third was skill under-invocation. We had 40-plus skill files and the agent loaded maybe eight of them with any regularity. Teams on GitHub report the same thing: the library grows, the load rate doesn't. Browsing on demand sounds inefficient until you measure the token bill for the alternative.

The fourth, and the one that hurt most, was poisoned memory. A single bad episode got summarized into a confident-sounding rule, and it took a week of confused debugging to trace it back. Anyone who has shipped one of these knows the feeling.

What trips people up ​

Storing raw trajectories and calling it memory. You get a searchable transcript pile. Darwin-Claw's whole argument is that the pile obscures the pattern, and the pattern is the thing you wanted.

Shipping append-only memory. If your system has no deactivation, no merge step, and no expiry, it will drift toward confident nonsense. Budget for the removal path before you budget for the write path.

Letting semantic similarity be the only retrieval signal. Semantic search is very good at returning the wrong-quarter document with a high score. Add a time window, even a crude one, and measure the change.

Front-loading skill metadata. Every token of catalog you inject competes with the task. SkillBrowser's gains on already-solvable instances come from not spending that budget.

Writing skills as one flat file. 96.8% of popular skill packages mix at least two functional roles. If you cannot update the procedure without touching the applicability notes, updates will stop happening.

References ​

One thing to remember ​

Every one of these papers spends more engineering on the write side than on the read side. The moderator, the curator, the deactivation flag, the prototype distillation, the component validation, the periodic execution refresh. Those steps don't show up in a demo, and they're the difference between a memory that compounds and one that quietly rots.

What this means in practice ​

If you're building a long-horizon assistant over user history, fix retrieval before you touch the generation prompt. TIDER's 8.82-point LifeBench gain came from a 1.7B locator, which is a cheaper swap than upgrading your base model and doesn't require re-embedding your store.

If your skill library is past 50 entries, stop injecting metadata up front and give the agent a browsing meta-skill instead. Expect under-invocation for the first two weeks, then instrument skill-load rate per task type and tune the meta-skill's prompt rather than pruning the library.

If you're experimenting with agents that improve agents, put your budget into the reward model. LM2LM got a third of its data-generation cost back by using a frozen LLM as a world model, but the part that kept it honest was periodically running real experiments to refresh the surrogate. Plan for those runs, because a surrogate you never check will drift toward whatever your policy finds easy to propose.