Recursive self-improvement through collective intelligence

Compares two workspaces, chooses which better satisfies the task, and explains the judgment.

We use non-verifiable research tasks as training data. We use non-verifiable to mean that an automatic rule-based signal is not available and that only a self-evaluation signal (whose correctness is unknown) guides the overall learning loop.

To measure progress, we separately ask GPT-5.5 and Claude Opus 4.8 to assess the completed work. Their judgments are withheld from MASS. This gives us an outside measure of improvement in a process whose supervision comes from the model itself.

MASS uses workflow optimization to elicit collective intelligence, then distills the team's experience into the shared model. The inner loop optimizes the team's workflow while the model weights remain fixed. The model evaluates and judges for itself which workflow is optimal. The outer loop then updates those weights by learning from executions of the optimized workflow. The interactive diagram below follows both loops.

INNER LOOPevolving the team

round 1 · iteration 1 · champion: —

Multi-agent executor agents sharing one model

orchestrator 1 2 3 subagents

Self-evaluator judges the workspace

✓ new champion

Self-optimizer rewrites the workflow

Workflow v1

hop

1 2 3

role role role

instruction instruction instruction

contract contract contract

workspace

feedback

revised workflow, given to the team as its prompt

ℒ(0)

ℒ(0)

ℒ(0)

OUTER LOOPlearning from the team's work

= the same model in every role

Run champion ×18

Self-rank workspaces

Keep the best 16

Fine-tune, workflow removed

model capability

ℒ(0) base

ℒ(1)

ℒ(2)

instruction contract

← swipe to see the whole figure →

Pause Restart

Figure 2. MASS. Workflow search changes how the agents coordinate. Training on selected executions carries their experience into the shared weights. The updated model then resumes all three roles. This animation illustrates the procedure. Drag the progress bar to explore any part of the animation, including while paused. Hover over a component for details, or select it to jump to the explanation. Underlined terms in the text link to the diagram.

0. Setup: workflow as a prompt↑ in figure

A workflow is a written plan for how a multi-agent team should work together. The orchestrator assigns work to subagents and integrates their results. The plan is added to the task prompt, making the team's organization available for the model to inspect and revise. It has four components:

For example, an evolved finance workflow arranges data preparation, feature construction, modeling, and backtesting into a sequence, followed by an audit. Its data contract calls for explicit checks on the timing of the data:

Evolved finance workflow, condensed from the paper

Call order Data → Features → Modeling → Backtest → Audit → Reconciliation → Report

Data specialist's output contract validation_report: no_future_leakage: bool train_end_before_val_start: bool val_end_before_test_start: bool

A backtest can look convincing if it lets historical decisions use information from the future. This contract requires the data specialist to check for that error and report whether the time splits are valid. It also tells later agents what evidence they should receive before proceeding. Part of the research plan is thus expressed in what agents must establish and pass on to one another.

For each training task, MASS retains a champion: the best workflow found so far according to the current model's judgments. Each iteration has three steps:

The evaluator judges the completed work; the optimizer uses that judgment to revise the process that produced it. Optimizer's system prompt emphasizes contracts and hop, directing workflow search toward what information agents exchange and when they receive it.

Even with an optimized workflow, the quality of long-horizon research work can vary from run to run. MASS therefore executes self-judged optimal workflows (or champion workflows, meaning the optimal workflows found so far) with multiple random seeds and uses the current model to rank the resulting workspaces, retaining the highest-ranked trajectories. Each trajectory records the messages, tool calls, and tool results of the orchestrator and its subagents.

Removing the workflow from the orchestrator's training prompt encourages the model to learn how to organize the work from the task itself.

We run two complete rounds of MASS starting from Qwen3.6-27B in the qwen-code coding-agent environment. Our synthetic research suite contains 12 tasks in finance, robotics, and pharmacy, each requiring code, quantitative results, and a research report. Nine tasks are designated for training and three, one per domain, are held out from post-training. Eight ultimately supply training dataOne training task is excluded because workflow search finds no workflow that beats its reference. The task descriptions were generated by GPT-5.5 before the experiment. Within MASS, the current Qwen model supplies workflow feedback and training-data selection. The three test tasks are excluded from fine-tuning, validation, and checkpoint selection, although workflow search is also evaluated on them..

We compare three generations: the base model (\mathcal{L}^{(0)}), the first-round model (\mathcal{L}^{(1)}), and the second-round model (\mathcal{L}^{(2)}). We examine the quality of their work, their ability to organize and judge it, and their use of coordination without a supplied workflow.

On the three synthetic test tasks, the win rate against the base rises from 53.9% after one round to 69.9% after two rounds (Table 1). The second-round model also wins 60.8% of comparisons against the first-round model.

To test transfer beyond the synthetic research suite, we evaluate public benchmarks. After two rounds, score per output token reaches 1.2–1.6× the base model's level across MLR-Bench, DSBench, ScienceAgentBench, and AstaBench (Figure 3).

Specifically, the task scores themselves improve on MLR-Bench, from 1.58 to 2.40, and on ScienceAgentBench, from about 29% to 32% success. On MLR-Bench, the model delivers a paper in 50 of 60 runs after two rounds, up from 31 of 60 for the baseThe MLR-Bench experiment uses a 12-task subset with five trials. Mean scores among delivered papers are 3.07 for the base model and 2.88 after two rounds, but these means cover different completed-task sets. Statistical conclusions depend on whether results are aggregated across trials or across tasks. ScienceAgentBench uses 102 tasks and three trials..

The gains are strongest on four research benchmarks resembling the training tasks. Score per output token is 0.96× the base value on Terminal-Bench 2.0 and 0.94× on SWE-bench Verified, showing that transfer remains uneven. We suspect this generalization can be easily addressed by introducing software engineering tasks into the training data.

We observe that MASS enables role generalization in RSI. We train the model only on task-solving trajectories and observe that the capabilities of the workflow optimizer and workspace evaluator also improve. This enables RSI loop to be sustainable.

Figure 4 shows optimizer can find successful workflows sooner as cycle goes by.

In fact, Figure 4 is technically not a very fair comparison, since ( L^{(0)}) denotes a setting in which the base model (optimizer) updates the base model (optimizee), and ( L^{(1)}) denotes a setting in which the first-round model (optimizer) updates the first-round model (optimizee). For a fair comparison, we give the first-round model's workflows to the base model (Table 2). We observe that the base model with first-round search workflows wins 64% of comparisons against the base model with base-search workflow. Each set of workflows was discovered using its generation's executor, evaluator, and optimizer. The transfer test holds execution weights fixed during evaluation. It does not isolate the optimizer from the other roles during search. Table 2 clearly shows that optimizer's capabilty have increased.

The evalutor also move closer to those of the strong external model judges (more details in paper). Agreement with those external judges rises from 73% to 93% across the three cycles. Overall, these results suggest that task-solving examples can also improve capabilities used to produce and select the next round's training data.

We also inspect how the model works when it receives only the task prompt and usual tools. Across 110 synthetic-task runs per generation, delegation rises from 1 run for the base model to 48 after one round and 87 after two. Here, delegation means a subagent call that returns without a tool error. Code handoffs, where one subagent reads a Python file written by another, rise from 1 to 42 to 83 runs.

These behaviors are present in the training conversations and become more common under a plain task prompt. With the tools held fixed, the change is in how readily the model uses coordination. Transfer can also appear in executions with no delegation: none of the MLR-Bench runs calls a subagent. Learning from a team can thus benefit work the model carries out on its own.

What really makes an optimal multi-agent workflow effective?

We analyze the roles, instructions, contracts, and hops of the champion workflows (the best workflows found so far). For each component, we estimate how much its text reveals about the task. In the finance example above, a role such as “careful data scientist” could apply to many tasks. A contract specifying leakage checks for a trading backtest is much more distinctiveWe estimate mutual information between embeddings of workflow components and task descriptions, using text-embedding-3-large and all-mpnet-base-v2 with unadjusted and permutation-adjusted estimators. These statistics describe workflow text, rather than messages exchanged during execution. The samples cover only 8–9 tasks; agents within a workflow are not independent task replications..

Figure 5 shows that between the first and final iterations of workflow optimization, an optimal multi-agent workflow tends to encode task information more strongly in contracts and hops and less in roles and instructions. We do not show this here, but mutual dependencies among the components generally decrease too (interesting!). This pattern suggests that the LLM optimizer evolves the workflow components to be mutually independent but optimizes the information flow via contracts and hops (see this blog post for deep, intuitive explanations). I would say that workflow optimization over discrete components resembles discovering a basis vector for that harness space.

The optimizer is instructed by its system prompt to emphasize contracts and hop, so the pattern also reflects how search is directed.

We observe that trajectories from multi-agent systems can be more effective than trajectories from single agents in RSI. Multi-agent execution also changes the structure of the training data. The orchestrator's conversation shows how to divide a broad task into focused assignments and coordinate their execution. A subagent's conversation shows how to carry out an individual assignment. Specifically, we observe that jointly learning coordination from the orchestrator and bounded execution from subagents provides more effective supervision per training token than learning from long single-agent trajectories (Figure 6).

We compare students trained independently from the same base model on single-agent trajectories (S, S+, S++), multi-agent trajectories (M, M+), and a mixture (X). A plus sign denotes a larger training set; M+ is the first-round MASS model. All points below report results pooled across four tr