I think moving up is really just reinventing the orchestrator layer. But I’d argue PyLabRobot doesn’t need to go up there. The orchestrator level is crowded: John’s FluentAgent (link), @hazlamshamin’s node/recipe layer, and others. I think this work belongs above PyLabRobot rather than inside it. PyLabRobot’s uniqueness is the driver level and the resource model.
Earlier I had the feeling that moving away from a universal API was a good thing. I still do, and it’s very much how things are already going. The new instrument drivers are written by the LLM anyway, and they conform loosely to the capability structure. Nothing wrong with that.
And we can keep the capability and locality structures side by side, or, taken to the end, move everything to localities and go fully device-centric. Either is fine, because the point of a capabilities architecture isn’t hardware-agnosticism anymore (clear from this thread). It’s structure, a consistent shape for the LLM to write in. Capabilities where devices genuinely line up; localities with typed params as the escape hatch where they don’t. And if everything drifts to a locality, that’s okay. The durable value is the organization, not the universality.
But aiming for abstraction at another level, I don’t think that’s PyLabRobot’s job. Let’s instead make the resource model, volume tracking, and clash prevention better, in a real open-source, community-driven way. That’s the layer that makes all these LLM-written drivers actually safe to run, and unlike the orchestrator layer, it’s uniquely ours to get right.