AlphaGenome 2: Better hypotheses, not a clinical verdict

Google DeepMind announced AlphaGenome 2 on November 11, 2026, targeting the effects of DNA variants in particular cell types and states. This is a research advance, not a clinical verdict.

The useful question is what a laboratory should do differently tomorrow. Our assessment: treat the model as a way to allocate experimental attention. A ranked hypothesis can be valuable even before it becomes a verified mechanism, provided the ranking improves the next experiment and the team does not mistake its confidence for evidence gathered from patients.

Three questions that should stay separate

A useful starting distinction comes from the US National Human Genome Research Institute: genome-wide association studies identify statistical associations, not causation. Finding an associated region, establishing a molecular mechanism and showing that an intervention benefits people are different assignments.

Consider a hypothetical research team with several candidate variants. A computational score might justify testing one first. It cannot, on that basis alone, establish that the variant causes a patient's symptoms, that changing a nearby gene will reverse them, or that such a change would be safe. Each step introduces a new question that needs its own evidence. Collapsing these steps would turn an experiment-planning tool into an unsupported medical claim.

This distinction also changes how success should be reported. “We selected a candidate that survived an independent test” is more informative than “we obtained a persuasive visualization.” The former measures a decision; the latter measures a presentation.

Context should become part of the hypothesis

The Human Cell Atlas is building reference maps of human cells. Our editorial inference is that context-aware prediction makes the choice of biological context an explicit research decision rather than a background label.

A good hypothesis should therefore specify the variant, the proposed target, the cell context and the expected direction of change. Teams should also state what result would contradict it. Without that last requirement, it becomes too easy to reinterpret every experimental outcome as support.

For example, in a hypothetical inflammation project, researchers could compare a candidate effect across a relevant immune-cell preparation and an unrelated control preparation. They should decide those comparisons before inspecting the results. If they search enough settings after the fact, a striking-looking match may be easier to find than a useful mechanism. That is a design risk, not a demonstrated defect in this particular model.

A known mechanism is a checkpoint, not the finish line

A 2024 Nature study linked a disease-associated regulatory region to ETS2-driven macrophage inflammation. Such established mechanisms provide useful checkpoints when evaluating computational tools. But a retrospective checkpoint and a prospective discovery answer different questions.

Our proposed evaluation would have two separate tracks. First, check whether a tool recovers well-characterized examples under documented conditions. Second, lock predictions for a new set of candidates before the experimental team measures them. Keep the second set separate from threshold selection and troubleshooting. A system that explains yesterday's examples attractively may still need substantial work before it improves tomorrow's choices.

Negative results matter here. If a candidate fails, preserve the prediction, protocol and outcome rather than quietly replacing it in a showcase. A research workflow should become more informative with failure, not merely more selective in what it displays.

Measure the decision, not just the score

For a first pilot, we would ask a laboratory to set a fixed experimental budget and compare candidate-selection methods. The relevant outcome is how many useful, independently supported findings emerge per unit of effort. Include investigator time, sample preparation and unsuccessful follow-up, not just the time required to produce a prediction.

A pilot should publish its denominator: how many candidates were considered, how many were selected, how many were tested and how many passed the agreed criterion. Report uncertain and untested cases separately. Otherwise a small collection of successes can hide a workflow that fails to improve on a simple baseline.

The comparison also needs to reflect the laboratory's real choices. An expensive validation assay may favor a shorter, more conservative shortlist; a cheaper screen may benefit from broader exploration. There is no reason to assume that one cutoff optimizes both. The decision threshold should follow the research objective, not the attractiveness of a single headline metric.

Reproducibility and access are part of the product

The official API repository describes research access and explicitly excludes clinical decision-making. Teams evaluating the service should review the applicable terms and the handling of their proposed inputs before building it into a workflow.

Our minimum reproducibility record would include the model version, input coordinates and genome reference, chosen context, scoring method, comparison baseline and date of execution. Store what was actually submitted and returned, subject to appropriate data controls. A future rerun should be an auditable comparison, not an attempt to reconstruct a screenshot.

For organizations considering adoption, a sensible commercial question is whether the system reduces the cost of reaching a robust experimental decision. That is more actionable than assuming that impressive predictions automatically translate into valuable drug targets. Access arrangements, repeatability and integration effort belong in the same assessment as predictive performance.

Make uncertainty operational

A score becomes more useful when a team knows what action follows from it. We would define three working categories before a pilot: candidates ready for a specified experiment, candidates needing additional evidence, and candidates the current workflow cannot assess. These are proposed management categories, not capabilities claimed for the model. Keeping the third category visible prevents “not assessed” from quietly becoming “no effect.”

Responsibility should also be explicit. A computational researcher can record inputs and explain the comparison; an experimental researcher can judge whether the proposed preparation matches the biological question. Neither role should inherit an automatic clinical interpretation from software. A clear handoff document makes disagreement easier to investigate and reduces the temptation to treat the output as self-explanatory.

Finally, a pilot needs a stopping rule. Before spending more, define the evidence that would justify expansion, revision or abandonment. If results repeatedly fail the agreed criterion, a smaller or redesigned workflow may be better than adding more automated predictions. This is not an argument against adopting new tools. It is a way to distinguish adoption that improves research from adoption that merely increases the volume of plausible-looking output.

What would change our view

We would look for prospective external evaluations, transparent unsuccessful cases and evidence that laboratories make better choices at a fixed budget. Strong results would justify expanding research use; uneven results would help identify where conventional approaches remain preferable.

The promise of AlphaGenome 2 is best understood as better questions put to experiments. The dividing line remains firm: a predicted variant effect is a hypothesis about molecular behavior, not proof of clinical benefit and not a diagnosis. Keeping that boundary visible is how a promising tool can earn trust rather than borrow it.