The execution gates are the interesting part here. In a tool-using system, “plausible protocol” is a weak milestone if the generated code can’t satisfy device constraints or the feedback loop can’t localize the failure. I’d want to see how much of the 89.5% gate-pass rate comes from the verifier catching errors before execution versus the skill library learning from failed runs. Keeping protocol intent, derived parameters, and instrument observations as separate, traceable state also seems important: it makes revisions auditable instead of letting a later agent silently rewrite the premise. The Opentrons result is a useful concrete test; I’m curious how performance holds when protocols or hardware profiles are held out entirely.