Before USB, every device had its own port
You remember the drawer. Serial cable for the label printer, a different one for the scanner, a card you had to install to make the camera work, and a driver disc for each. Every pairing was its own small project.
USB didn't make devices better. It made them interchangeable — and that turned out to be worth more than any individual improvement, because it meant a device maker and a computer maker could stop coordinating with each other.
Model-driven hardware is in the drawer era. There's no USB moment yet. What exists instead is four partial standards, each covering a real slice of the problem, none covering the seam between them.
Worth knowing what they are, because the vocabulary shows up in every vendor pitch you're about to hear.
Describing the machine
The most settled layer. A file format that says what the machine physically is — where the joints are, which direction they rotate, how far they travel, what the parts weigh.
URDF is the long-standing one; newer stacks lean on formats like MJCF and USD, particularly where simulation matters. If a robot exists in software anywhere, it has a file like this behind it.
What it does not do is say how to control the machine, what it's for, or what it's unsafe to do. It's a body with no nervous system. Useful, standardized, and about ten percent of the problem.
Moving messages around
ROS 2 — the Robot Operating System, which is not an operating system — is the closest thing to a genuine standard in this whole field. It's the plumbing: how one piece of robot software publishes a camera frame that three other pieces subscribe to, how a request gets made, how a long-running action reports progress.
It's near-universal in research and increasingly common in industry. If you hire someone to integrate a robot, they will almost certainly be working in it.
But plumbing standardizes how messages move, not what's in them or what anything does with them. Two ROS 2 robots don't understand each other any more than two computers understand each other because both have USB ports.
Talking to the language layer
The newest entry. MCP — the Model Context Protocol — standardizes how a model reaches out to a tool or a data source. It's what makes it possible to hand an AI a capability without custom-wiring the model to the system.
People are pointing it at hardware, and for a real class of jobs that works: ask a machine its status, look up a fault code, kick off a named routine that the machine already knows how to run safely.
What it isn't is a control protocol. It's request-and-response, at the pace of a conversation. Go back to the three clocks — this is firmly the top one. It's an excellent way for a model to ask a machine to do something it already knows how to do, and no way at all for a model to do something a machine doesn't.
That distinction gets blurred constantly in demos. Watch for it.
The policy, and the data behind it
The unsolved one, and the reason the other three don't add up to a standard.
The effort here is to make a learned skill portable — so that "open a latch" trained on one machine works on a different machine. Open X-Embodiment pooled robot demonstration data across dozens of institutions to attack exactly this. Hugging Face's LeRobot is building the open stack — models, datasets, and cheap arms to run them on — around the same goal.
The word to know is cross-embodiment: does a skill survive being moved to a different body? Today, mostly no. Change the arm, change the gripper, move the camera four inches, and performance falls off in ways that are hard to predict from the outside.
That's the real reason there's no standard. You can standardize a plug. Standardizing a body — so a skill means the same thing on two different machines — is an open research problem, not a committee that hasn't met yet.
The safety standards already exist, and they don't fit
Here's the part that gets skipped in every enthusiastic article.
Industrial robot safety is not a frontier. It's a mature, boring, well-regulated field with real standards behind it — ISO 10218 for industrial robots, ISO/TS 15066 for collaborative ones, functional safety frameworks like ISO 13849 and IEC 61508 underneath. These are the documents that let a machine work near a person without that being reckless.
Every one of them rests on an assumption: that you can specify what the machine will do, and verify it.
A learned policy is statistical. It does the right thing at some rate, and the failures aren't enumerable in advance the way a programmed motion's are. That is not a paperwork mismatch you resolve with a better test report — it's a genuine collision between how these systems work and how safety cases get made.
The practical consequence, and it's the most useful sentence in this post: the safety layer stays separate, and it stays deterministic. The interlock, the light curtain, the E-stop, the limit switch. None of those become AI. They sit underneath it, and they are what makes it acceptable to run something above them that's occasionally wrong.
If a vendor's architecture has the model in the safety path, that's not an advanced product. That's a missing part.
What the actual signal looks like
Ignore the demo videos. There are two things that would tell you the standard is arriving, and neither has happened yet:
- The same policy runs on two vendors' machines without retraining. That's the cross-embodiment problem breaking. It would be the USB moment, and it would be obvious.
- A safety standard names learned policies explicitly — with a defined way to make the case for one. That's the regulatory half, and it moves slowly for good reasons.
Until then, every deployment is a bespoke integration priced accordingly, whatever the marketing says.
This week
You will get pitched. When you do, three questions cut through most of it:
- "What happens to the safety system if the model is wrong?" If the answer involves the model, stop there.
- "Does this run on hardware you didn't build?" No is a legitimate answer — but it tells you you're buying one vendor forever.
- "What does it do on day one versus after you've collected data in my building?" The honest answer is always that day one is worse. A vendor who won't say so is selling you the demo.
None of that requires you to know anything about robotics. It requires knowing that the seams are where this breaks, which you now do.
The part you can act on is underneath all of it — making your own equipment legible enough to be worth connecting to anything. That's the next one, and it's work that pays off whether or not any of this arrives on schedule.
If someone's quoting you on an automation project and you want a second read on where the integration risk actually sits, book a 30-minute call and bring the proposal.