CAPABILITY · Client under NDA

Lab Automation Orchestration Backend

Backend that orchestrates robots, microscopes, incubators, and a cell-analysis vision service into one programmable system for autonomous cell culture.

Lab AutomationSelf-Driving Lab SoftwareBiotechnologyCell Therapy ManufacturingDrug Discovery TechIndustrial RoboticsBiotech Backend SoftwarePharma R&D ToolingHardware Orchestration
See it work

From protocol to orchestrated robots (or simulated ones).

Scientists describe protocols as ordered steps and actions. An async job executor walks the Project → Protocol → Step → Action graph and dispatches each action to the right microservice — incubator, liquid-handler, microscope, or the cell-analysis vision service. Every dispatch lands in a forensic JobLog. Flip mock mode on and the same protocol runs on your laptop without touching hardware.

lab.example/orchestrator
viewing as · Scientist
Scientist · Protocol editor
🧪 orchestrator
Projects
Protocols
ActionTypes
Hardware

Protocol editor

Project · Stem cell expansion 2025-W12 · 1 protocol

draft · v0.4
Project · Stem cell expansion 2025-W12
Protocol · MSC passage P3 → P4
1Pre-warm media @ 37°C
2Aspirate spent media
3PBS wash × 2 editing
robot.dispenserobot.aspiratevision.image add
4Trypsinise & neutralise
5Reseed at 5000 cells/cm²
Summary
Steps5
Actions14
Hardware4 services
Est. time1h 22m
ActionType palette
incubator.warmrobot.aspiraterobot.dispensemicroscope.imagevision.analyse
Demo only

This is an animated mockup of the lab-orchestration capability — not a live product. Protocol steps, log entries, and latencies are illustrative.

01

Typed ActionType registry

Each hardware capability is registered as a typed ActionType — new instruments onboard as data, not code changes. The executor only knows the registry.

02

Async job executor

Walks Project → Protocol → Step → Action eagerly, dispatches each action to the right microservice, and refreshes job state so pause/cancel is honored cleanly.

03

Hardware microservice dispatch

One async dispatcher fans out to incubators, liquid-handlers, microscopes, and the cell-analysis vision service over httpx — concurrent, never blocking.

04

Forensic JobLog

Every action persists full request/response payloads, latency, and execution status — full traceability across physical operations for regulated environments.

05

First-class mock mode

Live HTTP calls swap to canned responses with simulated latency, so the full job lifecycle runs on a laptop with zero hardware reservations.

06

PostgreSQL + SQLAlchemy 2.0 async

Projects, protocols, steps, actions, and logs persist through fully async SQLAlchemy 2.0 over asyncpg — schema migrated with Alembic.

What we built

Backend that orchestrates robots, microscopes, incubators, and a cell-analysis vision service into one programmable system for autonomous cell culture.

How we built it

Async FastAPI + SQLAlchemy 2.0 over PostgreSQL; a typed ActionType registry and a custom job executor dispatch each step to the right microservice.

Scientists describe protocols as ordered Steps and Actions; the executor walks the Project → Protocol → Step → Action graph and dispatches each action to the correct microservice. Every action produces a JobLog entry with full request/response payloads and latency, giving full forensic traceability across all physical operations.

Architecture

How a request flows through it

Each request enters at the top of the diagram, flows through every box, and lands at the bottom — exactly the way the production system behaves. The scan-line traces where a live request would be right now.

tracing request flow
Scientist defines protocol
Project Protocol Step Action graph
Async JobExecutor (FastAPI)
Robot Microscope Incubator Cell-analysis
service service service (CV pipeline)
Every action JobLog
(request, response, latency)
CellAnalysisResult
(count, confluence, viability)
flow direction┌─┐ component
Stack

What it's built with

Backend
FastAPI 0.128SQLAlchemy 2.0 (async)asyncpgPydantic v2Alembichttpx
Database
PostgreSQL
Auth
JWT (python-jose)bcrypt (passlib)
Infrastructure
DockerGoogle Cloud Build
Testing
pytestpytest-asyncio
Engineering notes

The interesting parts

Typed action registry

Each hardware capability registered as a typed ActionType — new instruments are onboarded as data, not code changes.

Async job executor

Walks Project → Protocol → Step → Action eagerly, dispatches each action to the right microservice, and refreshes job state between actions so pause/cancel is honored cleanly.

Forensic JobLog

Every action persists request/response payloads, latency, and execution status — full traceability for regulated environments.

First-class mock mode

Live HTTP calls swap to canned responses with simulated latency, so the full job lifecycle runs on a laptop without hardware.

Decisions

The calls that did most of the work

A handful of engineering choices shape how a system feels. Here are the ones we'd still defend — alongside what each one cost.

01

Typed ActionType registry — onboard hardware as data

A new brand of incubator or a different liquid handler shouldn't require code changes to the orchestration layer; registering capabilities as data keeps the platform extensible.

Tradeoff: Indirection — the call site for a robot action goes through a registry lookup instead of a direct method call. Less greppable, more flexible.

02

Async-by-default Python backend

Job execution is dominated by waiting on physical hardware. A synchronous worker model would spend most of its wall-clock time blocked on sockets.

Tradeoff: Every code path is colored async; mixing in a synchronous helper requires care, and the team has to know FastAPI/asyncio idioms well.

03

First-class mock mode for hardware-free dev

A six-figure hardware rig per engineer doesn't scale. Mock mode lets the full job lifecycle — including cell-analysis output — run on a laptop.

Tradeoff: Mock responses drift from real hardware unless the system is exercised against both regularly; CI needs to cover the mock path explicitly.

04

Pause/cancel honored between action boundaries

Stopping cleanly between actions is safe in a wet lab; interrupting mid-pipette is not. Refreshing job state between every action gives the operator a clean stop point.

Tradeoff: An in-progress action can't be aborted; the operator may wait seconds for a long action to finish before pause takes effect.

Want something like this?

Tell us what you're building.

Free 30-minute call. Real humans, real timelines, no follow-up emails forever.

See more capabilities