Zifeng Wang
← All writing

Multi-Agent Autoresearch
and Self-Improvement: Catching Up on Advances in 2026

Scaling autoresearch takes more than adding agents. This review examines how coordination, shared memory, and search make parallel experiments build on one another—and how research experience can improve the strategies, workflows, and models behind future discoveries.

AI Agents 22 min read

I am interested in how autoresearch scales: from a single agent running experiments to many agents exploring ideas in parallel. Increasing the number of agents raises questions about how to divide research, coordinate exploration, and build on one another’s discoveries.

Recent work tackles this through orchestrators, self-organized communities, search algorithms, and learning. The thread connecting them is how parallel trials become cumulative progress: what gets remembered, how discoveries reach other agents, and how experience improves the next research decision.

Two ways to organize research

Two patterns of multi-agent research

Centralized

One overall loop, delegated subagent loops

Central research A research question brings in an orchestrator, which delegates to three subagents. Each subagent has a local research loop. Results converge at the orchestrator, which starts the next overall research cycle. Research question Orchestrator Subagent A research iterate Subagent B research iterate Subagent C research iterate Overall research loop

A question starts the overall research loop.

Decentralized

Peer communication and shared-space access

Decentral research Three peer agents communicate directly and read or write a shared space. These interactions proceed independently without an orchestrator. Agent A research Agent B research Agent C research Shared spaceRead / write tasks, findings, and code

Agents communicate directly or read and write a shared space.

Figure 1. Centralized research delegates local loops and brings their results back to an orchestrator. Decentralized research connects peers through messages or shared artifacts. Conceptual illustrations.

01 Centralized Research

The first way to scale is to let one agent manage several experiments. But a lead agent must coordinate information as well as work: it has to turn an expanding research record into useful context for itself and its workers.

CoMind

CoMind[1] starts with an existing research community: Kaggle notebooks, discussions, datasets, and models. It builds a dependency graph linking notebooks to their resources, so that an agent can retrieve a working approach together with what it needs to run.

Each iteration has a concrete division of labor. The Coordinator selects promising resources. An Analyzer assesses their novelty, feasibility, effectiveness, and efficiency; an Idea Proposer uses these reports and a persistent idea memory to propose and filter research directions. The Coordinator turns selected ideas into distinct implementation drafts and launches parallel Coding Agents. Each Coding Agent works in a persistent notebook, runs experiments, and receives evaluation feedback. Successful solutions and metrics are published back to the community.

Key insight: community knowledge is part of the search algorithm. Removing public resources hurts CoMind, while its coordinated use of those resources outperforms simply adding code or retrieval to AIDE in the ablation study.[1] The lesson I take is to organize parallel experiments around existing evidence and distinct hypotheses, so each worker extends a useful starting point.

CoMind makes the division of labor explicit. As the campaign grows, the next problem is how its coordinator and workers can use accumulated evidence without inheriting an ever-longer conversation.

Stateless Language Agents

In SLA,[2] neither the Advisor nor its Workers keep an ever-growing conversation. The harness stores the global best program and score, each Worker’s local candidate, and structured outcomes—including the difference between a failed execution and a valid experiment that did not improve the score.

At each planning epoch, a fresh Advisor receives the task, best code, and summarized evidence about previous directions, then assigns concrete experiments. At each local trial, a fresh Worker receives its assignment, retained candidate, and relevant feedback. An external evaluator checks correctness and measures the result. A Worker can keep refining its local best even while it trails the global best; this gives a new branch time to develop.

SLA reconstructs a fresh Advisor context from persistent research state, assigns parallel Workers, evaluates candidates, and stores outcomes for the next invocation.
Figure 2. Fresh contexts are reconstructed from harness-owned state. Reproduced from Zhang et al., Fig. 3, SLA (CC BY 4.0).[2]

Key insight: preserving evidence and exposing history are different decisions. In the ablations, agents starting from the same research state make less progress when focused reconstruction or Worker isolation is removed.[2] Research continuity therefore depends on selecting what each role sees. More accessible history can dilute the evidence needed for its next decision.

SLA reconstructs a selective view of a rich research record. Forgetting asks how far this can be compressed before the next round begins.

Scaling Discovery Requires Forgetting

Scaling Discovery Requires Forgetting[3] takes a more aggressive approach to context. During a round, peer agents edit and evaluate candidates, and can asynchronously inspect one another’s candidate commits and scores. There is no coordinating LLM assigning each experiment.

At a round boundary, the system destroys the sessions and accumulated search history. Only the best candidate and its score seed the next team. A new round therefore starts from a strong implementation without inheriting the previous team’s explanations, commitments, or failed branches.

What survives a restart?
SLA: best code + local branches + structured outcome evidence.
Forgetting: best code + score.

Key insight: search memory can become an obstacle to exploration. The paper observes agents making smaller edits as they become anchored to past attempts; resetting from the best candidate restores progress in its tested tasks.[3] Compared with SLA, this treats forgetting as an exploration mechanism. The design question becomes which evidence helps a fresh search and which merely preserves its previous commitments.

02 Decentralized Research

Forgetting already shows that shared code can carry progress without a coordinating LLM. Larger communities need additional ways to exchange explanations, decide who contributes, and combine concurrent work. The following papers move these responsibilities into shared institutions, participation rules, and workspace protocols.

The Station

The Station[4] gives resident agents a research environment with rooms and actions. In the Research Center, an agent reads a mathematical task and its evaluator, then submits a natural-language experiment request to a separate coding assistant. That assistant implements, runs, and debugs the experiment; the researcher inspects the report and code before choosing its next step.

Communication has different persistence levels. A public memory room holds forum threads; mail supports private asynchronous exchanges; an archive stores accepted papers for later researchers. Private lineage notes can pass to replacement agents. A periodically appointed supervisor offers high-level guidance, while researchers choose their own experiments.

Key insight: explanations can be reusable research outputs. A construction is more useful to later researchers when they can inspect why it works, or why a whole family of alternatives fails. The Station preserves these arguments in papers and lineage notes. Its broader lesson is that collective discovery needs a growing body of explanations alongside a growing pool of candidates.

The Station studies a resident research society. EinsteinArena extends the question to agents operated independently by different participants.

EinsteinArena

EinsteinArena[5] opens a similar research process to independently operated agents. Each problem exposes its statement, verifier source, leaderboard, submitted solutions, and discussion. An agent accesses the platform through its API, inspects an existing construction or program, modifies it locally, and submits a candidate for verification.

A verified submission updates the public record. Discussion adds the information a score cannot carry: why a construction works, which modification failed, or which assumption needs checking. A later agent can retrieve both the artifact and that reasoning, then begin from the existing result instead of independently rediscovering it.

Key insight: shared verification can coordinate researchers who share no controller. A common verifier makes contributions comparable, and public artifacts let independently operated agents extend them. Discussion carries the reasoning needed for reuse. Compared with The Station, the emphasis shifts from maintaining a resident society to providing an interface through which an open population can accumulate discoveries.

These platforms leave participation to each agent’s judgment. MPT gives that decision an explicit auction rule and a training signal.

MPT: Learning Self-Orchestration through Bidding

Market-based Post-Training (MPT)[6] gives agents predefined roles but learns when each should act. Each turn, the highest bid in [0, 1] wins. The winning bid also allocates training credit:

vt = rt + bt+1vt+1
creditt = (1 − bt)vt

Here, r is reward and v includes downstream value. A 0.8 bid retains 20% and passes 80% backward. Action policies learn from local credits.

To train bids, restore a contested state and resample the winner’s bid below the runner-up’s. Continue both branches and prefer the bid associated with higher return.

Illustrative counterfactual: restore one state. B bidding 0.8 beats C at 0.5 and leads to return 12. Resample B to 0.4 so C acts, leading to return 8. Prefer B’s original bid.
Figure 3. Illustrative bids and returns in a same-state counterfactual comparison.[6]

Key insight: coordination should adapt as capabilities change. With trained action policies held fixed, learned bidding still improves the crafting comparison against alternative coordination strategies.[6] Participation deserves its own learning signal, coupled to credit assignment. MPT studies one actor per turn; parallel experimental execution remains a separate scheduling problem.

MPT allocates turns within a trajectory. Agensh addresses many workers making progress simultaneously, without waiting for a shared next turn.

Agensh: Self-Organization at 1,024 Agents

Agensh[7] gives every worker the same cooperation loop, a Git workspace, shared context, and direct or broadcast messages. A worker reads the current goal and findings, chooses useful work, and appends a CLAIM describing its scope. Claims communicate intent; workers resolve overlap through messages.

The worker implements its contribution, shares intermediate findings, verifies acceptance criteria, and merges the result with an explanation and verification evidence. If another contribution causes a conflict, it pulls the new state, resolves the conflict, and retries. Other workers can continue throughout: there is no generation barrier and no lead agent that must approve every assignment.

Each worker repeats: read shared state → claim work → implement and share → verify → integrate.

Key insight: a local cooperation protocol can replace many centralized decisions. Claims, verification evidence, and merges make work discoverable and integrable while other workers continue. This suggests that scaling depends on task boundaries and integration rules as well as agent intelligence. Its 1,024-agent result is demonstrated on software reconstruction, where contributions can be expressed and tested as code.

Collaboration Depends on the Baseline

The choice among these coordination designs should start from a strong single-agent baseline. In Capable language models can outgrow the benefits of collaboration, the authors hold task prompts, tools, and compute budgets constant while varying coordination and model capability.[13] Single-agent performance is a strong predictor of whether collaboration helps; sufficiently capable baselines can leave less room for additional agents to improve results.

Key insight: measure the marginal value of coordination. For autoresearch, I would compare teams and strong single agents at matched budgets, and report faster wall-clock progress separately from better final solutions. The paper’s capability threshold is an empirical result within its studied settings, rather than a universal limit on collective research.

Once agents can share and integrate work, the next question is where to spend the next unit of research effort. The progression here runs from a programmed tree policy, through asynchronous population search, to agent-directed exploration—and finally to improving the feedback used to guide that exploration.

AIDE: Searching over Candidate Programs

In AIDE,[8] a search node is an executable program plus its score, execution status, and parent. The search controller first creates independent Draft roots. It can Debug an invalid candidate within a limited repair depth; otherwise, it Improves the current best valid candidate.

For an expansion, the LLM receives the task, selected code, and compact notes about earlier attempts. It proposes a code change; execution produces either a validation score or an error. The controller records the new node and decides where to expand next. A failed run remains a branch that can be repaired rather than disappearing into a conversation.

AIDE retains a branching tree of candidate programs. The highlighted path leads to the best valid candidate, scoring 0.78. The controller selects that node, expands it through Improve, and evaluates the new child at 0.81 before selecting again. Earlier and failed branches remain in the tree.
Figure 4. One tree-search iteration: select the best valid candidate for improvement, expand it, evaluate the child, and select again. Gray branches retain earlier attempts; Debug can repair failed nodes. Scores and history are illustrative.[8]

Key insight: executable candidates make research progress explicit and recoverable. A node preserves an implementation and measured evidence even when the next LLM call has a fresh context. Search can revisit or repair that node. The simple greedy improvement policy also exposes a limitation: explicit bookkeeping preserves alternatives, but a selection rule still has to allocate effort to them.

AIDE makes each expansion explicit. AIRA₂ extends candidate inheritance to experiments running concurrently, with different completion times.

AIRA₂: Asynchronous Multi-GPU Search

AIRA₂[16] maintains a population of solutions in a central database. Whenever a worker becomes free, an algorithmic Global Orchestrator samples parents using temperature-controlled, rank-based selection, then dispatches mutation from one parent or crossover from two. It does not wait for every candidate in a generation to finish.

Each mutation is a tool-using ReAct session: the worker can inspect data, edit code, execute it, debug, and submit a solution. Workers run in isolated containers with one GPU each. Completed solutions return to the population, making them available as parents while slower experiments are still running.

Hidden Consistent Evaluation scores candidates on the same hidden search split through a protected scorer, instead of trusting an agent’s self-reported metric. A separate final evaluation remains outside that search feedback.

Key insight: parallel discoveries need to become shared starting points. In the paper’s comparison, independent best-of-K workers plateau earlier than evolutionary workers that inherit and combine candidates.[16] Extra throughput becomes cumulative search through the population. Hidden consistent scoring supplies the common signal needed to decide which discoveries should receive more budget.

AIRA₂ gives workers autonomy within an attempt while an algorithm selects their parents. CORAL moves more of the research policy into the coding agent itself.

CORAL: Letting Agents Manage Exploration

CORAL[9] lets a long-running coding agent decide what to explore, what to implement, and when to pivot. Parallel agents use isolated worktrees but share persistent directories: attempts/ for solutions and scores, notes/ for findings, and skills/ for reusable procedures.

The harness intervenes through heartbeats. Per-iteration reflection asks agents to record what they learned; periodic consolidation organizes accumulated knowledge; stagnation prompts encourage a different direction. An agent can inspect a peer’s attempt, reuse a recorded procedure, and continue its own experiment without a manager assigning that dependency. Recovery preserves the long-running session, unlike SLA’s fresh invocations.

Key insight: search can accumulate knowledge about how to explore. Notes and skills preserve strategies and failure explanations that a candidate score alone cannot express. The ablations favor shared co-evolution over taking the best independent agent on the three tested tasks.[9] The implication is that agents should exchange reusable research knowledge as well as successful code.

MethodPersistent search stateWho chooses the next experiment?
AIDEProgram treeA programmed node-and-operation policy
AIRA₂Solution populationAn asynchronous evolutionary scheduler
CORALAttempts, notes, skillsThe coding agent, guided by heartbeats

Either kind of controller still needs feedback. When full evaluation dominates the budget, choosing experiments also requires choosing how to measure them.

DuoDiscover: Co-Designing Cheaper Feedback

DuoDiscover[10] addresses a bottleneck that more workers cannot remove: evaluating the real objective may take minutes or hours. Each worker therefore chooses both a target—a code region to optimize—and a yardstick, a cheap evaluator for that target. For example, it might isolate a hot loop instead of repeatedly running the entire workload.

The worker edits code and hill-climbs the yardstick in a fast inner loop. A slower outer loop runs true evaluations to confirm improvements and test whether the proxy still ranks candidates correctly. If rankings cease to agree, the yardstick needs revision. The orchestrator can stop an unproductive worker, brief others, or launch a worker to combine complementary changes.

DuoDiscover orchestrates a fleet of workers. Each worker co-discovers a target and cheap yardstick, uses a fast edit-and-score loop, and checks gains and yardstick fidelity with slow true evaluations.
Figure 5. A fast search loop sits inside a slow verification loop; the orchestrator can stop, combine, or brief workers. Reproduced from Agarwal et al., Fig. 2, DuoDiscover.[10]

Key insight: evaluation itself is an object of discovery. Under an expensive objective, finding a cheap, faithful comparison can unlock more useful iterations than generating more proposals. Co-discovering the target and yardstick lets the agent improve its own feedback loop. Full evaluations keep that loop connected to the objective the research campaign actually cares about.

04 Recursive Self-Improvement

The preceding systems mainly improve task solutions. A further step is to make the researcher itself an improvement target. The next papers progressively move from editing harness code, to training research operators, to using an optimized team’s behavior to train the model that organizes the next team.

Weco’s AIDE²: Improving the Searcher

Weco’s AIDE² study,[17] detailed in Recursive self-improvement of AI research agents, moves the search target up one level. An outer agent edits the inner research agent’s harness code: how it drafts solutions, chooses branches, constructs context, and spends its budget. Each proposed harness runs AI R&D tasks under a fixed monetary budget; private held-out grading checks whether the researcher improved. A better harness becomes the next incumbent.

One discovered design treats draft lineages as bandit arms: allocate effort across lineages, improve greedily within one, and fork a stalled search from the global best under a new strategy. The outer loop can therefore improve the algorithm that allocates future experiments, rather than only producing another candidate solution.

Inner search: change a solution program and measure task quality.
Outer search: change the searcher’s code and measure its performance across tasks.

Key insight: harness quality is a source of capability at fixed model weights. The experiment makes the research algorithm itself editable and measurable, so better budget allocation and context can become discoveries. The main run fixes the outer proposer; replacing it with the evolved researcher did not establish significant acceleration. Improving a researcher and accelerating the improvement process remain separate claims.

AIDE² edits the searcher’s code. Frontis-MA1 keeps an explicit program-search controller and trains the model that expands its nodes.

Frontis-MA1: Training the Model That Expands the Tree

Frontis-MA1 is the trained model in OpenRSI; OpenMLE-Evo is the search controller using it.[11] Like AIDE, it maintains executable program candidates and parent–child links. Crossover can give a child two parents, making the lineage a graph. Each evaluated node stores code, a score, validity, and an experience record.

For each expansion, the controller samples parent(s) using score, improvement over their parent, and method-family novelty. A promising branch can therefore receive effort before it becomes the best-scoring one. It retrieves context for the chosen operation: ancestors and siblings for Improve, related errors for Debug, or evidence from both parents for Crossover. Draft starts a new root. The model produces a child program; execution supplies its score and the next experience record.

Where training enters. Execution-grounded SFT and RL train Draft, Improve, Debug, and Crossover. Model weights stay fixed during an inference search; new outcomes update the search state and memory.

Original Frontis-MA1 framework: four shared code-evolution operators drive a program-search tree, are initialized by supervised learning on executable rollouts, and are optimized by reinforcement learning with sandbox feedback.
Figure 6. The same operators connect evolutionary inference (1), supervised training (2), and reinforcement learning (3). Reproduced from Yang et al., Fig. 5, Frontis-MA1 (CC BY 4.0). Click the figure to enlarge.[11]

Reading the figure. Panel 1 shows how operators expand and evaluate program candidates. Panels 2 and 3 show how those operators are trained: first imitate successful executable rollouts, then learn from measured rewards. The trained model is reused inside the search loop.

Key insight: parent selection and node expansion are separate levers. OpenMLE-Evo improves which candidates receive budget and context; Frontis-MA1 improves the transformations applied to them. A better tree policy and a better proposal model can contribute independently.

Frontis-MA1 learns how to expand program candidates. MASS changes the search object to the team’s workflow, then learns from its executions.

MASS: Search Workflows, Then Learn Their Behavior

In MASS, the search candidate is a workflow specification: which subagents to call, their instructions, what each must return, and the call order.[12] Revising a workflow changes how the team solves a task; executing it produces a deliverable workspace. For example, a revision might require one subagent to hand runnable code to the next, rather than only a written recommendation.

Search stage: revise one workflow at a time. With weights fixed, the optimizer reads the previous proposal, the retained best workflow, and feedback history to propose the next version. Every version is executed. A self-evaluator compares its workspace with the retained best workspace; a win replaces the incumbent, and either verdict enters the feedback history. The paper describes this as evolution with an elite size of one. It does not select arbitrary parents from a branching program tree.

Training stage: learn from the retained workflow’s executions. Run it multiple times, self-rank the resulting workspaces, and fine-tune on selected orchestrator and worker trajectories. The supplied workflow is removed from the orchestrator’s training input, so delegation is learned from the task rather than copied from that prompt. Updated weights return to executor, optimizer, and evaluator roles; external judges are reserved for final evaluation.

Key insight: workflow search can construct the supervision for learning collaboration. The current model first elicits useful team behavior through better instructions and handoffs, then learns from that behavior. The search object is a workflow; the longer-term improvement resides in the shared model.

MethodSearch candidateHow search advancesWhat is learned
AIDE[8]Executable programDraft, repair, or improve a selected nodeOriginal setup uses a frozen proposal model
Frontis-MA1 / OpenMLE-Evo[11]Program with parent linksSample parents; invoke a trained expansion operatorModel weights for Draft / Improve / Debug / Crossover
MASS[12]Text specifying a team workflowSequential proposals with one retained bestShared model, from selected team executions

RSIGym: Making Self-Improvement Testable

AIDE², OpenRSI, and MASS improve different parts of a researcher. RSIGym provides an environment that makes the permitted changes explicit.[14] Agents call reusable training, inference, rollout, evaluation, and sandbox services under a shared budget. Its Data track changes training data with a fixed recipe and harness; Harness changes execution code with fixed model weights; Joint opens data, training settings, and harness together.

Key insight: define what can change before measuring improvement. Shared infrastructure supports controlled studies of individual interventions and their interaction. RSIGym therefore complements the algorithms above by making their improvement targets experimentally accessible. Its reported runs measure target-system gains; whether inherited changes improve subsequent research cycles remains an open evaluation question.

05 Outlook

Across these papers, scaling depends on turning experiments into evidence that changes future decisions. One promising extension is to anticipate that evidence before paying for the full experiment.

Predicting before executing. DuoDiscover makes measurement cheaper by constructing target-specific yardsticks.[10] Language Models as AI Research World Models explores a complementary capability: an LLM reads the research environment, a proposed code or configuration change, and experimental history, then predicts the resulting gain.[28] The study uses fixed weights and supplies experience in context. Relevant experimental records improve intervention ranking, including transfer across environments; in the tested ablations, this knowledge can matter more than additional reasoning effort. The important finding is that experiment logs can become predictive research knowledge.

From forecasts to experimental budgets. I see a possible combination: forecast promising changes, test them with cheap measurements where available, and spend full experimental budget on the most informative candidates. Observed outcomes would then update the evidence used for later forecasts. Deciding when to trust a forecast, explore an uncertain direction, or retire an exhausted branch becomes part of research control. The current world-model study evaluates outcome prediction and selection from recorded candidates under fixed-reference environments; integrating prediction into a live, continually changing campaign is a further step.[28]

Compute allocation. Agents should be able to submit experiments with resource requirements while a runtime allocates and releases GPUs. Slurm already supports GPU allocation, dependencies, and heterogeneous jobs.[15] The research layer still needs to decide when a small trial justifies a larger run, how competing ideas share a budget, and when evidence should redirect that budget.

Longer campaigns. For research lasting months or a year, continuity must survive individual sessions. SLA and Forgetting offer different answers to what should persist.[2][3] Open questions include how to reconstruct useful context, recover from interruptions, and hand work to fresh agents without losing evidence.

Cumulative exploration. With thousands of agents, communication needs to make code, tools, assumptions, and failed experiments discoverable and reusable. Search also needs a way to step back: after repeated refinements without progress, when should a branch stop, revisit an earlier candidate, or change hypothesis? Sharing results and controlling search need to work together.

06 Autoresearch Benchmarks

The following task resources recur in this review, with original references and links to the papers that use them.

Benchmark / resourceWhat is measuredUsed in this review
MLE-bench[18]Build ML solutions for Kaggle competitions; held-out scores and medals.AIDE[8], AIRA₂[16], Frontis-MA1[11], AIDE²[17]
Anthropic kernel task[19]Minimize execution cycles on a simulated VLIW/SIMD machine.SLA[2], Forgetting[3], CORAL[9]
FrontierCS[23]Improve executable algorithms with objective partial scores.SLA[2], Forgetting[3], CORAL[9]
SOL-ExecBench[20]Optimize real GPU kernels; correctness and proximity to hardware limits.SLA[2], DuoDiscover[10]
MLE-Live[1]Kaggle-style ML engineering with community discussions and shared code.CoMind[1]
NatureBench[27]Match or exceed published scientific ML results on hidden tests.Frontis-MA1[11] NatureBench Lite subset
KernelBench[21]Replace PyTorch workloads with correct, faster GPU kernels.AIDE²[17] reward-hacking diagnostic
nanochat-autoresearch[22]Improve a language-model training script under a fixed compute budget.Forgetting[3]
FrontierSWE[24]Long-horizon software implementation and performance engineering.SLA[2]
ProgramBench[25]Rebuild software from executable behavior; behavioral test-pass rate.Agensh[7]
SWE-fficiency[26]Speed up repository workloads while preserving correctness.DuoDiscover[10] SWE-fficiency-Lite subset

Subsets and diagnostic uses are marked. Anthropic’s task uses a VLIW/SIMD simulator; SOL-ExecBench and KernelBench run on GPUs. Hardware, budgets, and hidden evaluation splits vary.

For broader research execution, MASS additionally evaluates on ScienceAgentBench, MLR-Bench, AstaBench E2E-Bench-Hard, and DSBench.[12] These cover scientific workflows, open-ended ML research, and data-science tasks.


References

  1. Li et al. CoMind: Towards Community-Driven Agents for Machine Learning Engineering. ICLR, 2026.
  2. Zhang et al. Stateless Language Agents: Scaling Long-Horizon Automated Research. 2026.
  3. Tan et al. Scaling Discovery Requires Forgetting. 2026.
  4. Chung, Du, and Wesley. Autonomous Mathematical Discovery in an Open-World Multi-Agent Environment. 2026.
  5. Bianchi et al. Harnessing the Collective Intelligence of AI Agents in the Wild for New Discoveries. 2026.
  6. Xu et al. Learning Self-Orchestration in Decentralized Agent Swarms. 2026.
  7. Zhan et al. Agensh: Scaling Organizational Intelligence to 1,024 Agents. 2026.
  8. Jiang et al. AIDE: AI-Driven Exploration in the Space of Code. 2025. Code.
  9. Qu et al. CORAL: Towards Autonomous Multi-Agent Evolution for Open-Ended Discovery. 2026.
  10. Agarwal et al. DuoDiscover: Scaling Autonomous Discovery Beyond the Evaluation Bottleneck. 2026.
  11. Yang et al. Frontis-MA1: Training an AI4AI Model towards Recursive Self-Improvement in Machine Learning Engineering. 2026.
  12. Lee et al. Recursive Self-Improvement through Multi-Agent Self-Supervision. 2026.
  13. Kim et al. Capable language models can outgrow the benefits of collaboration. Nature Machine Intelligence, 2026.
  14. Meng et al. RSIGym: A Flexible Environment for Recursive Self-Improvement. 2026.
  15. SchedMD. Slurm Workload Manager documentation: GPU and generic resource scheduling, job arrays and dependencies, and heterogeneous jobs. Accessed October 19, 2026.
  16. Hambardzumyan et al. AIRA₂: Overcoming Bottlenecks in AI Research Agents. 2026.
  17. Srikanth et al. Recursive self-improvement of AI research agents. 2026. Weco’s AIDE² blog post.
  18. Chan et al. MLE-bench: Evaluating Machine Learning Agents on Machine Learning Engineering. ICLR, 2025.
  19. Anthropic. Original Performance Take-Home Assignment. Task release, 2026.
  20. Lin et al. SOL-ExecBench: Speed-of-Light Benchmarking for Real-World GPU Kernels Against Hardware Limits. 2026.
  21. Ouyang et al. KernelBench: Can LLMs Write Efficient GPU Kernels? 2025.
  22. Karpathy. autoresearch: AI agents running research on single-GPU nanochat training automatically. Task and code release, 2026.
  23. Mang et al. FrontierCS: Evolving Challenges for Evolving Intelligence. ICML, 2026.
  24. Proximal. FrontierSWE: Benchmarking coding agents at the limits of human abilities. Benchmark release, 2026.
  25. Yang et al. ProgramBench: Can Language Models Rebuild Programs From Scratch? 2026.
  26. Ma et al. SWE-fficiency: Can Language Models Optimize Real-World Repositories on Real Workloads? ICML, 2026.
  27. Wang et al. NatureBench: Can Coding Agents Match the Published SOTA of Nature-Family Papers? 2026.
  28. Wang et al. Language Models as AI Research World Models. 2026.

Citation

Please cite this post as:

Wang, Zifeng. “Multi-Agent Autoresearch and Self-Improvement: Catching Up on Advances in 2026”. Zifeng Wang’s Blog (Oct 2026). https://zifengwang.net/blog/multi-agent-autoresearch-and-self-improvement.html.

Or use the BibTeX citation:

@article{wang2026autoresearch,
  title = {Multi-Agent Autoresearch and Self-Improvement: Catching Up on Advances in 2026},
  author = {Wang, Zifeng},
  journal = {Zifeng Wang's Blog},
  year = {2026},
  month = {October},
  url = {https://zifengwang.net/blog/multi-agent-autoresearch-and-self-improvement.html}
}
← All writingBack to top ↑