The wet-lab dry-lab feedback loop is the core operational rhythm of modern protein engineering. You generate candidates computationally, run them in the wet lab, take the results, update your model or ranking heuristic, generate the next round of candidates. Everyone agrees this cycle is important. There is much less agreement on how to actually run it well.
One question we come back to repeatedly: how fast does the cycle need to be? The instinct is "as fast as possible," but that is not obviously right. There are real tradeoffs in how you structure iteration frequency, and optimizing for speed alone can actually slow down the overall project.
The Scheduling Framing
Think of the feedback loop as a scheduling problem with two queues. The dry-lab queue processes computational design jobs: given assay data from round N, produce a ranked candidate list for round N+1. The wet-lab queue processes synthesis and screening jobs: given candidates from round N, produce quantitative activity data for the dry lab to consume.
The latency of each queue determines the total cycle time. In most labs we have worked with, the wet-lab queue is the longer one. Gene synthesis, protein expression, purification, and assay setup together commonly run 3-6 weeks per round, even in a well-equipped team. The computational job, once you have clean data, takes hours to days.
This asymmetry has a structural consequence: the bottleneck is almost never computation. It is almost always sample throughput and assay capacity. So when teams ask "how do we run the loop faster," the answer is rarely "speed up the computational step." It is usually "how do we design the wet-lab portion to feed cleaner data back faster."
Batch Size vs. Iteration Frequency
There is a genuine tradeoff between the number of variants you screen per round and how quickly you complete a round. Screen 500 variants and you get rich data but the round takes 8 weeks. Screen 40 variants and the round takes 3 weeks, but your data per round is sparser.
The right answer depends on where you are in the project. Early-stage campaigns, where you are trying to understand the sequence-function landscape in a poorly characterized region, benefit from larger batches because each additional data point teaches you something about the landscape topology. You are in exploration mode.
Later in a campaign, when you have identified promising regions of sequence space and want to refine around them, smaller batches with faster cycles often outperform larger infrequent rounds. You are in exploitation mode and you want to be updating your model on fresh data more frequently. The best round-3 candidate list looks nothing like round-1, and you want to be generating it based on round-2 data rather than on stale round-1 data extended by two more months of waiting.
We do not claim there is a universal optimal batch size. It depends on the protein family's fitness landscape geometry, your wet-lab throughput, and the total project timeline. What we do think is that teams should be explicit about which mode they are in, rather than defaulting to the same batch size throughout the campaign.
Data Quality vs. Data Volume
Speed is not the only thing that matters when structuring the feedback cycle. Data quality matters enormously. We have seen campaigns stall not because the cycle was slow but because the assay data being fed back to the computational step was noisy enough to obscure the signal.
A common failure mode: a team runs a high-throughput screening assay that produces a Z-factor of around 0.4, which is technically above the threshold for an acceptable assay but means that variants within 30-40% of each other are effectively indistinguishable by rank. When you feed that data to a computational model that is trying to learn which mutations are beneficial, you are training on noise. The model confidently learns the wrong things.
Better to run fewer variants with a cleaner assay, even if that means fewer data points per round. A rank-correlation coefficient of 0.75 on 40 variants is more useful than a rank-correlation coefficient of 0.35 on 400. The computational model can do more with the cleaner signal.
This is a place where we push back on the framing that "more data is always better." In the wet-dry loop context, the quality of the data as input to the computational step is what determines how much each round advances the campaign. Volume without quality can actually slow you down by misdirecting the next round's candidate generation.
Where the Handoff Actually Breaks
In practice, the most common place the feedback loop breaks is not at the data collection step or the computational step. It is at the handoff between them.
The wet lab produces a spreadsheet. That spreadsheet goes to someone who is responsible for processing it and feeding it into the design pipeline. That person is often juggling other responsibilities, the spreadsheet format is not quite what the pipeline expects, there is a missing normalization step, and the handoff takes two weeks instead of two days. By the time the computational team has a clean candidate list, the wet lab has already moved on to other work and needs to context-switch back.
This is a boring operational problem, not a scientific one, and it is responsible for a substantial fraction of the cycle latency in most protein engineering campaigns we have seen. Addressing it requires standardizing data formats between wet lab and dry lab before the campaign starts, not after the first round produces data in a format nobody expected.
When we onboard a new design campaign, one of the first things we do is agree on a data schema: what columns the assay output needs to have, how controls are labeled, what the activity metric units are, how replicates are handled. That agreement exists before any wet-lab work starts. It feels like administrative overhead, but it typically saves two or three weeks per round across a multi-round campaign.
Knowing When to Stop Iterating
There is a version of the feedback loop question that goes in the opposite direction: not "how fast can we iterate," but "when should we stop." Running additional rounds has a cost, both in time and in wet-lab resources. At some point, the expected improvement from another round falls below the cost of running it.
The signal that you are near that point is usually a plateau in the top-variant performance across rounds. If rounds 1 through 3 each produced a best-in-round that was meaningfully better than the previous round's best, and round 4's best is statistically indistinguishable from round 3's best, you are probably in diminishing returns territory for the current design strategy.
That does not always mean stopping. Sometimes it means switching from an exploitation strategy to a diversification step: deliberately sampling from a different region of sequence space to check whether there is a parallel peak you have not explored. But it does mean being deliberate rather than running another round simply because the pipeline is set up to run one.
The feedback loop is a tool. Like any tool, getting value from it requires knowing when it is the right one for the current problem and when you have extracted what it can give you.