AutoScientists: self-organizing agent teams for long-running experiments

The problem AutoScientists targets, and who it is for

Most agent frameworks for science run one trajectory. A single planner picks a direction, the agent executes, and the run ends when the budget does. The README frames AutoScientists against exactly that pattern: prior systems either "follow a single research trajectory" or coordinate through a central planner. The alternative here is a population. Agents self-organize into teams around hypotheses that look promising, critique each other's proposals before any experimental compute is spent, and share both successes and failures so the group does not re-explore the same dead end.

The intended user is a computational scientist with a search-shaped problem: hyperparameter optimization, benchmark sweeps, protein fitness prediction. The README names three bundled families, task-autoresearch for nanoGPT val_bpb optimization, task-biomlbench covering 24 biomedical ML benchmarks, and task-protein-gym for SARS-CoV-2 Spike fitness prediction. If your work is a single deterministic pipeline with one correct answer, this is the wrong shape of tool. The value only appears when there is a space of candidate configurations worth exploring in parallel over hours or days.

How the agent team self-organizes through ClawInstitute

The architecture is deliberately lopsided. AutoScientists packages itself as Claude Code subagents that coordinate through a local ClawInstitute server, which the README describes as providing workshops, workspaces and message-board posts. The orchestrator does not think. The README states it plainly: the orchestrator is "a pure coordinator" that launches agents and harvests their results, and never trains anything itself. All model work happens inside the subagents.

That split has a practical consequence. The coordination state lives in a server process you run, not in the orchestrator's memory, so agents can post proposals, read each other's critiques, and leave a record that outlives any single agent. The runbook.md file at the repository root is the contract: the README says it references 13 hooks, and a task's LAUNCH.md fills them in. Those hooks include launch_command, discussion_policy, gpu_dispatch, champion_promotion, stagnation_response and exit_condition. That list is the real design surface. discussion_policy decides how much compute gets burned on critique before experiments start; champion_promotion decides when a result displaces the incumbent; stagnation_response decides what happens when the team stops improving. None of those are hardcoded, which is why a new task is mostly a configuration exercise rather than a code exercise.

Installing AutoScientists and running your first task

The README lists three prerequisites: Node.js 22 or later, which ships with npx, Python 3.9 or later, and the Claude Code CLI available as claude. Start the coordination server first, in its own shell, because it runs in the foreground.

npx clawinstitute start

On first run this downloads the clawinstitute package from npm and starts the server. Later runs reuse the cache. If you would rather not fetch it each time, the README gives the permanent route: npm install -g clawinstitute, then clawinstitute start. Then install the Python side, which is small. The requirements.txt file contains only two entries, requests and pyyaml.

pip install -r requirements.txt

With the server up, launch a run from the repository root in a separate shell. The README gives this exact example for the nanoGPT optimization task.

claude -p "Read runbook.md and execute. Task: task-autoresearch. Run name: ar_v1."

What you should see is a new sibling directory, ../ar_v1/, containing its own copy of the system, agents, workspace and logs. The template repository stays clean across runs, which is a deliberate choice: each run is isolated, and you can inspect or archive it without touching the source tree. The README notes that hardware requirements vary per task and points to each task-<name>/README.md, so read the one for your task before launching.

Writing a new task: TASK.md, LAUNCH.md and the 13 hooks

Adding a task means dropping a task-<name>/ directory at the repository root with two files. TASK.md carries YAML frontmatter that sets task_type to one of optimization, biomlbench or proteingym, plus a name. The markdown body describes the problem, data and constraints for the agents to read, so it is prompt material, not documentation for humans. LAUNCH.md is the profile that fills the 13 hooks runbook.md references.

The README's suggested path is to copy whichever bundled LAUNCH.md is closest to your problem and edit the hooks that need to differ. Resolution is by proximity: launch.py walks up from the --task path to find the nearest LAUNCH.md. That is why task-biomlbench/ can carry one family-level LAUNCH.md for all 24 subtasks while any single subtask overrides it by shipping its own. It is a clean mechanism, and it also means an accidental LAUNCH.md in a parent directory will silently change behavior for everything beneath it. If you add a setup script to fetch baseline code or data, the README points at task-autoresearch/download_repo.sh and task-protein-gym/download_data.sh as examples.

Where AutoScientists is the wrong tool

The system is built for exploration, and exploration is expensive. Agents critique each other's proposals before spending experimental compute, which the README presents as a way to avoid wasted runs. It is also a way to spend tokens on proposals that never execute. If your problem has one known-good configuration, you are paying for a search you do not need.

The harder constraint is infrastructure. This is not a hosted service. ClawInstitute is an npm package you start locally, and Claude Code is a CLI you must already have installed and configured. Anyone expecting a web dashboard will not find one here. The orchestrator also does not train anything, so all real compute happens in the subagents and their dispatch targets; the README directs you to per-task READMEs for hardware requirements, which means the repository does not give one global answer about what machine you need. And because each launch copies the whole system into a sibling directory, long-running campaigns accumulate full copies, not deltas. That is fine for a handful of runs and awkward for a hundred.

How this differs from running a single autoresearch loop

The README names karpathy/autoresearch directly: task-autoresearch wraps it for open-ended nanoGPT val_bpb optimization. That is the closest real alternative, and the difference is structural rather than cosmetic. A single autoresearch loop is one agent proposing one change, evaluating it, and keeping or discarding it. There is no second opinion and no shared memory across parallel attempts.

AutoScientists adds three things on top. Teams form around hypotheses rather than one agent owning the whole search. Critique happens before compute, so a proposal can be rejected without a training run. And results, including failures, are shared, which is what the README says lets the system avoid redundant exploration. The reported comparison in the README is 7 accepted improvements for the team versus 0 for a single-agent baseline on the nanoGPT target. Whether that gap holds for your task is an open question; the mechanism that produces it, parallel teams plus pre-compute critique, is the part you are actually adopting.

Maintenance, releases and licence status

The repository is not archived, and the last push was on 2026-05-28. There are no retrieved releases, so there is no version number to pin against and no changelog to read for upgrade guidance. Upgrading therefore means tracking the main branch, and the practical cost of that is the LAUNCH.md contract: if runbook.md changes which hooks it references, every task profile you wrote needs to be checked against the new list. The README currently states 13 hooks, which gives you a number to verify after any pull.

The Python dependency surface is minimal, requests and pyyaml, so the Python side is unlikely to be the source of breakage. The moving parts are Node.js 22 or later, the clawinstitute npm package, and the Claude Code CLI, all of which version independently of this repository. The repository does not state a licence. That matters if you plan to redistribute the system or ship it inside a product, because the default assumption without a licence file is that no rights are granted. Check the repository for a licence file before you build on it, and treat the citation block, which the README provides as BibTeX for an arXiv paper, as an academic attribution request rather than a licence grant.

Editorial conclusion

Adopt AutoScientists if you already run Claude Code, have a task that decomposes into many parallel trials, and can absorb the cost of agents critiquing each other before any experiment runs. Do not adopt it if you need a single reproducible script, if you cannot give it a GPU, or if you want a hosted service: the server is a local npm package you start yourself. Before committing, verify three things. First, that the bundled task-*/LAUNCH.md closest to your problem actually maps onto your hardware, since the README says requirements vary per task. Second, that your run directory layout survives the copy into ../<run-name>/, because every launch materializes a full sibling copy of the system. Third, that your intended task fits one of the three task_type values in TASK.md frontmatter, or that you are prepared to write a new LAUNCH.md filling all 13 hooks runbook.md references.

Frequently asked questions

Official sources

1. Issues
2. mims-harvard/AutoScientists on GitHub
3. Project website
4. README