LabMozart

An operating system for life-science labs

Reusable lab skills.
Across hardware.

LabMozart is building an operating system for life-science labs. It coordinates workflows across instruments, robots and people, with execution middleware to adapt and verify robot operations.

We develop lab application packages for specific workflows, helping hardware partners deliver lab solutions and laboratories plan deployment and ongoing operation.

Explore applications Watch simulation demos
Lab needs

Workflows & criteria

Hardware capabilities

Robots & instruments

LabMozart

Lab execution middleware

Compose skills Adapt execution Verify results

Workflow solutions

For specific lab workflows

Reusable assets

Future adaptation & deployment

Meet lab needs. Build capabilities for reuse.
02

The opportunity

Robotic capability
is not a lab workflow.

AI accelerates hypothesis generation and experimental planning. Testing those ideas still requires wet-lab work. Turning the capabilities of robots and instruments into reproducible workflows requires application development, hardware adaptation and quality validation.

Requirements can be specified
Objects, operating conditions and QC criteria can be defined for development and validation.
Workflows still need engineering
Existing instruments may lack usable interfaces. Sample transfer, physical interaction and dependencies between steps still need integration.
Repeated work can be packaged
Shared operations, adaptations and acceptance criteria can form lab application packages for subsequent deployments.

Our view: before widespread use in homes, robots can find practical applications in labs with well-defined tasks and acceptance criteria.

03

Lab applications

Explore where robotics can help a lab workflow.

Connect the equipment.
Keep experiments moving.

A lab application organizes operations, equipment handoffs, operating conditions and result checks into a workflow for a specific experimental task.

Experimental requirements inform step decisions. Assign operations to instrument interfaces, robots or people as needed, then check observed state and relevant quality-control (QC) results. Results return to step decisions; unmet conditions pause dependent steps. The middleware adapts robot operations, while instrument interfaces and people can execute directly.
Organize execution around the task. Use results to plan the next step.

Condition-triggered workflows

  1. BottleneckThe culture reaches its growth threshold, but the next step still waits for a person.
  2. ApproachTrigger induction, sampling or cell harvest when the required conditions are met.
  3. Potential valueAct within the required time window and reduce delays.
Workflow and acceptance criteria

Use growth-curve measurements, time windows and protocol thresholds to coordinate induction, sampling or harvest, rather than a fixed schedule alone.

Check monitoring data, trigger conditions, timing and experimental outcomes. Missing or abnormal data blocks steps that depend on it.

Result-driven sample processing

  1. BottleneckMeasurements are ready, but downstream preparation still depends on a manual handoff.
  2. ApproachUse measurement results to coordinate preparation and sample transfer.
  3. Potential valueVolumes based on measurements. Sample provenance preserved.
Workflow and acceptance criteria

Coordinate measurement results, volume calculations, sample transport and processing on existing liquid-handling workstations. Robots handle the physical handoffs where needed.

Calculate quantities from measurements and QC, schedule processing and track destinations. Acceptance checks cover composition, destination containers, sample provenance and relevant experimental QC.

Handling cultures on solid media

  1. BottleneckCollecting cells from solid media requires more than liquid handling.
  2. ApproachCollect the specified culture material, streak a plate and start incubation.
  3. Potential valueReproducible handling. Traceable strains.
Workflow and acceptance criteria

Sampling a specified culture grown on solid medium in a tube, followed by plate streaking and incubation, requires controlled tool contact and inoculum transfer.

Set parameters for the strain, culture conditions and equipment. Validate culture identity, inoculum transfer, streaking quality, contamination control and growth outcomes.

Sample storage for people and robots

  1. BottleneckManual use changes sample locations and complicates robotic access.
  2. ApproachIdentify and locate samples, retrieve them on demand, and verify their return.
  3. Potential valueIntegrate sample retrieval without a complete storage-system overhaul.
Workflow and acceptance criteria

In shared refrigerators and freezers, including ultra-low-temperature freezers, changes in sample placement, access angles and condensation complicate identification and handling. Explore location tracking, handoff rules and limited retrofits for retrieval and return.

Check sample identity, location and container integrity. Validate low-temperature exposure, identification reliability and operational safety separately.

These are potential applications. Co-development defines the task, operating conditions and acceptance criteria for each application.

Use existing device interfaces where available. For buttons, knobs or handling tasks without an interface, assess robotic interaction and any necessary modifications. Build on liquid-handling workstations and other equipment, measuring value through qualified output, timely responses, human intervention and total cost.

04

Technology demos

Component-level cross-platform simulation · Latest addition: October 28, 2026

Different platforms.
The same task objectives.

Start with basic operations needed for lab workflows, then simulate and adapt execution across hardware.

We have validated some basic operations in simulation. We are developing experimental workflows and discussing application needs and hardware-validation conditions with hardware teams.

The same tube, destination in the rack and success criteria are used across platforms. Navigation, docking, grasping and placement are adapted to each configuration.

About 69 seconds
Simulation · Original speed

Compare all three configurations. On mobile, select one platform for a closer view. Recordings retain Chinese on-screen captions.

Open video file

Acceptance checks

The correct tube is released into the designated rack position and remains stable.

Configuration notes

OpenArm and Franka use parallel grippers; Phoebe uses a Hand-E gripper. Grasping, transport and rack placement are adapted to each configuration.

These videos show individual operations in cross-platform simulation. Hardware performance and experimental quality require separate validation.

Continuous execution mechanism · Simulation validation

From individual operations to connected steps.

State continuity
Preserve object state and pass earlier results to later operations.
Condition-based continuation
Check current state and proceed only when preconditions are met.
Failure handling
Block subsequent steps after a failure, preserving state for diagnosis and recovery.
Hardware configurations, comparison criteria and demo scope

Tube transfer, button press and knob adjustment: September 15, 2026. Pipette demo added October 28, 2026.

The videos above show independently initialized operations. Continuous execution was tested separately in simulation, combining tube transfer and equipment interaction on OpenArm in the tested scenarios and configurations.

Shared
Task goals and acceptance criteria
Adapted
End effectors, grasps, paths and controls
Checked
Simulated operations and final states
PlatformTube transferButton pressKnob adjustmentPipette & tip
OpenArmLeft parallel gripperRight ORCA dexterous handRight ORCA v2Right ORCA v2
FrankaLeft parallel gripperRight Wuji dexterous handRight Wuji Hand 2Right Wuji Hand 2
PhoebeLeft Hand-E gripperRight Allegro dexterous handRight Allegro v3Right Allegro v3

These simulations use three hardware configurations to illustrate how execution is adapted to shared task requirements. Additional configurations follow the same adaptation and validation process. Platform names identify the demo configurations; commercial arrangements are agreed separately.

Configurations share final-state criteria for tube transfer and use separately defined efficiency targets. In this run, Franka completed the task in 66.702 seconds, above its 64-second target.

The Phoebe button demo uses an uncalibrated engineering model. Its knob demo uses an idealized passive-roller model that has not yet been calibrated.

Pipette demo: pickup and tip attachment are conceptual simulation; tip attachment is modeled for illustration. Grasps, orientations and details vary by configuration, with no performance ranking. Liquid transfer, tip sealing and real-hardware performance have not been validated.

05

Product roadmap

Workflow development · Execution middleware at the core · A lab operating system as the long-term vision

From lab workflows
to repeatable delivery.

Package protocols, adaptation configurations and acceptance criteria in versioned lab applications, so subsequent deployment can focus on hardware and site differences.

  1. Workflow development

    Define steps, device interactions and quality criteria around the samples and experimental goal.

  2. Lab application packages

    Manage workflows, hardware bindings, adaptation parameters and acceptance criteria with explicit versions and operating conditions.

  3. Reuse across sites

    Retain workflow and skill definitions. Adapt to hardware and site differences, then perform the necessary revalidation.

Packages define workflows; the runtime organizes execution. It coordinates instruments, robots and people against shared criteria, checking and recording outcomes. The middleware adapts robot operations. Shared assets underpin the longer-term system for development, deployment and operations.

LabMozart Operating System for Biological Labs

From design and validation to deployment and operations

Long-term product concept: Studio defines the lab and workflow. SkillLab develops, adapts, simulates and validates skills. Ops commissions the site and performs acceptance checks, then supports operation and maintenance. Authorized feedback returns to SkillLab for improvement, revalidation and approved release. Shared execution middleware and reusable assets underpin every stage.
Return to the system diagram

Scroll horizontally and vertically for details. Focus the frame to browse with the arrow keys.

Studio: site and workflow design. SkillLab: adaptation and simulation testing. Ops: deployment and operations. A long-term direction, developed in stages.
Execution architecture

Next-step decisions route tasks to instruments, robots or people. The middleware adapts robot operations; observed state, instrument readings and experimental QC feed back into those decisions.

Tasks and authorization inform next-step decisions, which route directly to instrument interfaces or authorized people. Robot operations use the execution middleware. Observed state, instrument readings and experimental QC return to decisions; QC-dependent steps wait for the required results.

Task and authorization

Samples, equipment, goals, SOPs and authorized scope; connected to LIMS / ELN.

Next-step decisions

Use dependencies, current state and model recommendations to schedule, pause or hand off.

Choose the execution resource for each step

Instrument interfaces

Call reliable interfaces directly and return instrument readings.

Execution middleware → Robots

Compose skills, match capabilities, plan execution and verify outcomes. Vendor systems retain control and protection.

Authorized people

Carry out manual steps, exercise experimental judgment and handle exceptions directly.

Outcome checks and feedback

Observed state, instrument readings and measured QC inform next-step decisions against relevant criteria. QC-dependent steps wait for the required results.

Connect laboratory information management systems (LIMS), electronic lab notebooks (ELNs) and instrument data. Use reliable interfaces directly, retain vendor control and protection, and assign manual steps and exception handling to people.

06

The technical core

Shared skills. Independent verification.

Beyond motion.
Meet experimental requirements.

Build sample identity, timing and quality-control requirements into execution and verification. Assess completed operations and experimental quality separately.

Task requirements constrain the plan; shared acceptance criteria feed independent result verification.
Shared skill definitions contain object roles, desired states, pre/postconditions and acceptance criteria. Task requirements feed configuration binding and planning, followed by permission checks and segmented execution. Shared acceptance criteria separately feed independent result verification. Observed state and instrument readings determine completion or blocked continuation; execution and evidence collection adapt to the configuration.
Preserve sample identity
Track sample identity and processing stage, including the source and destination of each transfer.
Respect operating conditions
Include time windows, contact conditions and step dependencies in execution constraints.
Verify experimental quality
Check final operation state, instrument readings and experimental QC separately. Sample quality and contamination control require physical measurements.
Design choices, configuration binding and end-effector adaptation

Four key design choices

Shared criteria; adapted execution
Define objects, goals, pre/postconditions and acceptance criteria once. Bind configurations, check permissions and execute in segments. Adapt hardware and observations—not task criteria.
Hard constraints first
Templates, planners or vision-language-action (VLA) policies generate candidates. Hard geometric, contact and hardware limits remove infeasible options before comparing progress and risk. Prefer reliable templates; force and tactile feedback require calibrated, validated hardware.
Predict to rank; observe to verify
Predictions rank candidates. Observed state, instrument readings and QC verify outcomes against shared criteria. Vendor systems retain low-level control and protection.
Wait for dependent results
Observe before each segment. Block continuation on uncertain state or unmet conditions, using tested exception-handling paths. While QC is pending, continue only with steps that do not depend on it.

Protocols supply objects, steps and criteria. Demonstrations supply intent and visual cues; force data requires measurements. Robot records supply state, actions and outcomes, retaining provenance and missing data.

Shared requirements; adapted plans

Task and skills
Objects, goals, constraints and acceptance criteria.
Configuration and site
End effector, control, location, permissions and current state.
This run’s plan
Bind validated templates and configurations; set actions, parameters and stop conditions.

Design example: tube placement

Preserve criteria
Same tube, rack and task: correct identity and position, an intact container and stable placement after release.
Adapt execution
Changing from a parallel gripper to a dexterous hand requires adapting contact points, grasp force, clearances, rack insertion and release.
Recheck verification
Adapt grip checks and detection to available signals. Revalidate success and failure detection; retain result criteria.

Preserve object state on exceptions and use the defined handoff. Execution records inform offline refinement; changes require relevant revalidation.

07

AI-native R&D

AI-native R&D.
Build for reuse.

AI agents connect method research, skill development and simulation, turning test feedback into knowledge for subsequent development.

R&D and offline improvement: from operation requirements to reusable experience
Understand the task, research methods, develop skills, validate in simulation and reuse experience. Failed candidates return to development. Evaluated and revalidated versions may serve subsequent tasks; active versions are not automatically replaced.

Physics-based simulation provides test evidence. People define objectives, make critical judgments and review the results.

Lab applications and skills
Reuse workflow definitions, skills and operating conditions to compose later application packages.
Hardware adaptation system
Reuse device interfaces and execution plans, focusing new work on configuration differences.
Validation and regression system
Build regression tests from versions, execution records and quality criteria, retaining exception-handling knowledge.

Use authorized feedback to improve applications and delivery. Assess reuse through adaptation effort, human intervention and experimental quality.

Development feedback and independent evaluation

Develop candidates; learn from feedback

AI researches methods, generates skill code and configurations, uses simulation to test geometry, contact and forces, and analyzes failures. Failed candidates return to development.

Authorized execution records link tasks, configurations, versions and outcomes. AI uses them to distinguish perception, calibration, contact, policy and experimental factors, then updates code, configurations, tests and development rules.

Operations, exceptions and human corrections linked to outcomes refine skill applicability, recovery strategies and interfaces. Object specifications, interfaces, calibration and site records refine adaptation configurations and their applicability. QC, controls and cross-configuration records build regression sets and validation matrices.

Contamination requires dedicated QC; causal conclusions require controlled experiments. Align units, coordinate frames, time and object semantics. Retain provenance, calibration, configuration, versions and missing information; distinguish measured, inferred and simulated parameters.

Evaluate independently; measure reuse

Compare learned policies and other methods with reliable baselines on the same tasks and resource budgets in independent tests, retaining failures. Assess reuse through version differences, execution logs and engineering time for adaptation and revalidation, while checking human intervention and experimental quality.

Release gate: continue analyzing candidates that fail criteria. Independent evaluation, necessary revalidation and approval produce traceable versions for subsequent tasks or authorized updates. Active versions are not automatically replaced.

08

Deployment and validation

A validation path from simulation to hardware

Test in simulation.
Validate on hardware.

Build a deployment package in stages: a site model, a simulated configuration, hardware-test records and site acceptance.

01

Model the site

Capture maps the workspace and equipment locations, retaining annotations and measurement sources. Precise calibration then establishes the interaction parameters.

LabMozart Capture workspace-scanning and equipment-location interface.
LabMozart Capture / Spatial capture interface · Original screenshot
Stage outputSite model with traceable coordinates
02

Adapt in simulation

Test object interactions, paths and task constraints against the selected hardware configuration, recording candidate plans and simulation conditions.

Functional rooms and equipment layouts in the digital laboratory, used for space, object and task adaptation. Original interface screenshot with Chinese labels.
Digital laboratory / Adaptation and rehearsal · Original Chinese interface
Stage outputConfiguration and simulation-test records
03

Validate on hardware

Plan reviewed hardware trials to test safety and recovery, recording interventions and the relevant QC results.

Stage outputCalibration, contact and QC test records
04

Validate at the site

Use hardware-test results to define the site trial, agree on acceptance criteria, then arrange a controlled pilot.

Stage outputSite acceptance and operating scope
Validation requirements, operating scope and site handoff

Four kinds of evidence; four questions

Can the skill transfer?
Does the same task meet shared criteria across configurations? Check versions, test conditions and final states.
Is the operation reliable?
Are physical contact, error and recovery acceptable? Check hardware tests, contact data and exception records.
Does the experiment meet quality criteria?
Do sample identity, processing and contamination control meet requirements? Check experimental QC and controls.
Does it work at the site?
Do qualified output, intervention and support effort meet the agreement? Use site records and customer acceptance.

Unknown outcome? Check state before resuming.

Stop and hand off when no usable plan is available, state is unknown, or retry or time limits are reached. After an interrupted irreversible step such as reagent addition, establish the actual outcome before any retry. Hardware operation requires review and authorization, retaining vendor protection, emergency stops and site safeguards. Controlled trials are distinct from routine operation; low-temperature, aseptic and exposure-sensitive work needs dedicated assessment.

Specify scope for each configuration

Lab skillHardware configurationRuntime versionSite conditionsValidation evidence

A validated application package, together with workspace and interaction coordinates, calibration and configuration versions, operating conditions, acceptance records and exception-handling procedures, forms a deployment package for customers and delivery partners to review, revalidate and maintain.

09

Co-development and ecosystem

Co-develop
a lab application.

Developing joint lab products for life-science and biopharmaceutical R&D organizations and teams, with robotics, instrument and integration partners.

Robotics and engineering partners

Configure robots, instruments and application packages as a workcell for a defined workflow, exploring joint delivery.

Biological R&D laboratories

Define workflow requirements and acceptance criteria. Discuss workcell purchase or support for operating applications on site for an agreed period.

Our priority is life-sciences and biopharma R&D teams with existing instruments, recurring cross-device bottlenecks and a willingness to define acceptance criteria together.

Proposed collaboration: agree on the application package, hardware configuration and service scope for one lab workflow. Start with simulation assessment, then stage adaptation, hardware testing and site acceptance.

Initial configuration
Workflow development, hardware adaptation, integration and acceptance.
Ongoing operation
Runtime licensing, execution checks, version maintenance and on-site application support.
Application expansion
Additional application packages, method updates and necessary revalidation.
Models, policies, robots and instruments provide capabilities. LabMozart supplies application packages, hardware adaptation and runtime verification. Labs define needs and acceptance; robotics and engineering partners may develop and deliver workcells jointly. Roles are agreed per project.
Capabilities, applications and delivery roles; scope is agreed per project.

Application support, hardware and site engineering have distinct scopes. LabMozart provides the application, runtime, adaptation and validation. Partners would handle hardware supply, installation and maintenance as agreed. Hardware purchase or leasing, service levels and acceptance responsibilities are set per project.

Task screening, technical integration and data ownership

Select the task; define operating conditions

Prioritize unmet needs with clear usage frequency, reuse potential and independently testable criteria. Operating windows follow equipment schedules and experimental deadlines.

Integrate capabilities; assign engineering responsibilities

Models provide understanding and recommendations; LabMozart organizes experimental constraints, execution adaptation and outcome checks. Integration requires usable interfaces and control permissions.

Robot vendors
Hardware, control interfaces and protection functions.
Automation integrators
Equipment connections, calibration, commissioning and handoff.
Instrument vendors and channels
Device interfaces, state definitions and operating knowledge.
Reagent, consumable and protocol partners
Object specifications, operating conditions and quality requirements.

Commercial proposals are structured around the workcell, application packages and service level. Reagents, consumables and dedicated fixtures are potential areas for future co-development, without requiring exclusive compatibility.

Deployment packages, validation requirements and training would support partner delivery. Contracts define runtime licensing, version updates and access to data needed for maintenance.

Protect shared capabilities and customer outcomes separately

Ownership of general capabilities, customer-specific development and experimental results is agreed separately.

Sample information, raw scientific records and experimental results are protected under customer-specific agreements. Execution and maintenance records are limited to agreed service purposes. Cross-customer improvement or general model training requires separate explicit authorization, including for de-identified records. Agreements specify use, retention and deletion.

Discuss co-development

10 / Team and contact

Zhuo Song, founder and CEO of LabMozart
Zhuo Song Founder & CEO · Changsha, China

Bio × AI × Robotics

Biology meets AI.
Robotics meets the lab.

Bio
PhD in Human Genetics and Bioinformatics, Vanderbilt University.
AI
Develops full-stack AI applications; previously led the development of China’s first FPGA-based genomic computing product.
Robotics
Contributed extensively to automated anaerobic culture and colony-picking systems: defining experimental requirements, training computer-vision models and collaborating with hardware engineers.
Entrepreneurship
Previously co-founded a company and served as CTO, bringing clinical genetic testing and genomic computing products to market and supporting cumulative fundraising of over RMB 200 million.

For investment discussions, application co-development or technical collaboration, contact us by email.

zhuosong@gmail.com
Email the founder