Recuris improves long-horizon agents by evolving memory, not weights

Recuris improves long-horizon agents by evolving memory, not weights

Recuris freezes the model and evolves a four-part Skill Memory, lifting long-horizon task success in 35 of 37 model–benchmark pairs and giving PMs a gated path to recursive improvement outside the weights.

A long-horizon agent can keep the same model weights and still get better at the job. Recuris shows how: freeze the LLM, evolve a four-part Skill Memory outside it, and only promote patches that clear a held-out validation gate.

Quick take

FieldPM read
TrendRecursive self-improvement is moving into the agent harness memory layer, not into another weight update. Working Memory tracks verified task state; Experiential Memory supplies reusable skills; a fixed Meta-Agent patches only the component a structured failure points to. 1
Fresh signalOn August 25, 2026, researchers at NUS, Stanford, Oxford, and Princeton posted Recuris (arXiv:2608.24876). Across four long-horizon benchmarks and ten models, it improved task success in 35 of 37 completed model–benchmark pairs. On τ²-Retail, Claude Opus 5 rose from 72.4% to 87.9% (+15.6) and GPT-5.6 Sol from 58.3% to 76.1% (+17.8). 12
Problem solvedGrowing chat histories bury unresolved goals and mis-time skill use. Outcome-only memory rewrites also cannot say whether the broken piece was the skill, the working state, the invocation policy, or the checker. 3
Evidence boundaryGains are measured under the paper's harness, benchmarks, and avg@4 protocol. No model weights change. Cross-task evolution is the main claim; test-time adaptation on Terminal-Bench 2.1 is a weaker, direction-only result at the reported sample size. 23
Action windowPilot one multi-step tool workflow with versioned skill cards, a verified goal board, structured traces, component-scoped patches, and a regression gate before any memory package reaches production traffic.

What changed

Long-horizon agent work already depends on a harness: memory, skill invocation, task-state tracking, tools, and verification around a base model. Recursive self-improvement still stalls there. Histories grow, unresolved goals disappear into the transcript, and agents invoke the wrong skill at the wrong moment. Experience piles up, while the memory mechanisms that organize and select that experience stay mostly fixed. 13
Recuris treats that memory-control layer as the product surface. Skill Memory is four components:
  • Experiential Memory (E) — reusable skills in an agent-skill format
  • Working-Memory spec (W) — schema and update rules for a compact goal board
  • Invocation policy (ρ) — when skills enter context and which ones
  • Checker set (C) — whether environment observations support a proposed state change
The base model stays frozen. Recursion happens only inside those four components. 3
Two loops do the work.
Within a task, Working Memory holds verified progress and unresolved goals. At defined execution events—for example a drafted state-changing tool call—the invocation policy pulls matching skills from Experiential Memory. After the agent acts, checkers commit only the state changes the observation supports. Skill use is grounded in current needs rather than the full chat history. 3
Across tasks, that coupling produces a structured trace: working state, selected skills, action, observation, proposed update, and checker decisions. A fixed Meta-Agent attributes each diagnosed failure to one component, patches only the implicated pieces, and submits the candidate to a validation gate. The gate admits the patch only when it repairs the source failure and does not regress a held-out development set that includes tasks the current memory already solves. Rejected candidates leave the memory unchanged. 3
Recuris within-task EM-WM coupling and cross-task Skill Memory evolution with validation gate
Official method overview: verified EM–WM coupling inside a task, then Meta-Agent localization, component patch, and held-out admission across tasks. Source: Recuris HTML paper.
The evaluation spans τ²-Retail (114 tasks), τ²-Airline (50), SkillFlow (166 tasks in 20 families), and Terminal-Bench 2.1, across ten models from a 3B open-weight agent to frontier systems. Task success is avg@4. Selected headline pairs: 23
ModelBenchmarkAgent alone+ RecurisΔ
Claude Opus 5τ²-Retail72.487.9+15.6†
GPT-5.6 Solτ²-Retail58.376.1+17.8†
Doubao-2.0-Proτ²-Retail58.181.4+23.3†
Qwen3.6-27BSkillFlow42.258.7+16.6†
Qwen3.6-35BSkillFlow35.348.8+13.5†
GPT-5.6 Solτ²-Airline79.086.0+7.0†
† marks a paired task-clustered bootstrap 95% CI that excludes zero on the official table. Claude Opus 5's 87.9% on τ²-Retail sits 9.7 points above the best model result in the evaluation without Recuris. 12
Recuris task-success gains, longer-horizon lift, and long-horizon failure-mode reductions
Official results panel: frontier and open-source lifts, larger gains on longer episodes, and failure-mode cuts rescaled against the agent-alone baseline. Source: Recuris GitHub.
Three product-facing details matter as much as the leaderboard:
  1. Horizon. The advantage grows with interaction length rather than decaying, reaching +32.2 points on the longest tasks in the stratified analysis. 13
  2. Diagnosis. Structured-trace localization hits 64.8% macro accuracy versus 13.0% from the task outcome alone and 37.0% from the raw trajectory. Scoped repair depends on that gap. 3
  3. Transfer. A Skill Memory evolved on Doubao-2.0-Pro can load unchanged into GPT-5.6 Sol and Claude Opus 5. The same package lifts those targets on τ²-Retail even though neither model took part in the evolution. 13
The paper also keeps the outer loop deliberately small. The base LLM, tools, Meta-Agent, localization and patching procedures, validation gate, and harness pieces outside Skill Memory stay fixed. Common long-horizon failures fall by up to 80% under that setup. Two pairs go the other way (including Gemini 3.7 Flash on τ²-Airline at −1.5), and several airline intervals include zero, so domain choice still matters. 23
Author Ling Yang posted the paper and code on the evening of August 25 Eastern Time; the post drew early research attention overnight. Co-author Yingcheng Charles Wu amplified the same claim: recursive improvement can live in external memory rather than weights. 45
Loading content card…
Loading content card…
No dedicated YouTube explainer for Recuris had surfaced at collection time. An earlier AI Engineer workshop from Anthropic staff on building agents that run for hours remains useful orientation on harness patterns: structured handoffs, evaluator contracts, and what to keep outside the model as models change. Treat it as background on long-running harnesses rather than coverage of this paper. 6
Loading content card…
Anthropic's November 2025 engineering note on long-running agent harnesses is the adjacent production precedent. It frames multi-session work as a discrete-session problem: each new window starts without prior memory, compaction alone is not enough, and durable artifacts—progress logs, feature lists, clean commits, end-to-end checks—carry state across sessions. Recuris answers a related product question with a different mechanism: versioned Skill Memory plus a regression gate, rather than only session files and feature checklists. 7

Why PMs should care

The deployment unit is model plus Skill Memory

If the product promise is "the agent gets better at this workflow over time," the shippable unit is not a new checkpoint. It is the frozen model plus a versioned Skill Memory package: skills, working-state schema, invocation rules, and checkers. Recuris shows that package can move across models without retraining. For a PM owning agent platforms, support automation, or internal tool agents, that changes the upgrade story. Keep the memory package in git, pin the model separately, and test transfer when the base model changes. 13

Working state is a product object, not a chat side effect

A transcript is a poor source of truth for what remains unfinished. Recuris makes the goal board explicit: pending, done, or blocked, with evidence attached, and only environment-backed checker decisions can mark progress. That is the same product instinct as Anthropic's feature-list and progress-file pattern, pushed into a machine-checkable state machine. PMs can instrument goal completion, blocked goals, false-pending checker errors, and skill-invocation timing as first-class metrics. 37

Outcome-only learning is a weak repair API

A binary success bit tells the system that something failed. It does not say whether to rewrite a skill card, fix the working-state schema, change when skills load, or tighten a checker. Structured traces raise localization accuracy from 13.0% to 64.8% in the paper's audit. That is the difference between a vague prompt rewrite and a patch with an owner. 3

Promotion needs a gate outside the improver

The Meta-Agent proposes. The gate decides. Held-out anchor tasks that the current memory already solves are the regression set. That is the product control that keeps recursive memory from becoming uncontrolled skill sprawl. Without it, every failed trajectory can mint a new skill that looks helpful on the source case and hurts the rest of the workflow. 3

Not every long-horizon setting is ready for cross-task evolution

On Terminal-Bench 2.1, cross-task evolution admitted no patch in 13 runs, so the authors evaluate a narrower test-time adaptation mode instead. Matched-budget adaptation adds only +2.3 points over retrying the same seed memory, with intervals that include zero at that sample size. The large jump from one attempt to four is mostly the attempt budget. Read that as a boundary condition for PM scoping: start where tool receipts and environment verifiers already produce structured evidence. 23

How to implement now

Treat recursive memory evolution as a gated Skill Memory product, not as open-ended self-modification of the agent.
  1. Pick one multi-step workflow with a hard verifier. Prefer a support, ops, or internal tool path with machine-checkable outcomes: database state, ticket status, or scripted acceptance tests. Freeze the "done" definition before any memory evolution starts.
  2. Version the four memory components. Store skill cards, working-state schema, invocation triggers, and checker predicates in git with owners and change review. Pin base model, tool schemas, Meta-Agent model, gate rules, seeds, and eval split IDs. Score model-plus-Skill-Memory together.
  3. Install verified working state in the live loop. Maintain a goal board with evidence. Mark a goal done only when a checker accepts an environment observation. Log blocked goals and rejected proposals instead of trusting the model's claim that a step finished.
  4. Invoke skills from state, not from the full transcript. Fire retrieval at defined events—turn boundaries or drafted write actions—and keep the retrieval key tied to the current goal or tool. Measure whether required writes happen after the skill enters context.
  5. Record structured traces for every failed run. Keep working state, selected skills, action, observation, proposed update, and checker decisions. Use those traces for localization. Do not train or patch from the final bit alone.
  6. Run a component-scoped Meta-Agent behind a regression gate. Allow patches only to the diagnosed component set. Admit a candidate only when it repairs the source failure and holds held-out anchors already solved by the current package. Reject and keep the prior package otherwise.
  7. Measure the product, not a single success rate. Track task success, success by horizon bucket, required-write recall, localization accuracy, patch admission rate, regression rate on anchors, skill churn, cost and latency per accepted task, and cross-model transfer when the base model changes.
  8. Promote on a ladder. Offline evolution → shadow scoring on held-out production-like tasks → limited internal traffic with the previous Skill Memory ready for instant rollback → broader rollout only after repeated seeds stay inside the reliability budget.
The PM hypothesis is narrow: a versioned Skill Memory with verified working state, structured failure localization, and a held-out admission gate can raise long-horizon task success on a frozen model without opening the weights. Recuris supplies the architecture and the measurement shape. This week, choose one offline workflow, write the four memory components and the gate before the Meta-Agent runs, and refuse to promote any package that never beat its own regression set.

This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.

Related content