The slow part of lab automation is programming each new method

The slow part of lab automation is getting the hardware to run each new method, and planning the experiment has become the quick part. An AI agent can propose the next experiment in minutes, while the robot that has to carry it out runs the procedures somebody has already programmed into it, so the useful answer to how to program a liquid handler for a new method is to have the agent write that program too, from the scientist's own description. Take a group whose liquid handler sets up its ELISA plates each week, and a scientist who now wants a dose-response series of four compounds, in triplicate, on the same deck.

Elnora, the AI agent for lab work, plans a lab's experiments, writes and optimises its protocols, analyses the results and remembers what the lab has decided. For this scientist it writes the dose-response workflow in the code library the lab's automation platform already uses, runs the whole workflow in simulation, prints the deck it expects for the operator to confirm, and files the method beside the fitted curves so the next request starts from it.

An automated lab runs the methods it was set up for

A liquid handler and the software around it are configured for a set of procedures: the labware definitions, the deck positions, the tip types and the liquid classes, which are the settings for how fast and how deep each kind of liquid is drawn up and dispensed. A new question in the lab often calls for a procedure nobody has configured yet, and adding it means somebody writes the code that drives the hardware and tests it before samples go on the deck.

In most labs that somebody is an automation engineer, or the one scientist who learned the instrument's software, so new methods wait in a queue for that person. Much of what they know is unwritten: which plate type sits flat in which carrier, which aspiration height leaves a cell pellet undisturbed, why one deck position is kept empty. When they move to another job the scripts stay behind and the reasons leave with them.

The planning side meanwhile keeps speeding up. An agent can suggest the next round of conditions as soon as the last plate is read, so a lab with robots and a planning agent still waits at the step between the plan and the hardware.

A new method starts from the goal and from what the lab already has

A lab gets past that step by treating the building of a method as part of the experiment. The scientist states what they want measured, and the agent works out what the lab already has for it: the connected instruments, the labware already defined and the methods that already run. It then writes the missing part, tests it in simulation, runs it on the hardware once a person has confirmed the setup, and keeps what worked for the next request.

That moves the scientist's job from programming the robot to saying what the experiment is for, which is the part they trained for. It also changes what the lab keeps. A folder of scripts written for one deck layout is hard to reuse on the next instrument, while a method filed with its protocol, its deck layout and its results can be found and adapted by whoever asks for something similar.

Elnora writes the dose-response run from the scientist's request

The scientist asks for an eight-point, three-fold dilution series of four compounds, in triplicate, added to the cells already seeded, on the liquid handler the ELISA runs on. Elnora reaches the instrument through the automation platform that already controls it, reads what is configured there, and drafts the protocol to the group's named template. A critic agent reviews the design and ranks each problem it raises with a proposed fix, here the vehicle-control wells missing from the second plate.

Elnora then writes the workflow in the SDK, the software kit the lab's instruments are driven through, so the lab's engineers can read the code and own it. It runs the workflow from start to finish in simulation, and the run stops to show the deck layout it expects, one position at a time, and goes on once the operator confirms the bench matches it. The arm carries out the run and the phases, the durations and the logs come back, so the scientist can read what ran, in what order and for how long, first in simulation and again on the hardware.

Elnora also writes the run file for the plate reader and reads its output back, matches each reading to its well on the plate map, and fits one dose-response curve per compound. The protocol, the workflow, the deck layout and the fitted curves land in the shared Knowledge Base, in the project's folder, on the day the plate is read.

The second request starts from the first

A week later a colleague asks for the same dilution series on a new set of compounds. Elnora finds the method in the Knowledge Base with the deck layout that worked and the run log beside it, changes the compounds and the plate map, and the run goes through simulation and deck confirmation again on the way to the instrument. A scientist who runs the series often can save it as a skill of their own, and Elnora carries their skills and named protocol templates into each new conversation.

The code Elnora writes runs in an isolated workspace for each task, with network access limited to an approved list of scientific hosts, and the credential for the automation platform is added on the server side, so it stays out of the text the model reads. When the lab connects its next instrument, the method that worked on the first machine is where the work on the second one starts.

The scientists choose what to measure, confirm each deck and own the results, and Elnora writes, simulates, runs and records each new method their questions call for.