You ask. It runs the lab.
“Run the SMC assay on these four plates.”
It checks where the plates are, confirms with you, submits the workflow you already validated, and tells you when each one is done.
“The sealer stopped mid-run. Find out why and get it going again.”
It reads the fault off the instrument, tells you what the run is waiting on, and helps you clear it with direct control of the hardware. Everything it touches is recorded.
What it does
Four jobs, not one. Writing the automation, running it, fixing it, and driving an instrument when that is all you need.
Build workflows and liquid handler methods
Describe the assay or upload a PDF. It writes the workflow, the methods and the liquid handling that goes with them: the transfers, the volumes, the tip changes. You review it as code before anything runs.
Run what you validated
Your approved workflows run exactly as approved. They are hardcoded Orca workflows to ensure your assays are completed the same way every time.
Recover a stopped run
When an instrument faults, it finds out why, tells you what the run is waiting on, and gets it moving again. Most schedulers stop here and wait for someone to notice.
Operate instruments directly
Shake a plate, move it, read it, home an arm. When the job is one command rather than a workflow, it is one command.
What it already knows
An assistant cannot run a lab it has to guess about. Orca AI reads the same record the scheduler plans from.
Labware definitions
Every plate, tip rack and trough it can place: geometry, well count, and where each one is allowed to sit.
Volume tracking
How much is in every well, folded from every aspirate and dispense that actually happened.
Tip tracking
Which tips a rack still holds, and what each channel on the head is carrying right now.
Every operation
Each device call in order, with what it did and what came back. An operator command leaves the same trail a workflow does.
Failures
What stopped, where it stopped, and what state the instrument was left in when it did.
Recovery state
One list of everything blocking the run, what clears each item, and what still remains after you clear one.
On the rails, and off them
Guardrails that stop an assistant fixing anything are guardrails you will turn off. These are built the other way round.
The run stays on the rails
Your workflow is Python you wrote and reviewed. It runs exactly as written, every time. The assistant submits it; it does not rewrite it on the way past.
Agency everywhere else
Outside the workflow it acts on its own: send a command to an instrument, move a plate, clear a fault, correct what the record got wrong. That is how a stopped run gets going again instead of waiting for someone to notice.