Recursive Experiential–Working Memory Evolution for Long Horizon Agent Harnesses

Talon The interesting claim isn't that agents need more memory. It's that they need to stop treating a giant transcript like a task plan.

Wildflower Yeah. Recuris is aimed at the agent that has been working long enough for its own history to become interference. It separates Experiential Memory, which holds reusable skills, from Working Memory, which holds what is true and unfinished right now.

Talon Exactly.

Wildflower The working state tracks progress and unresolved goals. Then, at an execution event, that state chooses a relevant skill. After the action, a checker uses the environment response to update the state. So it is state, skill selection, execution feedback, updated state. The important part is that the dialogue does not get to declare itself successful.

Talon That is such a relief from the usual agent demo logic. Also, how's your week? Mine has been a parade of systems calling a transcript a database and hoping no one asks it what happened three steps ago.

Wildflower Mine has been similar, which is apparently how we are spending a Thursday. But this paper does name the actual break. The initial request becomes stale, while the history contains completed work, noise, and old assumptions. Retrieval against all of that is a bad control signal.

Talon Mm-hm.

Wildflower This lands directly in our old context-window versus memory fight. The longer-context camp says a large enough window handles most agent memory. The durable-state camp says context is working space, not a reliable control layer. Recuris is another entrant, and it is firmly on the durable-state side. I do not think that debate is settled, but this is a much more concrete argument than just saying, "agents need memory."

Talon And it has a clean product boundary, Wildflower. A support agent that completes one lookup does not need this. But an agent doing terminal work, tool-heavy dialogue, or repeated skill reuse over a long task? That team is already building a harness. This gives the harness a current-state ledger instead of making the model reread its diary.

Wildflower Right, right.

Talon The numbers are hard to ignore, too. They report improvements in thirty-five of thirty-seven completed model-benchmark pairs. On tau squared Retail, GPT-five point six Sol goes from fifty-eight point three to seventy-six point one. Claude Opus Five reaches eighty-seven point nine, and the gains widen to thirty-two point two points on the longest tasks.

Wildflower And they do more than attach a memory module and call it recursive self-improvement. Across tasks, a fixed Meta-Agent reads the structured trace and tries to locate the failure. Was the stored skill wrong? Was task state wrong? Did invocation choose poorly? Did progress verification fail? It proposes a local patch, then a held-out validation gate decides whether that patch enters Skill Memory.

Talon Okay, that's good.

Wildflower That bounded loop is the paper's real contribution. The underlying model stays fixed, and the outer update procedure stays fixed. What evolves is the external memory-control layer. That makes the word recursive much less mystical. It is not an agent redesigning its own brain at three in the morning. It is a harness changing a tested component after evidence says that component failed.

Talon Thank you for preventing the inevitable "self-improving agent awakens" headline. This is basically our old verification-loop obsession, just pointed at memory. A final failure signal only says the run went badly. Their trace tells the system where to inspect, which is a much more useful training signal.

Wildflower Sure.

Talon I can already see someone renaming Working Memory a "living workspace" and charging extra for it.

Wildflower And then it becomes one shared folder with a fake C E O title. We have learned nothing.

Talon Oh, come on.

Wildflower My genuine concern is not that the architecture is unsound. It is that the checker and validation set become load-bearing. If environment feedback is ambiguous, Working Memory can become confidently wrong. If held-out tasks are too close to the patching tasks, the gate can approve a patch that merely specializes to the benchmark. The paper reports two Meta-Agent implementations converging and shows transfer across tasks and models, which helps.

Talon Yeah, no, that is the price of making this shippable. A team needs observable task state, reliable checks, and enough repeated task volume to maintain a validation pool. If the only evaluator is the same model giving itself a thumbs-up, we are right back to fluent self-approval, wearing a nicer memory badge.

Wildflower No way.

Talon But for teams with those pieces, I think this is practical before it is universal. Think repository agents with tests, structured back-office workflows, or tool environments that return clear success states. They do not need an all-knowing model. They need a harness that notices which skill failed and does not wreck every working skill while fixing it.

Wildflower The component-specific patching is also a reasonable trade-off. Rewriting all memory from one failed trajectory is high variance and risks deleting abilities that were fine. A narrow patch, admitted only after validation, is slower and more operationally annoying. It is also the sort of boring constraint that keeps an improvement loop from becoming a degradation loop.

Talon I like that you are the one sold on the guardrails here. Almost a year into this show and your optimism arrives disguised as an admission-control policy.

Talon Let's leave the mystical recursion headlines in the bin, Wildflower. This one can sit next to the shared-folder joke and behave itself.