Sakana AI MASS: A 27B Model That Trains Itself Through Agent Teams

Sakana AI and UC Berkeley published MASS, short for Multi-Agent Self-Supervision, a recursive self-improvement (RSI) recipe in which a single open-weight 27B model solves tasks by managing a team of subagents, searches for better team workflows, judges them with its own judgment, and is then fine-tuned on the winning runs. After two rounds, the paper reports a score per output token of about 1.2x to 1.6x the base model on four research benchmarks. The code is public on GitHub, and the write-up is unusually frank about where the loop breaks. Here is what it does, what the numbers do and do not show, and why the safety section matters more than the headline multiplier.

This is the latest in a long run of self-improvement research we have tracked, from our explainer on what recursive self-improvement is to the Google DeepMind DREAM RSI work and the last AI built by humans paper. MASS is notable because it is small, open, reproducible, and honest about its limits.

TL;DR: MASS at a glance

What problem does MASS try to solve?

Recursive self-improvement has a bootstrapping problem. When a model works on open-ended research, human experts often cannot cheaply judge whether the output got better. If the model grades its own work instead, any blind spot it has becomes part of the grading signal, and training on that signal can lock the mistake in.

MASS attacks this from the structure side rather than the grader side. Instead of one agent writing and scoring its own answer, the same model runs a team of virtual subagents with defined roles and contracts. Teams can cross-check each other, split work, and verify intermediate steps, which produces better trajectories than a lone agent. The model then learns from those better trajectories, so the team's collective experience is folded back into a single set of weights.

That is the "multi-agent self-supervision": no human labels, no stronger teacher model in the loop, and no external reward. The only supervision is the model's own comparative judgment between workflows.

How does the MASS loop work?

The repository README and the project page describe two nested loops.

The inner loop: workflow search with frozen weights

For each task, the model's weights stay fixed. A candidate workflow, which specifies roles, instructions, contracts between agents, and the order of calls, is executed. The model then judges the result against the current champion workflow, and an optimizer pass revises the workflow. Winners become the new champion. This is a search over agent organization, not over parameters.

The outer loop: distilling the champion into the weights

Once a champion workflow exists, it is run 18 times per task. The model ranks the resulting workspaces with a Bradley-Terry model and keeps up to 16 trajectories, 15 for training and 1 for validation. Crucially, the workflow text is removed from the orchestrator's prompt before training, so the model has to internalize the behavior instead of reading instructions. The team is then fine-tuned with LoRA on both orchestrator and subagent conversations.

Do this twice and you get three models: the base L0, the first-round L1, and the second-round L2. The repo exposes the pipeline as separate stages (search, collect, rank, select, render, train, export), with configs for each cycle, and exports both BF16 and FP8 weights.

If you want the broader agent context, our posts on Sakana Fugu multi-agent orchestration and Sakana's predictive-coding alternative to backpropagation show how the lab approaches orchestration and learning from different angles.

What results did the MASS paper report?

The setup uses 12 synthetic open-ended research tasks across finance, pharmacy and robotics. Nine are for training and three, one per domain, are held out for testing. Eight tasks actually supplied training data, because one task produced no workflow that beat its reference. Outside judges, GPT-5.5 and Claude Opus 4.8, grade the finished work, and MASS never sees those judgments during training.

On public benchmarks, round two's score per output token relative to the base model was:

Two things stand out. The held-out test win rate rises from about 54 percent to about 70 percent across the rounds, which suggests the learning is not purely memorization of the nine training tasks. And the coding benchmarks show no gain, which the authors attribute to a lack of software-engineering data in the synthetic task suite. The method improved what it trained on.

Note the metric: score per output token, not raw score. Team runs generate about 2.4x as many tokens as single-agent runs, so efficiency framing matters when you compare to a plain model call.

Three agents contributing to one shared workspace, representing multi-agent self-supervision results in the MASS research

Three findings worth remembering

1. Training on task solving improved the judge and the optimizer too

The model was trained only on trajectories from the executor role, yet it also got better as workflow optimizer and evaluator. Its agreement with the external judges rose from 73 percent to 93 percent across the cycles, and round-one workflows transferred back to the base model, which then won 64 percent of comparisons against workflows it found itself. The authors call this role generalization. It is the strongest argument that a single set of weights can carry all three jobs.

2. Team trajectories are more efficient training data

The round-one MASS model reached a 68.3 percent win rate after 28.8 million supervised tokens. A single-agent baseline reached 64.0 percent after 42 million tokens, so the team data needed about 31 percent fewer tokens. External judges preferred team outputs over single-agent outputs in 85.1 percent of comparisons. The authors caution that the groups also differ in workflow and verification instructions, so this comparison is confounded.

3. The optimizer, not the evaluator, may be the bottleneck

When both evaluator and optimizer were upgraded to GPT-5.5, winning workflows were found for all 12 tasks within five iterations. Upgrading only the evaluator helped much less. The fully homogeneous loop, with the 27B model in every seat, reached 11 of 12 tasks by iteration 13. If this holds up, the lever for faster self-improvement is better workflow proposal, not better grading.

What are the limitations?

The authors list them plainly, which is worth crediting:

• The synthetic suite is small: 12 tasks, with three for testing.
• Public benchmark gains are uneven, and software-engineering benchmarks did not move.
• The transfer test does not isolate the optimizer from the other roles during search.
• Token-efficiency comparisons are confounded by instruction differences.
• Task-information analysis rests on only 8 to 9 tasks, and agents inside one workflow are not independent replications.
• Workflow search is noisy, with strong iterations sometimes followed by sharp regressions.
• Evaluator agreement is measured against external judges, not ground truth.

In other words, this is a proof of concept on a narrow domain with a modest model. It does not show that frontier labs' closed loops behave the same way. It does give outsiders a runnable loop to poke at, which is rare in this area.

Several speech bubbles converging on one decision, an illustration of agents reaching consensus in a self-supervised AI loop

Why is the safety section the real story?

Sakana's authors argue that a homogeneous loop, where the same model proposes, executes and judges, needs careful study. A shared blind spot lets a flawed result pass as progress and then be reinforced through training. They call shared blind spots a possible "Achilles' heel" of recursive self-improvement.

Their prescription is independent checks, constraints on autonomous actions, and clear conditions for human intervention. They also make a subtler point: identifying a weakness does not by itself establish control. You must show that oversight can detect the consequences and intervene as the system changes.

This lines up with a debate we have covered closely. Our explainer on embedded evaluators in AI safety covers why evaluators living inside the system they grade are a structural risk. MASS offers a concrete, small-scale instance: the external judges (GPT-5.5 and Claude Opus 4.8) were used only for measurement, never as training signal, precisely so the team could check whether the internal judge was drifting. That separation is a design pattern worth copying.

For teams building agents, the safety lesson generalizes. If your agent pipeline uses the same model to write code, review it and approve it, you have a homogeneous loop of your own. Add a different model or a deterministic check somewhere in the chain. For organizations deploying autonomous agents and worried about actions taken without review, AgentBeam, the agent security platform from the explainx.ai team, is built to stop agents before they take dangerous actions.

How does MASS compare with other self-improvement work?

Most RSI headlines in 2026 involve frontier labs and closed systems. A few contrasts help place MASS:

• Scale and openness. MASS uses a 27B open model and a public repo. Our coverage of Ornith 1.5 looked at another open-weight self-improving claim, with different evidence.
• What changes. MASS changes both the workflow and the weights. Some other work only evolves a harness or prompts, as in self-evolving coding agent harnesses and NeoHourse routing.
• Who judges. MASS keeps external judges out of the loop, while many frameworks fold stronger-model feedback into training. That makes MASS a cleaner test of pure self-supervision, and also a weaker one in absolute performance.
• Measurement of automation. For how researchers are trying to measure AI research automation at all, see the Anthropic R&D automation index.

How can you try MASS today?

The README describes a low-friction entry point. Both commands below run without a GPU or model server:

python3 -m mass plan --config configs/paper.json
python3 -m unittest discover -s tests -v

For a real experiment, follow the repo's running guide, which covers environments, model downloads, vLLM serving and GPU allocation. Start with one task once the server is up:

python -m mass search --config configs/paper.json --tasks 51

Then run the stages in order: search, collect, rank, select, render, train, export. The first cycle uses configs/paper.json (L0 to L1) and the second configs/cycle2.json (L1 to L2). The README says it is a research implementation that does not include every paper ablation, so expect rough edges. Check the repository's license before reusing the code commercially.

What this means for builders

• Agent organization is a trainable asset. Workflow search plus distillation is a plausible way to turn a clever multi-agent setup into a cheaper single-model behavior.
• Token efficiency is the real KPI. The gains are framed per output token, which matters when you pay for inference.
• Do not assume transfer. The method did not help on coding benchmarks. Verify on your own domain.
• Keep your judge independent. Even a 93 percent agreement rate leaves a gap where mistakes can compound.

Treat MASS as a lab instrument, not a recipe for runaway intelligence: useful to study, narrow in scope, and honest about its blind spots. We will update this post if independent reproductions land.

Related reading

• What is recursive self-improvement?
• Google DeepMind DREAM and RSI
• The last AI built by humans paper
• Sakana Fugu multi-agent orchestration
• What is an embedded evaluator?
• Ornith 1.5 self-improving open-weight model
• Official sources: MASS project page, Sakana announcement, GitHub repository

Figures and repository details are as published on the project page and README on October 11, 2026, and may change.