RSI That Builds RSI 🔁

TL;DR — Research has always delivered answers: an algorithm, an architecture, a paper. Next, it will deliver systems: give it a domain, a task and a dataset, and it hands back something that keeps improving after you ship it. Getting there takes two loops running at once: one inside each project that improves the agent doing the work, and one above all your projects that improves whatever sets those loops up. The question is not whether agents can improve themselves. The question is who improves the improver.

The things we can build now don’t have to stop.

The signal: what research delivers is changing

Over the past few weeks the signals have come from research labs and from products at the same time.

Machines are building models. In late October, Recursive released Flint, a 40B mixture-of-experts coding model with 2.5B active parameters, under Apache 2.0. According to the company, its Eureka Machine, an automated research system that proposes ideas, implements them and tests whether they work, “helped develop nearly every part of Flint’s model-building stack.” Starting from a 35B baseline, it explored expert configurations and widths, and, against common practice, quantized the output layer to 4 bits, then used distillation to recover the lost accuracy. A small team worked alongside it, the numbers are self-reported, and there is no technical paper yet. Still, the shape of the claim is new: what gets built is a machine that does research, and the model is its output.

Companies are being founded on this idea. Apex Intelligence, started in Beijing in June by Yongchao Chen of Tsinghua’s Institute for AI, raised close to $50M to build self-evolving foundation models for scientific discovery. Its stated targets are chip design, molecular research and quantitative strategy.

Inference is becoming infrastructure. DeepSeek open-sourced DeepInfer, the inference framework behind its production services (offline inference only, for now). It could become for agents what vLLM and SGLang were for chatbots. The layer underneath is turning into a public utility, so the interesting work moves up, to how we use it.

Products are moving from chats to projects. Claude Code’s new Projects is one ongoing conversation. Claude starts parallel sessions called threads, gives each one the project’s instructions, and shows you which ones need you, for when “you’d rather describe it once than dispatch and track each session.” The same week, Anthropic previewed Claude Duet, which reverses the direction of the conversation: it sends a morning briefing, and during the day it messages you only when it needs you, asking before it acts on your behalf.

And the architecture is converging. This week, DeepSeek Harness described a Super-agent: one long-lived Router session that takes every human interaction and keeps the global context, above isolated Worker sessions that each run one task. They start from human attention: a person can usually follow only three to five sessions at once. I see the same shape, and ask a different question. They make many sessions feel like one agent. I want the agent above them to get better at running them.

Put these together and a pattern shows up. One conversation manages many. The agent comes to you. Underneath, the work itself is a loop that improves.

Research hasn’t absorbed that last part yet.

A morning with a Super Session

Here is the experience I am building toward in EvoScientist², the next version of EvoScientist, the open-source, self-evolving AI scientist I started.

You don’t open five threads. You open one conversation: your Super Session. It has been running your projects overnight, and it speaks first:

Good morning. Two things.

A paper posted last night re-evaluates the benchmark behind project 1 on a cleaner split. I can rerun our last three versions against it. Want me to?

And something I didn’t expect: in project 2, a short retrieval step before planning fixed most of the failures. Project 3 fails in the same way. I’d like to replan project 3 around that and start its next run from project 2’s recipe. Here’s the plan. Approve?

The first item is useful. The second is one that no single-project tool can send. A thread only sees itself, and the link between project 2 and project 3 is only visible from above.

That is the first reason to have a Super Session. The second is that it can improve how all those loops are run.

Inside a thread: the inner loop

Every project the Super Session runs is a self-improving loop. I call the concrete design EvoMachine.

You give EvoScientist a task and its data: a Q&A set, a Terminal-Bench suite, a research benchmark like ASI-Bench. It splits off a dev set, decides the evaluation criteria and sets up the code. Then it hands the criteria and the dev set to a Conductor.

The Conductor sets its own goal: make the Target Agent better. The Target starts as the simplest thing that can work, a ReAct agent. The Conductor sends it a recipe (the system prompt, the tools, the sub-agents), and the Target runs a batch: sixteen tasks at once, or one task sixteen times, whichever the Conductor expects to learn more from.

Two things come back. A Judge scores the outputs on dev (a score, an F1, written comments) and reports only to the Conductor. The Target’s own run log, every AI message, tool message and output, goes to the Conductor as well. From both, the Conductor writes the next recipe. v1, v2, v3: each version can change the prompt, the tools and the sub-agents.

Every few versions there is a bigger step. The Conductor turns the runs so far into training data, and a Trainer sends back two things. One is a LoRA adapter for the Target’s model: its slow, deliberate System 2. The other is a small model in the style of Jev, which returns choices and scores instead of text. Mine picks tools and plugs in as middleware: a fast System 1. Both go into the next recipe. Small iterations improve the agent; big iterations improve the model. The harness and the weights evolve together.

Two details matter:

• One model or two. If every role runs on the same model, I call it Self-RSI², after recursive self-improvement (RSI). Add a stronger teacher and it becomes Distill-RSI². Each role can sit on its own GPU or behind an API.
• A held-out split keeps it honest. When you search and score on the same data, “we tried more times” starts to look like “we learned something.” One recent re-evaluation found that on Terminal-Bench 2.1 an evolved harness did no better than simple test-time scaling at a matched budget, and on held-out tasks it did no better than the harness it started from. So the Conductor iterates on dev, and a version only counts as progress if it holds up on a held-out split the Conductor never sees.

The whole thread can be copied, too. The Super Session runs many of them at once, one per project.

Above all threads: the outer loop

If you stop here, you have a good harness-evolution system, and there are several of those already. Even in Self-RSI², where one model fills every role, what gets better is the Target: its recipe and its adapter. The Conductor’s way of improving it stays the same. That is not yet RSI in the strong sense, because whatever does the improving never changes.

The outer loop is where it changes.

The Super Session talks to you, and every exchange is a signal: which updates you cared about and which you ignored, which proposals you approved, which you corrected and why, and, weeks later, whether the replanned project actually got better. Its judge is you.

What it learns is not how to answer one task. It learns how to run loops:

• which new results are worth your attention, and for which project;
• which recipe from one project makes a good starting point for another;
• how to set up a new loop: what to hold out, what to measure, when a Conductor should stop.

The inner loop improves the agent doing the work. The outer loop improves the system that builds those agents, so that every new project can start higher than the one before it. That is what I mean by RSI that builds RSI: the outer RSI pushes the inner one.

There is a reason the outer judge should be a person. The first two of my Three Laws of Self-Evolving AI Agents are Endure (stay safe while you change) and Excel (don’t get worse at what already works). An inner loop with an automatic judge can satisfy its metric and drift away from what you meant; an outer loop judged by the researcher pulls it back. It is the lesson of Harness Vibe Research again: the multiplier is the coupling between human and agent, not autonomy on its own.

Who improves the improver?

“RSI” is in a lot of paper titles this autumn. Read the method sections, though, and most of them keep the improver fixed. A model edits a harness, or a harness generates data that trains a model, but whatever proposes the edits stays the same. That is real progress. It is not yet a loop that compounds.

A few papers have started to measure the part that matters. Weco AI’s AIDE² ran an “ignition test”: put the evolved agent in the improver’s seat: does it push the loop further than the agent that drove the run? The score was 0.780 against 0.782, three seeds each, which the authors call inconclusive. Sakana’s MASS has one model play agent, optimizer and judge, distills the team’s trajectories back into the shared weights, and reports that after two rounds the optimizer and the judge improved along with the agent. It also names the obvious risk, shared blind spots: the same weakness can compromise both the behavior and the thing that should catch it. And a group of economists led by researchers at METR sets a sharper bar: fully automating R&D need not, by itself, make progress accelerate; that depends on how fast returns diminish.

My bet is that the improver doesn’t have to improve inside the inner loop. It can improve in the outer one, where the signal comes from a person whose blind spots are not the agent’s. That is measurable, too: does a new project’s loop start higher and converge faster because the Super Session ran the projects before it? That is the ignition test for the outer loop, and it is the first experiment I will run.

Beyond science

None of this is specific to science. The inner loop needs a task, data and a way to judge the result. Swap the research benchmark for a trading strategy, the dev set for a backtest window, the held-out split for out-of-sample months, and the Judge for risk-adjusted return. Or swap it for chip design, with a set of circuits as the dev set and a simulator’s timing and power numbers as the Judge. The Conductor still writes recipes, the Trainer still trains, and the Super Session still tells you when something found in one project fits another.

For anyone working on many things at once, the Super Session is also a knowledge system: one place that remembers what every project learned and carries it to where it is needed, before you ask.

The layer above inference

I am not building the inference engine. DeepInfer and its peers will make running models cheap and boring, as they should. I am building the layer above them: the one that lets anyone use those models at high throughput, in many loops at once, and turns all that use into a system that keeps getting better at your problem.

Parts of it already ship in EvoScientist: memory that carries across sessions, AutoSkills that turn recurring patterns into reusable skills, scheduled tasks that run on their own and report back, and, as of v0.4.0, one background service for every project. EvoScientist² will put them under one conversation.

Research has delivered receipts for a long time. The next thing it delivers should be a system you keep: one that gets better every time you use it, and better at getting better.

Citation

If you found this useful, please cite it as:

Zhang, X. "RSI That Builds RSI" (November 2026). https://xizhang.ai/blog/rsi-builds-rsi/

Or use the BibTeX citation:

@article{zhang2026rsibuildsrsi,
  title = {RSI That Builds RSI},
  author = {Xi Zhang},
  year = {2026},
  month = {November},
  journal = {xizhang.ai},
  url = {https://xizhang.ai/blog/rsi-builds-rsi/}
}