The State Machine That Makes Experiments Recoverable
AutoResearch’s execution runtime has to coordinate work that is slow, interruptible, and produced by agents with different responsibilities. This chapter examines the runtime as a state machine: who owns a transition, which dependencies unlock the next unit, what happens when a worker disappears, and why a status field alone cannot prove completion. The useful judgment is whether the system can resume from evidence-backed state rather than from the last sentence an agent happened to write.
A queue is a model of dependency, not a to-do list
The runtime starts with a queue whose units represent meaningful research transitions. The initial sequence moves from spawning agents to planning, plan review, code preparation, code review, pilot execution, pilot analysis, scale-up planning, main coding, main review, main execution, and main analysis. Each unit has a status and, where necessary, a predecessor. A main experiment cannot become ready merely because a coder has finished; its plan, code, and review predecessors must have reached an accepted terminal state.
This is a directed acyclic graph in a practical sense: dependencies express what must be true before a unit can be claimed. The engine treats only done and an engine-approved skipped as satisfied dependencies. A failed required unit does not unlock its successor, even if a coordinator would prefer to keep the queue moving. That choice preserves the meaning of the workflow. A failed review is not evidence that the code passed review, and a failed pilot is not evidence that the main experiment is ready.
The queue also distinguishes work from judgment. Ordinary units can be marked complete after their required evidence is present. Result analysis, external criticism, and blind review are different. Their completion is itself a decision that changes the topology of the queue: analysis must add a critic, a critic may add a revision cycle or a blind review, and blind review may add a revision or a close unit. The engine therefore refuses to let a generic completion command stand in for those adjudications.
That refusal is important because a generic status transition loses causality. If a result-analysis unit is simply marked done, the queue can appear empty without recording whether the next action was to continue, stop, or seek an outside challenge. If a blind-review unit is marked done without processing its rating, the system can close without considering the reported weaknesses. AutoResearch gives each of these transitions a dedicated command so the artifact check and the queue mutation happen together.
The coordinator and the engine consequently have different authorities. The coordinator decides which agent to summon and can update a human-readable state snapshot. It does not own the definition of a valid terminal state. The engine does not call agents or interpret research content; it owns queue mechanics, dependency satisfaction, leases, adjudication boundaries, and completion evidence. Keeping those responsibilities separate reduces the chance that an agent’s ability to edit a file is mistaken for permission to certify the workflow.
Why a status field is not completion evidence
A status is mutable state. Someone or something can write done into a queue file, but that string does not show that the unit produced the artifact it was supposed to produce, that the artifact belongs to the current cycle, or that the transition happened through the authorized path. AutoResearch addresses this by keeping an engine-written mirror of the queue and an append-only chain of terminal events.
The mirror is an independent comparison point. When the engine reads the live queue, it compares the sequence number, unit set, unit states, cycle decisions, and protected skip records with the last queue it wrote.