AI in biology depends on reading your own instrument's data

Whether a lab can automate lab data analysis with an AI agent comes down to something narrower than which model won which benchmark: whether it reads the data a lab's own instrument produced, in the format that instrument actually writes. AI in biological research this year spans several distinct problems: predicting how a protein folds directly from its amino acid sequence, scoring a redesigned protein sequence against measured stability before anyone expresses it, reading a microscopy image and finding the particles or regions a person would otherwise draw by hand, and writing analysis code a lab used to wait on a software engineer for.

Most of that work started as a paper and a benchmark run on a public dataset.

What is already real

Predicting a protein's three-dimensional structure from its sequence is reliable enough now that a scientist can score a proposed mutation against the predicted structure before waiting on a crystal structure to confirm it. Microscopy has moved the same way: models trained to segment cells or count particles in a field of view now do work that used to take a person clicking round every object by hand. Generative models can score a redesigned protein sequence against experimentally measured stability data, so a variant is ranked before it is ever made. And a scientist who can describe an analysis in plain language can get working code for it in a field well outside their own training, without hiring a software engineer to write it.

Each of these already runs, on a public dataset, inside a paper somewhere.

The gap is the data, not the model

The step no benchmark tests is the one that decides whether a result reaches a working lab: whether the model can read the file an instrument actually wrote, with the plate layout, the column headers and the operator's own conventions already in it. Most instrument software keeps the final reading and drops everything that produced it: the run parameters, an adjustment made mid-run, the steps a person took after a first attempt failed. A model trained on a curated public dataset has not been shown any of that, and a published result and a usable tool stay two different things until something bridges the gap.

That is a data problem before it is a modelling problem, and it sits outside every benchmark score a paper reports, because a benchmark is scored on data that was already prepared to be scored on.

What it looks like once a lab's own data is read directly

Elnora runs these kinds of methods in one place, already connected to a lab's own data. Structure prediction, protein complex modelling and protein-ligand prediction sit alongside sixteen tools for microscopy work, from particle counting and region measurement to colocalisation and scale calibration, callable in the same conversation that reads a plate export. Behind them, 254 written scientific skills spanning genomics, chemistry, statistics and lab automation cover the method behind each answer, running to 268,000 words of written procedure, so a result traces back to a written method a scientist can open and check.

The instrument connection is what actually closes the gap a benchmark cannot close. Elnora writes the run file each connected liquid handler, plate reader, imager and cytometer accepts, then reads the output back, with the run rehearsed in simulation and approved by a scientist before anything executes. The run parameters, the plate layout and the result stay together, so an analysis has context a public benchmark does not carry: which well was which, what the instrument was actually asked to do, and what happened when it ran.

The potential the field keeps describing is real, and most of it is published already. Elnora's answer to whether it reaches a working lab is the much plainer question of whether the tool reads the file that lab actually produced.