Designing Automation That Evolves: The Rise of Software-Defined Workcells
Lab automation is often positioned as a way to reduce friction by standardizing execution, increasing throughput, and improving consistency. When workflows are stable, that promise holds. The challenge is that most laboratories don’t stay stable for long.
Projects shift. Assays evolve. New modalities emerge. Regulatory expectations change. Even within the same program, protocols are refined as teams learn. Science moves quickly and automation must move at the same pace.
Application-specific systems are typically designed around a defined “golden” workflow. An NGS preparation cell optimized for a particular chemistry. An ELISA workcell built around a fixed liquid handler configuration. Scheduling logic and physical layout tuned for one narrow execution path.This approach can deliver rapid deployment and short-term efficiency; yet it assumes stability.
When requirements change, adaptation becomes complex. Scripts must be rewritten, layouts redesigned, validation repeated. Incremental scientific changes translate into disproportionate automation effort.
The cost of that rigidity isn’t just financial. It’s lost momentum: delayed experiments, precious sample loss, constrained iteration and scientists working around systems rather than with them. Workarounds that introduce technical debt and fragment data integrity. In fast-moving R&D environments, those delays directly impact discovery timelines.
Automation should not become the bottleneck in scientific progress.
What “Software-Defined” Means in a Laboratory
The term software-defined is frequently used in discussions about modern lab automation, but it is often misunderstood. It is sometimes reduced to the presence of APIs, scheduling tools, or the ability to trigger instruments programmatically.
Those capabilities matter, but they do not define the architecture.
In a laboratory context, software-defined automation is about where control and logic reside. Rather than being embedded in a fixed hardware layout or tied to a single application, execution logic lives in software, independent of specific instruments or physical configurations.
This architectural separation is critical. It allows workflows to change without rebuilding the system. Instruments become modular components rather than permanent dependencies. Decision points can be introduced or refined in software as scientific priorities evolve.
At Automata, this principle underpins the LINQ platform. LINQ software orchestrates workflows at the system level, while LINQ hardware provides a modular execution layer beneath it. Orchestration, execution, and instrumentation are decoupled, and laboratories are not locked into a single layout, vendor, or use case.
This distinction separates orchestration from traditional scripting. Instead of embedding logic within individual devices, LINQ coordinates actions across instruments, data systems, and workflows from a central control layer. That separation reduces technical debt and enables change without rewriting the system from the ground up.
Importantly, software-defined automation does not eliminate complexity, it puts control where it can adapt. Most workflow changes can be handled through simple configuration, while more advanced needs can be addressed through deeper software integrations when required.
Data also becomes a first-class element of the architecture. Execution state, parameters, and outcomes are structured at the orchestration layer, enabling integration with LIMS, ELN, analytics platforms, and AI models without retrofitting data pathways later.
This is what makes the difference between automation designed for a single predefined workflow and automation designed as adaptable infrastructure.
Reconfigurable Workcells vs Application-Specific Systems
For well-defined, stable processes, application-specific automation can be effective.. Systems optimized around a single workflow are often straightforward to deploy and validate, and are effective at delivering repeatable results.
The limitation emerges over time.
When protocols evolve, throughput requirements shift, or new experimental questions arise, tightly coupled systems can become difficult to adapt. What initially delivered speed-to-value can turn into friction: requiring script rewrites, layout redesigns, repeated validation, and growing operational complexity.
The core difference lies in design intent:
- Application-specific systems optimize for speed of deployment.
- Reconfigurable workcells enable rapid evolution.
- Reconfigurable systems assume change.
- Orchestration is separated from execution.
- Hardware is modular.
Workflows can be adjusted without rebuilding the entire platform. New instruments can be introduced, capacity can scale, and logic can evolve while preserving prior investment.
This adaptability becomes especially critical as laboratories integrate more advanced computational and AI-driven workflows into their operations.
Why AI makes Reconfigurability Non-negotiable
AI-driven science assumes change.
Unlike traditional automation, where workflows are defined once and executed repeatedly, AI-enabled experimentation is inherently adaptive.. Models evolve as data accumulates, hypotheses evolve, and experimental parameters shift in response to results.. In active learning and closed-loop experimentation, each run informs the next, turning the workflow itself into part of the experiment.
This fundamentally changes the requirements placed on automation infrastructure.
Static systems struggle to support workflows that must adapt in real time. AI does not simply consume data, it influences what happens next. It reprioritizes conditions, refines execution parameters, and generates new experimental directions.
In this context, reconfigurability becomes essential.
Software-defined, reconfigurable workcells allow workflows to evolve as models learn. Parameters can be adjusted between runs. New steps can be introduced without rebuilding the system. Automation shifts from being a rigid execution engine to becoming an adaptive component of discovery.
As AI increasingly shapes experimental design, automation must keep pace, not just by running faster, but by changing intelligently.
A Real-World Example: AI-Enabled Cell Culture
The Automata–CellVoyant collaboration illustrates this shift in practice.
Cell culture in advanced therapeutic development presents variability, sensitivity, and control challenges. Traditional workflows rely on frequent manual intervention, destructive sampling, and iterative protocol adjustments to maintain quality and optimize conditions. The integrated system developed between Automata and CellVoyant is a practical example of supporting adaptive, closed-loop experimentation. CellVoyant’s AI models analyze live cell behavior, predict optimal conditions, and feed those insights back into the automation layer in real time.
LINQ provides the reconfigurable execution foundation that enables this dynamic control. Workflow logic is orchestrated within software, while hardware remains modular. Experimental conditions, timing, and parameters can be adjusted without redesigning the system.
This architecture enables extended, continuous operation while reducing manual intervention and preserving data integrity.
According to publicly available case materials, the combined solution:
- Reduces routine manual handling
- Preserves sample integrity through non-destructive monitoring
- Shortens decision cycles by responding to live data
- Improves reproducibility by reducing human variability
- Enables scalable data generation to strengthen AI model performance
This collaboration shows what automation infrastructure must look like to support AI-driven science at scale. Closed-loop experimentation becomes practical when orchestration and execution are decoupled.
Designing Automation for the Next Five Years
As laboratories look ahead, expectations of automation are shifting.
Throughput and consistency are no longer differentiators – they are baseline requirements. The real question is whether automation systems will remain relevant as scientific priorities evolve.
Research environments now operate across shifting modalities, emerging computational methods, and evolving regulatory landscapes.
Automation is no longer viewed as a one-time project, but as infrastructure, a persistent layer that supports experimentation across programs and over time.
Designing for this future requires architectural clarity: orchestration separated from execution, software decoupled from physical layout, and modular hardware, Systems must support safe, predictable change.
Over the next five years, the laboratories that move fastest will not necessarily be those with the most automation, but those with automation designed to evolve.
At Automata, we design systems with this reality in mind, enabling laboratories to build automation infrastructure that evolves alongside their science.
If you are evaluating how to future-proof your automation strategy, we would welcome the opportunity to explore what that could look like in practice.
FAQ
A lab workcell is a group of instruments, robotics, and software that work together to perform a specific laboratory workflow. In automation environments, workcells often include liquid handlers, incubators, plate readers, and robotic transport systems. Modern workcells are orchestrated through software platforms that manage scheduling, data flow, and execution logic across the entire system.
Traditional automation systems are typically designed around a single predefined workflow. Reconfigurable workcells are built with modular hardware and software orchestration, allowing laboratories to modify workflows, introduce new instruments, or scale capacity without rebuilding the entire system. This flexibility allows automation to evolve alongside scientific requirements rather than being locked into a fixed application.
Software-defined automation refers to an architecture where workflow logic and orchestration are managed in software rather than embedded directly in hardware or individual instruments. By separating control logic from the physical layout of the system, laboratories can adapt workflows, integrate new devices, and update decision points without redesigning the automation platform itself.
AI-driven experimentation often involves iterative learning, where models analyse results and adjust experimental conditions in response. This requires an automation platform to adapt workflows dynamically. Reconfigurable, software-defined automation platforms allow laboratories to modify parameters, introduce new steps, and update execution logic without rebuilding the system.
Software-defined laboratories separate orchestration from physical execution, allowing workflows to be modified or expanded without changing the underlying automation infrastructure. This architecture supports scaling across multiple workflows, instruments, and research programmes while maintaining data consistency and operational control.
Automation infrastructure provides a flexible foundation for laboratory operations over time. Instead of deploying isolated systems for individual projects, infrastructure-based automation platforms allow laboratories to reuse hardware, evolve workflows, and integrate new computational tools as research needs change.
Closed-loop experimentation refers to workflows where data generated during experiments is analysed in real time and used to automatically adjust subsequent experimental conditions. This approach is often enabled by AI models working together with automation systems, allowing laboratories to run iterative experiments that continuously improve outcomes.
