Bridged PyLabRobot into an agent-facing protocol

General
1

I wrote labwire-pylabrobot, a bridge that exposes a PyLabRobot LiquidHandler as an instrument in Labwire, an open Apache-2.0 protocol for driving hardware from AI agents (discovery, mandatory UCUM units, safety classes with enforced confirmation, signed run manifests, MCP adapter).

The useful part: mapping PyLabRobot broke my spec in ways the first bridge (ophyd) never did, and the failures are documented in SPEC-FINDINGS.md in the repo. The two biggest, both now fixed in v0.3 because this bridge forced them:

  1. Well addresses. UCUM made a parameter a volume in uL, but a well reference was just a string. I initially invented an address grammar (“source_plate/A1”) the protocol could not type or validate, exactly the bridge-private convention a protocol is supposed to eliminate. v0.3 added typed resource references: the schema declares the expected kind and the server validates the reference against live deck state at submission.

  2. Deck state. Agents cannot plan transfers without the deck, and the protocol had nowhere to put tree-shaped state. The deck is now a first-class discoverable resource (~8 KB projected from PyLabRobot’s ~133 KB serialization), so an agent finds it the same way it finds capabilities, no prompt hints needed.

Still open for critique: every material-moving operation is classed S2 and requires explicit agent confirmation, and gripper moves are exposed at the top tier, which requires an operator grant bound to a digest of the exact parameters, something the agent cannot produce for itself. The bridge uses PyLabRobot as an optional dependency against hardware-free backends only, no vendoring, and the README states it has never driven a physical liquid handler.

Repo: GitHub - benchwire/labwire · GitHub , bridge under packages/bridges/pylabrobot. make demo-pylabrobot runs a serial dilution end to end with signed evidence; make demo-pylabrobot-claude runs the same protocol planned live by an agent.

If a bridge like this is useful to this community, I would rather shape it to fit PyLabRobot’s model than have it drift. If you find anything wrong please let me know!

2 Likes
2

this is awesome

and thanks for the good feedback! both are good points

2 Likes
3

Thanks so much Rick. While you are here, I have a question that I think only you can answer for me. What does cancel actually do mid-operation on real machines? My bridge currently abandons the in-flight PLR call, which is a guess. If the safe move is finishing the op and only stopping between steps, I’ll encode that instead.

Also, I’d be happy to PR the bridge into your integrations docs if you want it there.

And if anybody else reading this runs PLR on real hardware and wants an agent driving it through the bridge, I’ll do the setup free for your instrument.

2 Likes