Recuris and the Case for Memory That Rewrites Itself

TL;DR: A paper called Recuris argues that the fix for agents that fall apart on long tasks is not a bigger context window but a split memory system where working memory tracks the current task state and a meta-agent quietly patches the skill library when things break.

The paper is “Recursive Experiential-Working Memory Evolution for Long-Horizon Agent Harnesses,” posted to arXiv under both cs.AI and cs.CL, with code at github.com/Gen-Verse/Recuris. I have not run the code, so treat the numbers below as the authors’ reported results, not independently verified ones. But the framing is worth taking seriously, because it targets the failure mode every agent builder has hit: the agent that does fine for ten steps and then loses the plot.

Why do agents fall apart on long tasks?

The stated problem is simple and familiar. On long-horizon tasks, the history grows, and the growing history obscures the task state. The agent has more tokens to look at and less clarity about what it is actually trying to do right now. Skill invocation drifts. It calls the wrong tool at the wrong moment because the signal of “what do I need next” is buried under a transcript of everything that already happened.

Most people reach for the obvious lever here: more context, better retrieval, a summarization pass. Recuris takes a different swing. Instead of treating memory as one undifferentiated blob, it splits it. Working Memory holds the current task progress and drives skill selection. Experiential Memory is the accumulated store of skills and past evidence. The claim is that grounding skill choice in current needs, rather than the full history, is what keeps the agent pointed in the right direction as the task runs long.

This is a distinction that matters in practice. If you have built anything agentic, you know the difference between “here is everything that happened” and “here is where we are.” The first is what most harnesses give the model. The second is what a competent human keeps in their head. Recuris is an attempt to encode that second thing as a first-class component.

What is the recursive part actually doing?

Here is where it gets more interesting than yet another memory-retrieval scheme. The paper’s real move is the loop.

Because Working Memory and skill selection are coupled, execution stops being an opaque stream and becomes what the authors call structured evidence. When something fails, the failure can be localized to a specific memory component: was it a bad skill, a wrong selection, a stale piece of experience. A fixed Meta-Agent reads that evidence and makes localized, validation-gated updates to Skill Memory. Those updates reshape how the agent executes, which produces new evidence, which feeds the next update.

Two words in there are doing heavy lifting, and both are good signs. “Localized” means the meta-agent is not rewriting the whole system on every failure, it is patching the specific piece that broke. “Validation-gated” means updates have to pass a check before they stick. That is the guardrail that separates recursive self-improvement from recursive self-destruction, which is the usual outcome when you let a model edit its own instructions freely. Anyone who has watched an agent “improve” its prompt into gibberish over a few iterations knows why gating matters.

The authors call this a bounded recursive memory-evolution loop. Bounded is the operative claim. RSI has a long history of sounding thrilling in the abstract and diverging in practice. A loop that can only make small, checked edits to a skill library is a much more plausible version of the idea than “agent rewrites itself.”

How strong are the numbers?

The reported results are broad, which is the first thing that makes them credible. Recuris was tested across four long-horizon benchmarks and ten models, and it improved task success in 35 of 37 completed model-benchmark pairs. That is not a cherry-picked win on one model and one eval. When something helps almost everywhere across a wide sweep, it is more likely to be a real structural gain than a tuning artifact.

The headline figures: on tau-bench, +17.8 points to GPT-5.6 Sol and +15.6 to Claude Opus 5, taking Opus 5 to 87.9%. On SkillFlow, +16.6 and +13.5 points to Qwen3.6-27B and 35B. And the pattern I find most telling: the advantage widens as the interaction horizon grows, reaching +32.2 points on the longest tasks, with common long-horizon failures falling by up to 80%.

That widening gap is the tell. If the gains were flat across task lengths, you would suspect a general prompting boost that has nothing to do with the memory architecture. Instead the benefit scales with exactly the thing the architecture is designed to fix. Short tasks barely need it; long tasks need it most. That internal consistency is more convincing to me than any single benchmark number.

The caveats. These are the authors’ own numbers, self-reported, and model names like “GPT-5.6 Sol” and “Claude Opus 5” mean the harness was run against a specific frontier lineup that will keep moving. Benchmark success on tau-bench and SkillFlow does not automatically translate to your messy production task with real tools and real users. And “up to 80%” is a ceiling, not an average, so read it as the best case rather than the expected case. The code being public is the thing that makes verification possible, which is more than a lot of agent papers offer.

What should a builder take from this?

The reusable idea here does not require adopting the full Recuris stack. It is the separation.

If you are building agents today, the cheapest thing to steal from this paper is the split between “what is my current state and next need” and “what is the full record of what happened.” Most harnesses collapse those. Give your agent an explicit, compact working-state object that gets updated each step and drives tool selection, and keep the long transcript as a searchable store you dip into rather than the thing you feed wholesale into every call. That alone tends to help before you touch anything recursive.

The second idea, the self-patching skill library, is higher risk and higher reward. If you try it, do not skip the validation gate. The failure mode is an agent that edits its own skills into a corner and gets confidently worse. Log every proposed update, gate it behind an eval that has to pass, and keep the ability to roll back to a known-good skill set. The catch most readers will miss is that recursive self-improvement only stays safe because of the boring plumbing around it, the localization and the gating, not because of the loop itself. The loop is the exciting part. The gate is the part that makes it usable.