Automata builds robotic automation platforms for life science labs — hardware that handles the kind of repetitive, precision-sensitive work that researchers would otherwise do by hand. My role sits at the software layer between the physical instruments and the services that orchestrate them.
Instrument drivers
The primary work is writing instrument drivers: Python abstractions that speak a given lab instrument's communication protocol and expose a clean interface for the orchestration layer above. Each instrument is different — different protocols, different error behaviors, different timing requirements. The driver layer's job is to paper over those differences and give the rest of the stack something stable to build on.
The boundary between driver and orchestration is always interesting to think about. How much of the device's quirks do you expose? How much do you hide? There's no clean answer. You're trying to balance fidelity to what the hardware actually does with the cognitive load you put on engineers who will never need to think about that hardware directly.
What's different about this domain
A bug in a web API causes a bad response. A bug in a lab automation system can waste an expensive reagent, contaminate a sample, or block a researcher's day. That changes how you reason about reliability. Edge cases aren't theoretical — they happen on physical timelines, and fixing them can mean waiting for a maintenance window.
That constraint is actually clarifying. It makes you more careful about what you assume, more thorough about how you test, and more thoughtful about how systems fail. I find that kind of discipline useful even when working on things without physical consequences.