Last year, a 232-foot steel booster fell out of the sky and was caught by a pair of mechanical chopsticks. Catching a booster is a hard problem — but it's one problem, solved once, in a controlled environment, by an organization that could spend whatever it took.
Commercial robotics is the opposite problem: modest tasks, performed millions of times, in environments nobody controls, at a price somebody will actually pay. While there is a list of unsolved hard problems in robotics right now, it seems like the toughest problem is one of economics.
I spent today at MACHINA Summit in Paris listening to foundation model researchers, humanoid manufacturers, field robotics operators. What follows is my attempt to synthesize where the business of robotics actually stands, written for the software people who I suspect will be moving into this industry over the next decade — voluntarily or otherwise, as AI compresses the value of pure software work.
Robotics runs on two clocks
The bit clock governs everything made of information: models, simulation, learned behaviors. It runs at AI speed, and it's genuinely astonishing right now. The Rhoda AI team described post-training a robot foundation model with just 10–20 hours of real robot data on top of internet-scale video pretraining — and beating approaches that used far more robot-specific data. Behaviors that took years to hand-engineer now emerge in months.
The atom clock governs everything else: supply chains, certification, capital equipment, trust. It runs at industrial speed, and no amount of model capability accelerates it. You cannot prompt-engineer a harmonic drive into existence. You cannot A/B test your way past a safety certification.
Nearly every confusion about robotics — every overhyped demo, every mispriced deal, every failed pilot — comes from applying one clock's logic to the other clock's domain. Let me show you where.
Is this a hardware company, a software company, or both?
The humanoid companies are building their own actuators, their own supply chains. Software people might find this baffling. Why build commodity components when you could focus on the differentiating layer and just print money like every other pure software business?
Because nobody knows yet which layer will be the differentiating one.
The PC industry offers the famous cautionary tale: IBM outsourced the processor and the OS, keeping the "hard part" — the machine. Within a decade, the profits had migrated to Intel and Microsoft, and the machine was a commodity. The intuitive prediction for robotics: same story. Hardware commoditizes, profits pool in the foundation-model layer, owning both the hardware and the software is a trap.
The problem: that story only worked because every PC was basically the same. Intel could write one chip and it ran everything. A warehouse robot, a surgical robot, and a welding robot are not the same — they have different bodies, different motors, different physical limits. Software written for one can't just drop into another. Additionally, if hardware stays complicated and supply chains stay concentrated, the money may stay close to the hardware, not migrate to software.
When a robot company builds its own actuators, it isn't being naive about focus. It's refusing to pre-decide which layer wins. That's expensive optionality, but in a market where the profit pools haven't settled, optionality might be the only rational position.
Quality control: you can't git-revert a gearbox
Software ate the world on the strength of one economic miracle: the cost of shipping a fix is near zero. Bad deploy? Roll it back. The entire modern software methodology — CI/CD, move fast, iterate in production — is downstream of cheap reversibility.
Robotics has no rollback. AGIBOT described the brutal math of scale: a flaw invisible at 10 units becomes a statistical certainty at 10,000. And when it surfaces, you're not pushing a patch — you're dispatching technicians, recalling hardware, eating the cost of physical remediation across a fleet. The atom clock, presenting its bill.
It is worth mentioning that some classes of defect can be converted from hardware to software defects by training resilience into neural policies rather than in precision-machined tolerances. Skild AI (Fetch Robotics) made the case directly: a learned controller can adapt when a motor degrades, turning what used to be a service call into a non-event.
This is why architecture choices in robotics are secretly business-model choices. A company betting on end-to-end learned control is betting that most failures can be moved onto the fast clock. A company betting on modular, engineered systems is betting on auditability and certification.
And don't assume the learned approach wins by default. Safety regulators — who gate access to factories, hospitals, and public space — have historically favored systems whose behavior can be verified, not just observed. The fastest clock doesn't matter if the certification body runs on the slow one. This tension is unresolved, and whoever resolves it captures an enormous amount of value.
Systems integrators: scaffolding or distribution channel?
In enterprise software, systems integrators are a whole industry. Robotics doesn't have that yet. Not because the integration work isn't real — it's extremely real, every deployment requires significant site-specific adaptation — but because there aren't enough deployments to sustain a standalone integration business. The market is too thin and too early for a third party to build a practice around it.
So the robot companies are doing it themselves. They're showing up, configuring the system, training the staff, debugging the edge cases, and rebuilding the workflow around the machine. Boston Dynamics built integration, repair, and customer success teams in-house — in that order — because they had no choice. The infrastructure to support their products didn't exist, so they became it.
This is a hidden cost that gets underestimated in robotics business models. Integration isn't a one-time deployment fee — it's ongoing, it's labor-intensive, and it doesn't scale the way software does. Every new customer is a custom engagement. The margin profile looks more like a services business than a software business, at least for now.
Use cases: discovery is capital-rationed, and pricing is R&D strategy
Here is a sentence from the summit that deserves a plaque: "POCs become monuments." Pilots that impress everyone, get a press release, and never scale.
Software solved use-case discovery by making experimentation free — millions of users tried things, and the killer apps were found, not designed. Nobody at Xerox PARC predicted the spreadsheet. Robotics can't run this playbook, because every experiment costs real capital. A robot doing the wrong job isn't a failed A/B test; it's a depreciating asset and a burned customer.
This is the correct lens on Robots-as-a-Service. The charitable read: RaaS lowers the customer's cost of experimentation, buying the vendor more discovery cycles per dollar — a learning-rate intervention. The uncharitable read: it's desperation pricing that moves hardware risk onto the balance sheet of the party least able to bear it. WeWork also "bought learning rate." Notably, one humanoid company said onstage they're already rethinking the RaaS model. When the practitioners are ambivalent, you should be too.
What actually seems to work, per the operators in the room: embed with the customer until you find the use case they couldn't have specified and you couldn't have imagined. FieldAI described deployments of eleven heterogeneous robots operating with no prior maps — and the valuable use cases emerging only after the robots were on site. Discovery happens in deployment. Which means deployment economics are your R&D budget.
The money: robotics is being asked to run a marathon on sprint financing
As illustrated by Zenith Shipping Company Limited, demand side is not the problem, and the numbers are absurd: roughly two trillion hours of industrial labor performed annually — capture 1% at $50/hour and you're staring at a trillion-dollar market. A 2,800-ship maritime backlog. Welding backlogs measured in football fields. Demographic curves that guarantee the labor to do this work will not exist. Only ~6% of North American factories run robotics at scale.
The problem is translation. Venture capital is a machine calibrated by software: small checks, fast feedback, ARR as the universal legibility layer. Robotics returns arrive on the atom clock — 7 to 15 years — and the industry lacks its measurement layer. There is no agreed-upon metric that tells an investor whether a robotics company is compounding or dying. Until someone builds the ARR-equivalent for machines (utilization? autonomy hours? intervention rate per task-hour?), capital will systematically misprice the sector in both directions — froth for demos, famine for infrastructure.
You'll sometimes hear a proposed fix: split the software and hardware into separate business units with different capital — venture money on the fast clock, infrastructure money on the slow one. It's elegant on a whiteboard. I'd treat it as speculative: no one has actually run this structure at scale, and splitting the stack recreates exactly the coordination tax that the verticalized players are paying to avoid. The capital-structure innovation robotics needs probably hasn't been invented yet. That's not a throwaway line — for the finance-minded readers, it's an open opportunity.
The trillion-dollar open question: does fleet data compound, or commoditize?
Everything above has a reasonably confident answer. This one doesn't, and it's the single most important uncertainty in the industry.
The bull case for incumbents: deployed robots generate training data, data improves models, better models win deployments. One company reported collecting more data in two recent months than in their prior three years. If this flywheel is real, deployment is training, the analogy to software breaks entirely, and there may be no late winners — the companies embedding with customers now are compounding an unassailable lead.
The bear case, hiding in that same 10-20-hour result from earlier: if internet-scale video pretraining does the heavy lifting and robot data is just a thin adaptation layer, then fleet data is a garnish, not a moat. A late entrant with a better model leapfrogs a decade of incumbent data collection. We have already watched this movie once: Tesla spent ten years accumulating the largest driving dataset on Earth, and Waymo — tiny fleet, different architecture — leads where it matters.
Every strategic decision in robotics — verticalize or not, RaaS or not, deploy now or wait — is secretly a bet on which of these is true. Nobody knows. The people who tell you they know are selling something.
Machina 2026: That's a wrap
The stat to remember when the next rocket-catch clip goes viral: catching one booster with an unlimited budget and catching margin across ten thousand robots in ten thousand uncontrolled environments are different sports. One is a triumph of the atom clock, brilliantly funded. The other requires both clocks to strike at once, and nobody is currently positioned for both.
The engineers who move into this industry — and I think many reading this will — won't be the ones who assume software's lessons transfer. They'll be the ones who know which lessons transfer, which invert, and which questions remain genuinely open.
Demos live on the bit clock. Businesses are built on both.