The Off-the-Shelf Robot Trap

There is a version of the Physical AI pitch that sounds completely reasonable until the moment it doesn't. It goes like this: find a robot platform that already exists, layer some AI software on top of it, and ship a product. Skip the hard part. Get to market faster. Let someone else solve the hardware problem.

The companies that have tried this are now either rebuilding from scratch or explaining to their investors why they need another eighteen months.

Why the Logic Fails

The appeal is understandable. Off-the-shelf robot platforms are real, they are available, and the idea of not spending two years on hardware development before writing a line of AI code is genuinely attractive. The problem is that a robot and its AI are not two separate products you assemble. They are one system, and the requirements run in both directions simultaneously.

Power distribution is the most immediate example. The physical demands of your AI (how often it needs to process, how fast it needs to respond, what it needs to carry or manipulate) determine what the power architecture of the robot needs to look like. An off-the-shelf platform was built around someone else's requirements. Those requirements are almost certainly not yours. You can try to work within them. Most people discover the ceiling faster than they expected.

Communication latency between software and hardware is the second wall. A Physical AI system making real-time decisions in a physical environment cannot afford the overhead of software that was not designed to talk to that specific hardware. Milliseconds matter. The tighter the integration between the AI stack and the physical system, the more efficiently the whole thing runs. Bolting software onto a robot that wasn't designed for it is not integration. It is improvisation. Improvisation at scale is expensive.

The third problem is the feature set itself. What your robot needs to do physically (the reach, the payload, the locomotion, the sensors) should be shaped by the outcome you are building toward. Not the other way around. When you start with off-the-shelf hardware, you inherit a feature set someone else decided on. Your AI is now optimizing for an outcome using a physical form factor that was never designed with that outcome in mind. That gap does not close with better software. It closes with a different robot.

The Exception, and Why It Matters

There is a company worth naming here, because it is the most cited counterexample and it deserves a clear-eyed look. GrayMatter Robotics pairs off-the-shelf industrial robot hardware with proprietary AI software, has raised over $70 million, and has real commercial deployments across aerospace, manufacturing, and automotive. That is not luck. It is a deliberate strategy that is working.

But the reason it works is precisely what defines the exception. GrayMatter operates in surface finishing: sanding, polishing, grinding, coating. The physical demands on the robot are narrow and consistent. The AI handles variability in the parts, not variability in the robot's operating environment or physical requirements. Their CEO has said explicitly that this is not a general-purpose AI, and that they built it by starting with customer requirements and working backward to the hardware. They did not layer AI onto a robot. They engineered a specific AI solution for a specific physical task category, and then selected hardware that fit those requirements.

That is the condition under which off-the-shelf works: when the physical task is narrow enough that standard hardware already fits it, and the AI is purpose-built for that specific task rather than general capability. If both of those are true, you may have a real path. If either one isn't, you are in the other article.

What Co-Development Actually Means

Building a Physical AI system correctly means treating the hardware and the software as a single design problem from the first conversation. The power architecture, the communication protocols, the physical form factor, the sensor suite: these are not decisions you make and then hand to the software team. They are decisions you make with the software team, iteratively, because the answer to each one changes the answer to the others.

This takes longer up front. It costs more up front. It also produces a system that actually does what you need it to do, at the performance levels you need it to do them, without the eighteen-month rebuild that follows the discovery that your off-the-shelf platform has a ceiling you cannot engineer around.

Most founders building Physical AI are not building a sanding robot. They are building something that navigates dynamic environments, makes complex decisions, and needs to perform reliably across conditions that no off-the-shelf platform was designed for. For those founders, the companies that will win are not the ones that found the fastest shortcut to a demo. They are the ones that understood early enough that the hardware and the software are the same bet, and made it together.

Co-development is not the harder path. It is the only path. The shortcut has a price tag, and it comes due about eighteen months after you were certain you had avoided it.