Parallel Experiment Queues: Scheduling for Higher Information Gain
With multiple instruments, the loop can schedule parallel experiments and collect more information per unit time. Here is how it coordinates instrument queues.
On Thursday afternoon, a run ends. The plate reader stops, the export file reaches a shared folder, and the lab quiets down. Work resumes Monday, not because instruments are booked or reagents are delayed, but because no one reserved Friday to inspect the results, determine what changed, and draft the next protocol.
That four-day pause is not a scheduling anomaly. It is the rate-limiting step in discovery across nearly every iterative research program we have discussed with.
Researchers usually define experiment cycle time by the run itself: assay duration, incubation hours, or the moment an instrument completes. That duration has a genuine lower bound. A 72-hour cell proliferation assay cannot finish in 12 hours.
Cycle time spans the start of one experiment to the start of the next, not just the run itself. Most of that interval is decision time.
For a typical four-person group doing iterative optimization, the pattern is roughly this: the experiment takes one to three days, then analysis and selection of the next run require three to five more days. That latter step consumes the time. Its limit is human bandwidth, not scientific complexity.
Interpreting results and choosing the next run demands substantial cognition. A lead researcher must reconstruct the experiment's context, compare it with earlier runs in the series, revise their mental map of the parameter space, and state the next hypothesis. This work does not fit reliably into a distracted ten-minute interval.
That load produces two bottlenecks. First, the work is postponed because it needs focused time, which is seldom available when results arrive. Second, completed analysis has limited throughput. One researcher can deeply handle two or three experiment series at once. Past that point, attention thins and next-run decisions deteriorate.
Even well-funded labs with strong instruments and capable teams therefore serialize their cycles around one decision point. Runs can proceed in parallel, but selecting the next run remains sequential, one series at a time, constrained by the person responsible for analysis.
Closing the experiment loop does not remove researchers. It automates the decision-support layer between "results are in" and "next experiment is queued."
Discovery Loop holds a probabilistic model of the parameter space under study. Each new result updates the model, reorders candidate experiments, and presents the researcher with the highest-ranked next run. The researcher reviews it, confirms or edits it, and queues the protocol. Analysis and protocol drafting that once consumed three to five days becomes an hour of confirmation.
The mechanism is a Bayesian update over a hypothesis tree, a structured map of possible parameter values and predicted outcomes. Every data point shifts the posterior and changes which experiments are expected to provide the most information. We cover the tree structure in a separate note. The practical effect is shorter cycles because the decision no longer waits for an unscheduled block of PI time.
A lab completing five cycles per month investigates a meaningfully different region of the search space from one completing fifteen. The gain is not simply speed. It is access to conditions the slower lab never reaches.
Optimization problems commonly contain a long tail of useful conditions that teams never test because their experiment budget runs out first. A conventional lab may spend 20 or 30 runs in the initially promising corner. A looped lab uses those same 20 or 30 runs on conditions selected continuously for information value, covering the space more deliberately.
The connection to active learning is direct. The central question is not only which model to use, but which examples to label next. In wet-lab work, the model is the researcher's changing hypothesis, while the labeling budget is the experiments the team can run. Better allocation changes the result.
Some researchers reject the premise that analysis is overhead. They point out that this interval is where intuition develops, surprising patterns surface, and hypotheses emerge beyond what the data states directly. Compressing it could remove the science that occurs between runs.
We take that objection seriously. Close examination of results can yield insight that a pure optimization loop misses. A researcher spending four hours on an anomalous confocal image gains understanding no automated system currently reproduces.
Our claim is narrower: analysis is not uniformly valuable. A large portion is clerical, including reformatting data, replotted views with unchanged parameters, locating the relevant prior run in a shared folder, and drafting a protocol that barely differs from one written two months ago. Discovery Loop automates that layer. Researchers retain the deep analysis that generates insight rather than incremental iteration.
We do not argue for a zero decision gap or for queuing every experiment without review. The insight-bearing portion of the gap is smaller than the total interval. Surrounding overhead can be compressed substantially while leaving that scientific work intact.
Discovery Loop closes a structural gap. Result processing and experiment planning are separate workflows without an automated handoff. An export file lands in an instrument folder and waits for someone to carry it into the next decision. That handoff is the joint we automate.
Once the loop closes, the constraint changes. The bottleneck becomes experiment throughput, meaning how many runs instruments can physically process per week, rather than decision throughput. This is tractable: it depends on equipment and team capacity, not one lead scientist's attention across three projects.
Labs in our early-access cohort say the main change is not necessarily more experiments per month, although some achieve that. They stop losing momentum between runs. The cycle no longer stalls at the decision point because the next decision is already taking shape when results arrive.