Every laboratory automation vendor makes the same promise: connect your instruments, automate your workflows, increase throughput. And every laboratory that has attempted this at scale has discovered the same thing: it is much harder than anyone expected.
The difficulty is not technical in the way people assume. It is not that the protocols are incompatible or that the APIs are poorly documented, although both of those things are often true. The real difficulty is that orchestration is a reasoning problem, not an integration problem.
The integration illusion
Connecting an instrument to a computer is straightforward. Most modern instruments expose some combination of serial, USB, Ethernet, or GPIB interfaces. There are well-established protocols: SCPI for test equipment, Modbus for industrial devices, various vendor-specific APIs for specialized instruments. The mechanics of sending a command and receiving a response are well understood.
This leads to a natural assumption: if we can talk to each instrument individually, we can coordinate them collectively. We just need to write the right script.
This assumption is wrong. And it is wrong for a reason that becomes obvious only when you try to operate instruments together rather than individually.
Context is everything
Consider a simple measurement workflow. You want to measure the output voltage of a circuit under different load conditions. You have a power supply, an electronic load, and a multimeter.
The script approach says: set the power supply to 5V, set the load to 100mA, wait 500ms for settling, read the multimeter. Repeat for 200mA, 300mA, and so on.
This works perfectly until it does not. What happens when the multimeter returns an unexpected reading? Is it a measurement error? A probe connection issue? A device failure? A settling time that was too short for this particular load step? The script does not know because it has no understanding of what the measurement means. It only knows the sequence.
A human engineer would immediately recognize an anomalous reading because they understand the expected behavior of the circuit. They would check the probe, verify the power supply output, examine whether the load is actually drawing the expected current. They would reason about the measurement in context.
This is the orchestration problem. It is not about sending commands. It is about understanding what the commands mean, what the responses imply, and what to do when reality does not match expectation.
Why scripts fail
Scripts encode sequences. They do not encode understanding. A script can handle the happy path and a finite number of predetermined error conditions. But physical systems produce an infinite variety of unexpected situations, and the correct response to each one depends on context that the script does not have.
This is why laboratory automation projects consistently follow the same trajectory: initial success with simple workflows, followed by exponentially increasing complexity as edge cases accumulate, followed by abandonment when the maintenance burden exceeds the automation benefit.
The fundamental issue is that scripts are brittle. They break when conditions change. And in a laboratory, conditions always change.
What orchestration actually requires
Real orchestration requires several capabilities that scripts cannot provide:
- State awareness. The system must know the current state of every instrument and how that state relates to the overall workflow.
- Expectation modeling. The system must have expectations about what each measurement should produce, so it can recognize anomalies.
- Causal reasoning. When something unexpected happens, the system must be able to reason about possible causes and appropriate responses.
- Adaptive sequencing. The next step in a workflow should depend on the results of the previous step, not on a predetermined sequence.
- Safety awareness. The system must understand which actions are safe in the current state and which could cause damage.
These are not features you add to a script. They are fundamentally different capabilities that require a fundamentally different architecture.
The reasoning layer approach
Our approach to the orchestration problem is to treat it as what it actually is: a reasoning problem that requires intelligence, not just automation.
Instead of writing scripts that encode sequences, we build a system that understands instruments, their capabilities, their current state, and the relationships between them. When the system coordinates a workflow, it is not executing a predetermined sequence. It is making decisions at each step based on what it knows about the current state of the world.
This does not eliminate the need for instrument drivers or communication protocols. Those are still necessary. But they become the lowest layer of the system rather than the highest. Above them sits a reasoning layer that provides the context, expectations, and decision-making that scripts cannot.
This is harder to build than a script. Significantly harder. But it is the only approach we have found that does not collapse under the weight of real-world complexity.
The orchestration problem is not "how do we connect instruments?" It is "how do we give a system enough understanding of the physical world to coordinate instruments intelligently?"
That is a much harder question. But it is the right one.