The part that gets swept into the broad word - “simulation” bothers me, though. It’s often brought up as important but as a single capability - mostly about simulating robot behaviour. This is a half-truth. Not because simulation isn’t critical, but that “simulation” bundles together multiple jobs that reduce different kinds of uncertainty.

Robotic simulation success is not automatically deployment success: A robotics simulator answers - can the system execute the task?. Simulation is scalable and safe; it’s a powerful environment for training, benchmarking, and large-scale data generation.

However, in simulation, we use abstractions and approximations, and those gaps can limit how reliably policies transfer from simulation into the real world (Sim2Real Gap)

What uncertainty are we trying to reduce? What kind of simulation reduces it at a cost and speed that matters for day-to-day operations?

There has been an increased sharing of starting points - open datasets, pre-trained checkpoints, and open-source stacks make robotic workflows more reproducible, and reduce the time and cost of cold starts.

Open Datasets like Open X‑Embodiment’s community dataset (1M+ n+ real-robot trajectories across multiple robot embodiments to enable cross-embodiment learning and reuse), and DROID (Distributed Robot Interaction Dataset - Open-Source Large-Scale Robot Manipulation Dataset with 76K demonstration trajectories and 350h of interaction data across 564 scenes and 86 tasks globally over a year).

There’s also LeRobot’s end-to-end library - vertically integrated open stack tooling across middleware, dataset handling, training, and inference/deployment. Then GPU-native simulation frameworks like Isaac Lab, are making training and evaluation more scalable, integrating high-fidelity physics and modularly rendering environments

These speed up how fast you can iterate on behaviour learning. But they only tell a part of the story.

A robot can pick and place, insert, tighten, spray, route correctly, or drive - and still create the wrong business result if the consequences of its actions are poorly modeled - unstable contact, material damage, thermal drift, process variation, fluid behaviour, gradual wear that accumulates over weeks, or congestion that has a downstream impact.

The problem is that these are actually different simulation problems.

Robotics simulation (learn behaviour faster): This is what most people are actively discussing in Physical AI simulations today - simulating kinematics and dynamics, contact, sensor streams, and environment interaction - so you can train and test policies at scale. It helps you learn faster, test more variations, and reduces the cost of testing on real hardware.

Physics and multi-physics simulation (understand and predict consequences): Trying to understand what actually happens to the work and the process - how is Stress distributed, how do materials deform, how does temperature change, how does tolerance shift, or how a part’s properties change under load and heat.... We need models that handle thermodynamics, mechanics, and materials engineering to represent these behaviours.

Surrogates and reduced-order models (ROMs) (make physics cost-effective and fast enough to use continuously, increase the exploration over the design-space): High-fidelity simulation is often too slow for everyday decision loops. Surrogate models can provide fast, approximate predictions. And when full multi-physics is too computationally heavy, ROMs can meet real-time requirements. Surrogates help not only in validating designs to discovering better designs through non-intuitive thinking.

This matters because, as in my previous posts, Physical AI is viable when you can change the system at scale safely and efficiently (cheaply) - so if you can model outcomes and validate changes quickly, you can iterate more safely. If you cannot, every change is expensive and slow to re-qualify - different simulation layers reduce different parts of the cost.

Let’s take the example from my previous post (where we pilot a general-purpose Robot)

• 6 robots x 16 hours per day x 10 min of human support per robot-hour = 960 minutes of support per day (16 hours/day).

• Labour Cost is £45/hour, which means £720/day of support or £180,000/year (250 working days). If we can improve policy to cut that time in half, we can save about £90,000/year.

What’s causing this need for support time in the first place?

If it’s sequencing, edge cases, or poor policy generalisation, then better robot-learning stacks and better robotics simulation reduce it. If it’s because of contact instability, deformation, changing friction, thermal drift, or tool–material interaction, we need multi-physics models to predict what will happen before you let the robot do it at production scale. And if the physics model is too slow to run frequently, we need a surrogate layer so validation is cheap enough to do so continuously rather than once/ad-hoc.

Let’s take another example where small percentages matter:

• A production line outputs 20K units/day. Holds/Misses which could be avoided affect just 0.5% - 100 units/day. Direct handling cost is about £10/unit. That’s £250,000/year over 250 days in direct cost (not including warranty, scrap, brand reputation, etc). In this example, it’s not about robotics simulation but modelling the process outcomes under variability, and doing this fast enough to explore multiple scenarios.

  ---

So when I talk to businesses about simulation-led strategies for autonomy - the question I have is - what kind of uncertainties are we trying to reduce, and which simulation jobs do we need to reduce them?

Usually it’s a combination of all three.

-

Pallavi Chari, | Linkedin

• _{Physical AI in Production Part I}

• Physical AI in Production Part II

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:

1. Theory of Constraints: Value comes from improving the system bottleneck

2. 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

3. 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:

1. Does it improve a real business problem?

2. Will it generate enough decisions, repetitions, and failures to improve quickly?

3. 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.

Example 2 - Reduction in fleet intervention - target metric = interventions per 1,000 miles.

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, | Linkedin

• _{Physical AI in Production Part I}

Moving Parts

The Physical AI ROI question isn’t the cost of the robot - it’s the cost of the next update.

I’ve been getting into a lot of discussions on Physical AI deployments, and the discussion on ROI is almost always “the Capex is the bottleneck – the robots, the sensors, the compute…

Read more

a day ago · Moving Parts

• ^{Physical AI in Production - Part III}

This has been the reasonable mental model of classic automation so far: We buy/install the thing, we validate/test it, run it for many years, cost is amortized, and savings are consistent over time.

But the more time I’ve been spending looking at Physical AI pilots and deployments across industries, be it automotive, manufacturing, or warehousing - Physical AI is not a one-off asset.

It is a system that keeps changing - and its economics are defined by the cost of changing it safely.

So I spent last weekend dusting off the cobwebs of my economics degree, and found 3 theories that resonated with me:

1. Good Old Transaction Cost Economics (The Nature of the Firm, Ronald Coase) which discusses the cost of coordinating and proving change – This theory is actually well written about in the context of AI and AI Agents (one I really enjoyed reading was this perspective on the impact of AI and Agentic AI on MROs - )

But there are a couple of other theories which I think we should also pay attention to:

2. O-Ring Theory (Kremer) - Butterfly effect of the weakest link, or one failure mode can wipe out lots of gains

3. The Power of Modularity (Baldwin & Clark) – can we structure the system so change doesn’t require proving everything again and again

So I’m spending some time on how these work with Physical AI deployments:

There’s a common pattern across industries -

the Steady state is fine , The messy days are expensive. Messy days happen more often than we want them to.

For example, warehouses have peak and congestion spirals…manufacturing cells will work great till a part tolerance shifts, and then line stops multiply…a driver assist system is great till a rare edge case triggers a really expensive intervention loop… and so on.

Bottom line - Physical AI has a great value proposition, because it targets the “messy middle” - fewer interventions, fewer stops, faster recovery, less babysitting the system and more consistency in changeable conditions -

However, I think a lot of us are using the wrong ROI framework to evaluate it - because we treat it like classical automation (capex + integration = stable savings).

Physical AI deployments want repeated updates – because the world changes, the system learns new patterns, we discover new edge cases, policies get updated, roll-outs happen in stages – and now we see Coase smile as Transaction Costs come into play

Coase’s point is that the actual cost isn’t just producing output - it’s the cost of coordinating, monitoring, and enforcing how things are done. In Physical AI, every update carries overhead. We need evidence that it improves something, proof that it hasn't broken something else, a controlled rollout, we need to monitor it once it hits the real world, and we need a way back if it goes wrong. Unlike a software feature update, some of those failures have physical consequences.

Now let’s talk about the O-Ring theory – which says that value isn’t always compounding in a system – it can be unstable because an operation is tightly coupled and one rare failure mode can wipe out a lot of gains seen from implementing the system

If we only measure averages (“throughput rose 3%”), we miss the edge economics (“one terrible day wiped it out”).

Take automotive fleets and ADAS systems: We can have ROI conversations based on sensors and compute needs, but the actual day-to-day cost is in interventions on bad days (remote support, investigations, customer handling, safety driver actions)

So the economics is actually about

what it costs to prove an update is safe, how well can we detect problems and how quickly we can roll back once we see them.

Which leads to theory three - Modularity.

And here is where we need to work with modularity economics -

A system gets cheaper to improve when you can change one part without having to re-prove the entire system.

In the manufacturing example, this will mean defining and maintaining clear safety controls, defining what stays stable vs. what can be changed, and automatically logging the right evidence to replay and compare. Without this, every update is basically a mini re-commissioning project, and we don’t drop the marginal cost of validation over time.

Another example of the O-Ring Theory is in warehousing where there is a tightly coupled flow - a jam in one zone can create knock-on delays, a bad dispatch instruction can starve the belt, a bad decision can cause gridlocks…

So is it not worth it?

Physical AI benefits are absolutely real (and I’m still on this thought train so stay with me a few more days) – we need to call out the right ROI model –

weak-links decide outcomes + repeatability is the driver of the business case. Make safe change cheaper over time, and stop changes from touching everything – this way we reduce the surprise spend category

The business case for Physical AI is basically - “Do we have a credible plan to make the next update safer and cheaper than the last?”

-

Pallavi Chari, | (Linkedin)

_{Next Read in the Series: Physical AI in Production - Part II (Article 2 of 3 )}