OncoOS
Platform Architecture AI Clinical Request early access

The operating system for hospital drug-screening labs.

OncoOS connects protocol design, instrument scheduling, and patient-linked sample tracking into one platform, from biopsy to dose-response curve, fully traceable, with every instrument talking back over an authenticated line.

No install required for scientists: edge agents handle the instrument side.

app.oncoos.lab / overview
OncoOS dashboard: running experiments, live schedule, and today's tasks
Live schedule · 105 steps across 5 experiments
Priority-aware scheduler · real-time & adaptive

0

Prefect flows quietly running safety nets behind every claim, poll, and heartbeat

0

Typical time for a claim or state change to reach a blocked edge agent via long-poll sync

0

Sample lineage traced from biopsy tube to individual microtumor well

0

Commands ever pushed to an instrument: the platform is receive-only, by design

Platform tour

Every layer of the lab, in one system of record

From how a protocol is drawn to how a plate physically moves between instruments: OncoOS is built around the real shape of a translational oncology workflow.

Design protocols like flowcharts, not spreadsheets

Drag step templates onto a canvas and wire them with typed connections: data, physical consumable movement, conditional branches, or timed waits. Groups, auto-layout, and an inline assistant keep a multi-day screen legible, like Drug Sensitivity Testing below: formation → drug application → two incubation/imaging/measurement cycles → project output, six lanes end to end. DAG validity is checked at design time, not discovered mid-run.

Versioned releasesDraft → ReleasedAuto-layoutInline assistant
VISUAL EDITOR OncoOS visual protocol editor showing the Drug Sensitivity Testing protocol: a 6-lane, 10-step microtumor drug screen DAG

See every instrument, exactly where it lives

Lab Space is a physical map of your instruments across buildings and floors, placed against your actual bench layout, not a generic list. Each device shows live state at a glance: idle, busy, full, in error, or under maintenance, with load meters for multi-slot incubators and storage.

Multi-buildingLive device stateLoad meters
LAB SPACE OncoOS Lab Space digital twin showing instrument placement on a floor plan

One global plan, real-time, fully dynamic and adaptive

A priority-ordered, resource-aware scheduler continuously walks the whole DAG across every system and consumable: capacity, incubation limits, dependency order, and error lockout are hard constraints; due-dates and ordering are soft, minimized by a priority score that ages starved steps upward. The same plan drives the Gantt, the edge-agent timeline, and claim-order enforcement.

Anti-starvation agingConsumable-awareSingle source of truth
LIVE QUEUE OncoOS live queue showing running and pending step runs per instrument

Instruments, compute, services, and people: one registry

Every system in the lab is a first-class record: liquid handlers, imagers, incubators, GPU inference services, even lab personnel. Heartbeats, load, parent/child relationships, and physical-vs-simulated status are all visible in one table, the same registry the scheduler claims against.

Heartbeat monitoringSimulated + physicalCapacity-aware claims
SYSTEMS OncoOS systems registry listing instruments, compute services, and personnel

Full chain of custody, from biopsy to well

Samples carry lineage (derived_from and pooled_from) so a microtumor well can be traced back through derivation plates to the originating biopsy tube. Consumables and kits are slot-validated, so a 384-well drug plate always knows exactly what's registered in every position.

Full lineage graphSlot-validated kitsBarcode-native
SAMPLES OncoOS samples table with microtumor lineage tracking

Query every well like a spreadsheet, plot it like a scientist

Explore filters by drug, concentration, indication, sample type, and QC status across every experiment, then switch between table, plate map, scatter, and dose-response views without losing the filter state. Export straight to CSV when it's time to leave the platform.

Plate map viewDose-response curvesCSV export
DATA EXPLORER OncoOS data explorer showing well-level measurement table with filters

Know where every consumable is, and move it with a scan

Logistics groups every registered consumable by its current physical location, an instrument system or off-device storage, so a lab lead can expand the Cell Incubator card and see exactly what's docked there right now: accession ID, contents, and state, without walking the bench. Transfer moves a scanned consumable to a new system or into storage; Derive distributes a sample across selected wells into new child samples; Pool merges multiple source samples into one. All three are logged as first-class relocation hops, with concurrent blockers surfaced instead of silently queued.

Location overviewBarcode transferDerive & poolConcurrent blockers surfaced
LOGISTICS OncoOS Logistics page with the Cell Incubator location card expanded, showing 8 plates and tubes currently docked

Every action logged, every note in one place

Every state transition, claim, and system event on an experiment is written to an append-only history and merged into a single notebook timeline alongside free-text notes. Notes can be authored centrally by a scientist in the web app, or filed at the bench by an operator through the edge agent's control UI: both attach to the same experiment or step run and appear side by side, author included, so "who changed what, and why" never depends on someone remembering to write it down separately.

Append-only historyCentral + bench authoringPer-step-run notesExportable PDF
LAB NOTEBOOK OncoOS experiment notebook merging state-change history and operator notes into one activity timeline
And the rest of the bench

Built for the parts of the workflow that don't fit in a demo

Protocols & pipelines

Reusable experimental protocol templates and data pipelines, versioned from draft to released, with accession IDs and step counts at a glance.

Logistics & relocation

Physical consumable moves (robotic or manual) are tracked as first-class hops, with concurrent blockers surfaced instead of silently queued.

Role-aware workspace

Scientist, lab technician, project manager, clinician, viewer: navigation and permissions adapt per role, with an admin impersonation view for support.

QC review

Review well-level measurements against a plate map and record QC decisions before data ever reaches an analysis pipeline.

Lab notebook

An electronic lab notebook that lives next to the data it describes, with every state change logged alongside it: no separate app, no copy-pasted screenshots.

Diagnostics

System health, flow registry, and agent tool status in one place, so "is it the instrument or the platform" stops being a guessing game.

Under the hood

Receive-only by design. Every instrument reports in: none get commanded

Edge agents run next to each instrument and talk to the platform over authenticated REST. The platform never opens a connection back to a device: it can only accept or reject what an agent reports.

planned
pending
running
completed
on failure
error
→ retry
system fault
suspended
↔ running

The StepRun state machine is the spine of the platform

Every unit of work (a robotic move, an imaging pass, an incubation window) is a StepRun with the same lifecycle. A system error auto-suspends its running work instead of losing it; container state rolls up with a strict priority so a Gantt bar never lies about what's actually happening on the bench.

  • Claims are first-come-first-served, capacity- and priority-checked, rejected synchronously on conflict
  • A long-poll sync/wait endpoint wakes blocked agents within moments of a state change
  • X-Agent-Token auth, minted at enrollment approval: no shared secrets, no standing commands
How a screen actually runs

From a step template to a well of live cells

1
Step templates

Reusable building blocks: imaging, dispensing, incubation, analysis.

2
Protocols & pipelines

Templates wired into an ordered, versioned DAG.

3
Experiments

A protocol instantiated against real samples, consumables, and a project.

4
Step runs

Scheduled, claimed, and executed by the right instrument, in priority order.

5
Results

Measurements, images, and outputs flow back in, queryable within seconds.

One driver interface, either path

Manual bench today, robotic bench tomorrow: same protocol either way

Every instrument in Lab Space is linked to the platform by an edge agent, a small process that runs next to the device, claims the step runs scheduled to it, and reports results back. Whether that step happens by robot or by hand is a property of the instrument, not of the protocol.

Driver-connected instrument

Fully automated

When an instrument has a driver (a SiLA 2 gRPC device, a serial device, a vendor SDK) the edge agent claims the step the moment it's schedulable and runs it end to end. A driver's only job is turning "please run this step" into a stream of readings; the runtime handles enrollment, auth, image upload, and retries underneath it. No operator touches it.

Any other instrument

Manually operated

No driver configured? The step is scheduled and claimable all the same. The edge agent's local control UI turns the platform's step briefing into what to do at the bench: which consumable, which parameters, how many measurements are expected, plus the free-text instructions authored on the step template itself, task by task. An operator claims it, follows that checklist on the instrument's own software, then uploads the resulting files through that same briefing card.

EDGE CONTROL UI OncoOS edge-agent control UI showing per-instrument machine state and step timeline

Either way, results reach the platform through the same door: a scoped presigned upload followed by an authenticated measurement post. An automated driver's readings and an operator's manually uploaded files are ingested identically, same validation, same lineage, same Data Explorer on the other end.

Two kinds of AI, on purpose

An assistant you talk to, and agents that work inside the run

OncoOS keeps the conversational assistant and the autonomous execution agent as separate services with separate tool surfaces, so "ask a question" and "act on the bench" are never the same permission.

Conversational assistant

Ask OncoOS

The AI a scientist talks to directly, surfaced from anywhere in the app to explain a failure, summarize a plate, or answer "why is this step blocked" in plain language, grounded in the same live data the UI shows.

OWhy is Imaging #1 running long on A2?
AIIt's ~16h over its estimate: the microscope is idle-blocked behind a wrapping-up plate robot hop. Want me to open the queue?
Workflow agent

Autonomous step-run agents

A separate agent runtime that operates inside experiments, advising on scheduling trade-offs and executing bounded tool calls against step runs, with its own tool surface, reviewable in Diagnostics.

APrecision Oncology Screen, Day 3 imaging batch: 8 of 9 wells within threshold, 1 flagged for QC re-review.
AAdvising: hold Day 4 drug application until flagged well clears QC.
Closing the loop

Full lineage, standard ontologies, complete provenance

Every result traces back through a real chain of custody (patient to biopsy to derived sample to well), and every clinical concept along the way is coded against the ontologies your hospital already uses, not an in-house vocabulary.

1
Patient

Pseudonymised record: an accession ID stands in for identity everywhere downstream.

2
Biopsy

Barcoded tissue sample, timestamped at collection: the root node every derived sample traces back to.

3
Derived sample

A microtumor, organoid, or cell culture: derived_from and pooled_from recorded automatically.

4
Plate & well

Placed into a slot-validated consumable under a drug plate design.

5
Measurement

A well-level result, queryable and traceable back through every hop to the biopsy.

Every sample carries a full timeline (created, lineage, step runs, measurements) so "where did this number come from" is always a click away, not a support ticket.

Patients

Pseudonymised records with linked biopsies: accession IDs stand in for identity everywhere downstream.

Biopsies

Each biopsy is a first-class, barcoded record linked to its patient and indication: the origin point of every downstream lineage graph.

Microtumors, organoids & cell culture

Samples derived or pooled from a biopsy carry that ancestry forward automatically, so a single well can be traced back through every derivation step to the originating tissue.

Drugs & therapies

The drug and regimen catalogue screens are weighed against, enriched with clinical evidence from validated to inferential, so a dose-response result sits next to what's already known about that drug.

Indications, ontology-mapped

Cancer indications carry standard codes (NCIt, ICD-O-3, SNOMED CT, ICD-10, MedDRA, DOID), so a screen's clinical question links out to the same vocabularies your EHR and tumor board already use.

Drug plate designer

Lay out mono- and combination-therapy dose ladders across 96-, 384-, or 1536-well formats (by drug, by dose, interleaved, or randomized) with controls, DMSO limits, and Cmax-relative dosing built in, then materialize the design onto a real consumable.

See OncoOS on your bench

This is a preview build: request early access and we'll walk you through a live protocol, a real edge-agent claim, and how your instruments would map onto Lab Space.