Autoresearch as a Budgeted Decision Loop

OpenResearch's autoresearch model is not “launch as many variants as possible and inspect the dashboard later.” This chapter focuses on what happens after a run becomes evidence: how one decision is turned into sibling hypotheses, how the first completion changes the operator's next move, and how the tree keeps learning attached to the winner. The practical capability is to distinguish repair, refill, promote, and stop—four different responses that prevent infrastructure failure, weak evidence, and scientific progress from being confused.

The loop matters because compute is limited even when agents are fast. A researcher has limited accelerator time, attention, storage, provider capacity, and tolerance for ambiguous results. A large flat sweep can consume all of those resources without resolving which change mattered. OpenResearch's tree rules instead turn each completed run into a decision point. The goal is not to minimize the number of branches. It is to maximize what each branch lets the next branch mean.

One decision, one round, one first completion

A round begins with a deliberate parent: the baseline for the first decision, or the confirmed winner of the previous round. The researcher then forms co-equal hypotheses about one decision. They might be alternative schedules, alternative initialization choices, or alternative structural changes, but the point is that the variants are comparable options within a single question. Each option becomes a sibling under the same parent.

This one-decision rule is a control on interpretation. If one sibling changes the architecture and another changes the dataset and evaluation metric, their numbers may differ, but the tree cannot tell the researcher which change caused the difference. The problem is not that complex changes are forbidden. Complex changes can be legitimate hypotheses. The problem is that mixing unrelated decisions in one round makes a result owe several explanations at once and makes the next parent less informative.

Each sibling receives a concrete description, changes its code or configuration on its own branch, and is committed before launch. The common run command stays fixed. The recorded source snapshot then gives the backend an immutable version of that branch. The result is a small bush of comparable questions, not a set of uncommitted intentions waiting to be interpreted after the fact.

The runs can be launched in parallel, but parallel launch is not the end of the round. The intended loop waits for the first completion so the researcher can regain control as soon as one slot produces evidence. Waiting is a sleep-until-change signal, not the complete source of truth. A run may have finished while the researcher was reading another log, and the wait operation may not report every completion that occurred outside its observation window.