A self-driving lab needs a brain before it needs hands.
Imagine a robotic system finishing an assay. A scientist then exports the results, matches them to a sample list, checks a spreadsheet, prepares a report and emails someone about the next experiment.
The equipment is automated. The work between the equipment and the next decision is not.
That is the problem Scispot addresses: connecting scientific data, workflow context and controlled actions so people do not have to coordinate every digital handoff. Scispot brings instrument data, laboratory records, analysis and AI tools into a connected operating layer.
Today, Scispot supports L3 orchestration: governed scientific and digital workflows with people overseeing key decisions. Full L4 closed-loop laboratory execution is not a current Scispot capability.
Our vision is to extend that same foundation into broader physical execution as hardware interfaces, automation integrations and operating controls mature.
The goal is not simply to move a plate faster. It is to move reliably from scientific intent → result → decision → next action.
What is a self-driving lab?
A self-driving laboratory combines automated experimentation with computational decision-making. In a closed-loop system, experimental results inform the choice of subsequent experiments. Scientists establish the scientific objective and the limits within which the system operates.
That is a useful destination. It is not an all-or-nothing starting point.
At Scispot, we approach autonomy one workstream at a time. A workstream is a defined sequence of work, such as processing an assay run or preparing a reviewed analytical report.
The first goal is to connect what happened, what it means and what should happen next. Physical robotics can then become part of that coordinated process where the required interfaces and controls exist.
Digital autonomy is not a substitute for physical automation. It is part of the foundation that makes physical automation useful across a complete workflow.
Five levels of laboratory autonomy
We use the following framework to describe a workstream's progression. These are Scispot's working definitions, not an industry certification.
A lab can have an L1 workflow and an L3 workflow at the same time. Connecting an instrument does not automatically make its entire workflow autonomous.
The useful question is: Which decisions and handoffs can this workstream reliably handle, and which still need a person?
Integration connects. Automation executes. Orchestration coordinates.
Consider an assay result moving through a lab.
Integration makes the result available to another system.
Automation applies a defined operation, such as a calculation or a quality-control check.
Orchestration connects those steps to the experiment, the review process and the next authorized action.
For example, a configured workflow can associate results with samples, apply QC, present exceptions for review and prepare the next digital task after approval. Scispot's data-processing and workflow tools support these kinds of connected steps.
An orchestration design must also account for what happens when the expected result does not arrive. Is the workflow waiting for data, waiting for review or blocked by an unresolved issue?
That is the difference between automating a task and coordinating a process.
How Scispot provides the digital brain
A digital brain is more than a chatbot attached to a database. It combines scientific context, workflow logic, authorized actions and a record of what happened.
Scispot enables that through several connected capabilities.
GLUE connects the lab's data sources
Scispot GLUE connects supported instruments, laboratory systems, databases and file sources. It supports data ingestion and transformation, including mapping identifiers, aligning formats and linking outputs to laboratory context.
This is the first step toward removing repeated file transfers and spreadsheet cleanup. Connection scope depends on the source, its available interface and the workflow being implemented.
Reading an instrument's results and controlling the instrument are different capabilities. A data connection should never be presented as proof of physical control.
Labsheets and Labspaces give data its scientific meaning
A measurement becomes more useful when its sample, experiment and protocol are known.
Labsheets provide structured laboratory records. Labspaces provide experiment and protocol context. Together, they support a connected view of the work rather than a collection of unrelated files.
The orchestration design can link the sample identity, method version, run and reviewed result. Those relationships help people and software determine which records belong together and which workflow step comes next.
An uploaded file is an input. A result linked to its scientific context is usable workflow information.
Smart Actions automate the work after data arrives
Smart Actions support configurable processing of instrument outputs. Depending on the workflow, this can include parsing files, mapping wells to samples, applying calculations and QC rules, and preparing structured results for review and write-back.
The important distinction is between processing data and accepting its consequences. In the documented Smart Actions workflow, users preview and approve proposed changes before they are committed.
That keeps automation connected to scientific review instead of treating generated output as automatically accepted evidence.
Scibot, AI agents and MCP connect questions to permitted actions
Scibot supports natural-language interaction with laboratory data, including search, summaries and analysis assistance. Scispot's MCP server gives compatible AI tools access to supported functions such as searching records, updating Labsheets and working with experiment entries.
MCP stands for Model Context Protocol. It provides a standard way for an AI application to interact with exposed tools and resources. It does not, by itself, provide a laboratory scheduler or robot controller.
For example, an assistant could help a scientist find flagged results and draft an experiment summary. Any follow-on action still depends on available tools, access rights and the workflow's review process.
Jazz brings the workflow into one usable interface
Scientists should not have to navigate a separate application for every handoff.
Jazz supports workflow-specific applications on Scispot's connected data and processes. A team can use an interface focused on receiving, reviewing results, resolving exceptions or producing reports, while working with the underlying Scispot records.
Its role in autonomy is practical: make the relevant information, required decision and next permitted action clear.
Governance keeps decisions connected to evidence
Scispot supports controls such as role-based access, audit history, electronic signatures and linked approvals. Trust Vault provides a workspace for quality-related records, evidence and system changes.
These capabilities help teams preserve the relationship between a result and the process used to accept it. They do not remove the need to assess and test a configured workflow for its intended use.
More autonomy should mean less manual coordination - not less accountability.
Does L3 orchestration replace laboratory scheduling software?
Not automatically. Scientific workflow orchestration and physical resource scheduling are related, but they are not the same job.
Scispot's L3 positioning concerns connected scientific records, digital processing, workflow progression and governed decisions. It is not a blanket claim that Scispot independently schedules every robot and instrument across the lab.
A multi-instrument protocol may also require software that manages shared device access, timing constraints, resource reservations and physical execution. Commercial automation platforms provide capabilities in this area. For example, HighRes distinguishes Cellario OS, its broader orchestration platform, from Cellario Scheduler, its automation execution and scheduling engine. Thermo Scientific Momentum and Biosero Green Button Go also offer workflow and scheduling capabilities.
Some of these platforms overlap with Scispot at the workflow layer. The right design therefore assigns clear responsibilities rather than assuming every product occupies a separate box.
For a protocol spanning days, weeks or months, the project should establish:
- Scientific workflow ownership: sample and experiment records, required inputs, analysis and approvals.
- Physical execution ownership: device availability, timing, reservations, method execution and hardware recovery.
- The interface between them: permitted requests, returned status, result identifiers and behavior when communication fails.
A workflow marked "ready" is not the same as a confirmed instrument reservation. A submitted run request is not evidence that the run completed.
A lab investing in Scispot may still need Cellario or another automation platform. That depends on its hardware, methods and existing infrastructure. Scispot should not be assumed to replace that layer, and compatibility with any named platform must be assessed for the specific deployment.
Two paths toward an autonomous lab
The same orchestration approach can support a new lab and an established one. The starting point differs.
The scenarios below are illustrative workflow designs, not descriptions of named customer deployments. Their execution depends on configured workflows and verified interfaces.
Scenario 1: Build an automation-native assay lab
Consider a new laboratory designing a connected experimental cycle:
Design → Make → Test → Analyze → Decide → Next experiment
The first task is to define how information will move through that cycle.
An experiment request establishes the objective, sample set and approved protocol. Samples and materials are recorded with the relationships needed to interpret the resulting data.
Preparation and testing take place through operators or the selected automation environment. Scispot's role is to keep the scientific records and digital handoffs connected - not to imply that creating an experiment record moves physical samples.
As instrument results become available through supported connections, configured processing maps them to the relevant samples and prepares QC outputs for review. Analysis and summaries then support a scientist's decision about the next experiment.
For an L3 implementation, the scientist remains responsible for the scientific decision. Scispot can coordinate the associated review and authorized digital follow-up through configured workflows.
The design principle is simple: build the sample identities, protocol context, review steps and interfaces before trying to automate the entire experimental cycle.
That creates a clearer path to future physical execution without claiming it is already a complete closed loop.
Scenario 2: Modernize an existing regulated analytical lab
Now consider a laboratory with an established LIMS, an ELN, instrument software and defined quality procedures.
Its first objective may be to connect a workflow like this:
Work request → Instrument result → QC → Review → Report → Approved next action
Scispot can support an instrument-to-report workflow by connecting source data, scientific records, calculations and reporting steps. Existing laboratory systems can remain part of the architecture rather than being replaced as a condition of adoption.
In this illustrative design, an incoming result is associated with the relevant sample and method. Configured QC identifies an exception. The reviewer sees the source information, the reason for the flag and the required decision.
If a rerun is approved, the workflow can prepare the follow-up record or request. Physical execution remains with the authorized operator or qualified automation environment. The original result is retained in the record, and the new result follows the required review process.
The goal is not to let an agent bypass quality procedures. It is to reduce the manual work needed to follow them consistently.
Add orchestration above the systems the lab already uses. Expand autonomy where the workflow and evidence support it.
What happens when something goes wrong?
An autonomous-lab design is incomplete without an exception path.
Take a simple example: a result arrives without a usable sample identifier. The next step should not be to guess which sample produced it.
A proposed exception workflow would hold the affected result, preserve the source, ask the appropriate person to resolve the identifier and continue only after that resolution is recorded.
The same principle applies to a failed QC check or a run whose completion is uncertain. Requested, started and completed are different states. A missing response should not silently become success.
Scispot's workflow-specific applications can include review, approval and exception steps.[^jazz] The exact behavior must be configured and tested. Hardware stop logic and physical recovery remain the responsibility of the qualified control environment unless a specific integration establishes otherwise.
The next step: connecting the brain to more physical actions
Our direction is to extend orchestration from digital work into broader, verified physical execution.
That means connecting an authorized decision to an appropriate automation interface, then bringing status and results back into the scientific workflow.
Approved intent → Supported execution interface → Physical action → Confirmed status and results → Reviewed next decision
Anthropic's Model Hardware Standard (MHS) is one emerging approach. In its August 2026 research-preview announcement, Anthropic described an interface for AI agents to operate programmable hardware. It identified MCP, command-line interfaces and APIs as access mechanisms, and described partner work ahead of an open-source release.[^mhs]
For Scispot, MHS is a possible future integration route, alongside vendor APIs, software development kits and automation platforms. It is not a claim of current Scispot MHS support.
A common hardware interface would not, on its own, prove that a complete lab workflow is reliable. Device support, execution feedback, method suitability, approval rules and exception handling still need to be established.
Scispot supports L3 orchestration today. Broader L4 closed-loop execution remains the direction we are building toward - not a capability unlocked merely by a standard becoming available.
How to start: choose one workstream and prove it
The practical starting point is not a lab-wide promise. It is one process with a clear beginning, a defined outcome and a costly manual handoff.
Map its current flow. Identify the records, systems and interfaces involved. Decide which steps can run through configured logic and which need scientific review.
Then test both the normal path and an exception. Demonstrate how the workflow knows what happened and how it reaches its next authorized step.
Measure outcomes such as time from instrument result to reviewed report, manual handoffs per run and time spent resolving exceptions. Establish a baseline before claiming a gain.
Start with one reliable workstream. Reuse the proven pattern where it fits. Expand physical execution only where the interface and operating controls support it.
The self-driving lab starts with connected work
Our thesis is not that laboratories should delay robotics. It is that digital and physical automation should share a coherent scientific workflow.
Scispot's role is to connect the context, coordinate the digital work and support the decisions around that workflow. The next stage extends that foundation into more physical actions where the necessary interfaces and controls are proven.
The path is connected data → automated tasks → governed orchestration → progressively closed loops.
A self-driving lab needs a brain before it needs hands.
Start with Scispot by mapping one workstream: its data, decisions, approvals and path to the next level of autonomy.
