Are we starting Physical AI in the wrong quadrant
Physical AI in Production - Part II (Article 2 of 3 )
In my last post, I wrote about the economics of Physical AI - specifically the cost of safe change. The next question is the obvious one - where should we actually start?
This is the question emerging tech gets stuck on. Folks seem to fall into one of these traps - either go straight for the most futuristic use case in the room that makes for the most obvious demo, or start so narrow that it never teaches us very much.
I don’t think either is a great filter.
A better set of questions is:
What business outcome are we trying to achieve first (fix operational pain, unlock capacity, improve reliability, build future capability)
Where does autonomy improve a real bottleneck, and where will it learn fast enough to get better quickly?
This feels like a better place to start because, let’s be honest, plenty of the use cases we see in this area are technically very impressive. Far fewer are good first bets.
And because I love theories, here’re three more:
Theory of Constraints: Value comes from improving the system bottleneck
Learning curves: Some systems improve quickly because they generate a lot of repetitions and experience. An article I really liked related to Physical AI is here
Real options: The first move matters in part because of the second move it unlocks (in high uncertainty, some deployments are valuable because they expand what we can do later)
The questions to ask of any Physical AI use case:
Does it improve a real business problem?
Will it generate enough decisions, repetitions, and failures to improve quickly?
Is this strategically important to be relevant in the future?
Let’s put these theories together for thinking about practical ways to start: By quadrant.
My attempt at a Physical AI Economic Flywheel:
Horizontal axis: Learning Velocity (will this use case generate enough repetitions of decisions and feedback to learn quickly)
Vertical axis: Operating Leverage (does it improve a real business problem)
Some deployments are in the top right – they solve a real problem today and learn fast. Some are strategically important but slower to learn. Some learn quickly but don’t yet move enough of the economics today, and some are still exploratory or early engineering efforts.
ECONOMIC FLYWHEEL (Top right):
Example 1 - Warehouse flow orchestration. This is one of the clearest top-right examples I can think of. Don’t just think free-roaming robotics. I mean the decision layer around flow: task priorities, dispatch rules, congestion policies, exception routing, zone behaviour under peak conditions. It sits on top of a very real bottleneck: flow through the site. And because it generates a huge number of decisions very quickly, it learns fast.
Napkin Calculation:
A site has 30 interventions a day. At 7 minutes each, that’s 210 minutes, or 3.5 hours a day. At £45 an hour of loaded labour cost, that’s about £39,000 a year.
Now we add the expensive parts (details in my previous blog): 10 gridlock events a year, each causing 2 hours of disruption at £2,000 an hour in overtime, missed cutoffs, and rescheduling. That’s another £40,000 a year.
So, if better orchestration removes 3 gridlock events + reduces interventions by 10%, we are already into ROI. And because the system is making decisions all day, the learning cycle is quick.
Example 2 - Reduction in fleet intervention - target metric = interventions per 1,000 miles.
We have 10,000 vehicles driving 15,000 miles/year each = 150 million miles a year. At an intervention rate of 0.5 per 1,000 miles, we’re looking at 75,000 interventions a year. If each costs £50 (people time, review, handling), that’s £3.75 million a year. A 10% reduction is £375,000
The other reason this sits in the top-right is that it doesn’t just save money today. It teaches quickly. Every intervention tells us about edge cases, rollout behaviour, and where the next autonomy fix could be (Real-Options) - we are not just buying today’s savings, but a better next move.
CAPABILITY BUILDERS (Bottom Right): This is where Frontier use cases like general-purpose robotics, humanoids, and open-ended manipulation sit today. They often learn quickly, but short-term operating value is still emerging. Their early value will show up in metrics like human-assist time per task, number of validated tasks completed, recovery time post failure, rate of unknown errors, etc.
One push back often is – “humanoids are too slow.” That may well be true today for many tasks, but it’s really not the metric that matters – it’s what the economics looks like over time for the whole system before and after autonomy – does the deployed system require less and less human intervention over time, and is the range of tasks that run with limited assistance expanding?
If we pilot 5-6 humanoids working alongside people (logistics/manufacturing), Early deployments will need some human assistance – resets, teleoperation, recovery, etc.
Each robot operates 16 hours a day and needs 10 minutes of human assist/hour – 6 x16hours x 10 min = 960 minutes (16 hours) of human support. At $50 an hour, that’s $800/day or $200K/year.
Now the learning curve (accelerator use) starts to cut time – reducing interventions to half over 12 months – that reduces assist cost to $100K, while the robot is learning even more tasks, needing fewer interventions
The important point is not that they’re slower today; it’s that the learning loop is improving the system every month – and once it’s reliable in one task, it can take on even more – moving from bottom right of the flywheel to the top right.
These deployments matter because they show us what machines will eventually be able to do. They create OPTIONS. We need to start working on them now to stay competitive later.
But their path to the economic flywheel (top right) depends on learning acceleration (data, simulation, pre- trained models…) and integrating this autonomy into operational workflows (MES/SCADA, WMS, CRM) and orchestratability.
The third factor: Marginal Validation Cost (MVC)
The other factor on the chart (apart from solving a real problem now, and learning fast) that will determine scale is the cost of Marginal Validation that I talked about in my previous post – all systems need updates, new models, new policies, new behaviours – if each change is expensive to validate and deploy, improvement slows down. But when the MVC declines (better simulation coverage, system design, rollout/rollback discipline), the business case accelerates – the system is faster, cheaper to operate, and can transfer across sites/lines.
So the most interesting question now is not just where the use case sits today - It’s what is moving it right or up. A use case is not static. It moves.
This is where some of the latest developments are so interesting.
Open robot datasets, synthetic data techniques, pretrained robot models, and better workflow tooling all move use cases to the right. They increase learning velocity.
Orchestration layers, workflow coordination, interoperability across heterogeneous robots, and better integration into the actual operation move use cases up. They increase operating ability.
So going back to the question at the beginning: If I were choosing where to start, I would look for one use case that clearly sits in the top-right today, and one that sits nearby as a strategic option, where the learning matters even if the first-year ROI is different.
I’m looking for more inputs to plot. If you’ve got use cases you’re considering, I’d love to hear about where you’d place them on this quadrant and what you think will move them out and/or up.
-
Pallavi Chari, Moving Parts | Linkedin
Physical AI in Production Part I
Physical AI in Production - Part III