Explore the live Open Weight Power Atlas here:

In my last Second Order analysis “Who Can Afford to Make Intelligence Cheap”, I thought through how open models don’t necessarily reduce/eliminate market power. The change the concentration through which this power gets captured.

Continuing developments in this space led me to want to keep testing so I built out the Open-Weight Power Atlas to keep an eye out on the topic - if capable models increasingly proliferate, become open-weight and interchangeable, where does the scarcity and so power, move?

The Atlas is a visual map of relevant open-weight model families. I use it to represent and understand which model families are becoming infrastructuer, which capability breakthroughs are actually converting into ecosystem gravity, how portable is intelligence really, who benefits when these models proliferate, and where the re-dependencies form around them.

Open Weight Power Atlas

Share

I’ve started with about 50 active model families and five different ways of looking at the structure.

• Gravity: Which families are becoming infrastructure?

• Conversion: Which technically strong models are actually accumulating ecosystem power?

• Liquidity: Does downloadable really mean movable?

• Power: If the model becomes cheaper, which scarce assets will benefit?

• There’s also Motion - which I’ll update about once a month - what’s changed, the mechanism, and what I’m watching next.

This is definitely not a model leaderboard, there’s a lot of really good places for that which I use often. I’m really interested in the structure around these models. For example, open weights can broaden the access, while gravity still concentrates around a few families. A sovereign model can create good local capability but retain upstream dependency. A model publisher may give away intelligence because the thing it actually monetizes is silicon, cloud, devices or distribution (complements).  I’m trying to make more of these relationships visible in the Atlas. 

I’d love for folk who work around models, AI Infrastructure, investment, or Enterprise to give it a try and tell me which of the filters/lenses gave you the most useful insight, and things to watch for in the next monthly update. So it helps me understand how to evolve it next.

Pallavi Chari,

Really? I read through the news again, and it seems to be blurring some lines with that statement - but what MHS is, is actually more interesting than its positioning. Anthropic may be doing itself a disservice with its current positioning.

This is the line in their announcements that made me go - really?

Each device tends to have its own programming interface, and so far there has been no standardized way to integrate them. (Anthropic announcement MHS)

As someone who has worked in the industrial tech space for a while, that just seems way too broad, so i started reading up on it. Here’s what I think.

Short version upfront:

Anthropic just launched the Model Hardware Standard (MHS) which is a way for Claude, to operate real physical equipment: microscopes, robot arms, lasers, lab machines. Anthropic’s pitch is that there has been no standard way to integrate this kind of heterogeneous hardware for AI agents.

Now that sweeping claim claim needs some dissecting. The industrial world has had ways to connect machines together for decades. What is new however, is that MHS is specifically built for an LLM, not for traditional software. The metrics Anthropic released have also been pretty solid - an 8 hour lab integration that used to take weeks, and a laser-recovery script that went up from 58% 99% reliability.

There are a lot analyses and posts on this topic which roughly all seem to be implying - “Anthropic invented something from nothing.” That’s too broad a brush and not completely accurate.

I found the MHS to be narrower (happy to be shown I’m wrong as I’m still trying to figure it out) BUT also that narrower piece to be more useful than another (!) standard way to integrate hardware.

Anthropic has built a cheap shortcut through what is a genuinely expensive, boring problem, aimed at AI agents.

What has Anthropic actually built

Here’s how I think it works:

• Each machine gets a driver: so a universal translator which takes whatever proprietary language a machine speaks and converts it into two simple commands: read (check X) and write (change Y).

• Devices announce themselves on the network, so an AI agent can find them automatically, instead of someone hard-coding a connection.

• The driver also carries natural language notes about the machine like how much does a robot arm weigh, what are its safety limits, etc. The kind of things that used to live only in a PDF or in a technician’s head.

• From all of this, the MHS auto-generates a cheat sheet describing the device, what it measures, what can be changed, and where the limits are.

• The AI agent can then control the device in three ways: A tool-connection standard (MCP), command line, or through code.

MHS is at the same time being a translator, a phone book (device discovery), a cheat sheet (device description), a control panel, and a way to turn what the AI learned into a fixed, repeatable script.

The name Model Hardware Standard however is suggesting a hardware standard. What it actually is, is one layer up: a translation layer that helps an AI understand and operate machines to work as Business as Usual/how they already do. The robot’s own internal software doesn’t change. Someone still has to build the translator for each new machine - Anthropic’s early partners are doing that now, one instrument at a time (CMU, genentech, Washington uniersity, QIAGEN…)

And I didn’t find anything when I searched for whether Anthropic is building this together with the organizations that are already common in this space (OPC UA and WoT for e.g.). Its list has labs, robotics companies, and cloud providers, but not existing standards bodies. Is it building as an island? Or is it just moving faster than they are?

For anyone who is interested - who else already does this?

• OPC UA: One of the closest things industrial automation has to a common machine language. Decades old, pretty exhaustive, used by manufacturing worldwide. The industrial world’s version of an electrical outlet standard. If a machine speaks OPC UA, I’d expect most industrial software already knows how to talk to it.

• W3C Web of Things (WoT): A simple, web-style version of the same concept: describe a device’s readable state, its available actions, and its notifications, the same way a website describes its own structure.

• ROS: Widely used open robotics software ecosystem. Less about connecting a robot to the outside world and more about how the robot’s own brain and body parts talk to each other. Goes much further into robot execution than MHS, though many commercial robots still run proprietary runtimes underneath.

• SiLA 2: OPC UA’s purpose-built lab equipment cousin.

• MQTT: Moves messages between devices quickly and reliably, but something else has to supply the meaning.

• MCP (Model Context Protocol): Anthropic’s own standard for connecting AI models to software tools. MHS gives physical devices a common agent-facing representation that can be reached through MCP. While Anthropic created MCP, it is an open protocol so another ecosystem could potentially go the Agent>MCP>ROS/Vendor API/OPC UA way

Every one of these already does some version of what Anthropic says doesn’t exist: describe a machine, expose its state, let other software ask it to do something.

While the claims are broad/ more marketing maybe - but if we narrow them down, they solve a really good AI specific problem.

The real way to say “No standardized way to integrate them” is that there’s no standard built specifically for AI agents, that has actually gained traction across the broad range of odd, older equipment out there. Maybe that’s less glamorous, though a very real gap.

Anthropic also says - “No bespoke translator program needed.” Well…the MHS driver is the translator. CMU researchers wrote one up from scratch for every single instrument. Good news is that MHS makes it happen once per device instead of once per pair of devices trying to talk to each other. While this is really useful, It’s not the same as not needing translation.

“The reference file gives the AI “everything it needs to know.” The reference file can tell Claude what the machine exposes, what changed, and what limits apply. It can’t contain every piece of physical or operational knowledge the agent may need. MHS can package machine context well, but some of the understanding still has to come from the model, a human, or additional domain knowledge.

“Safely operate physical devices” is the design goal. Anthropic will be using the preview phase to develop safety evaluations, permissions, and best practices around physical operation before opening the standard more broadly.

Whether in preview or not, how much of that safety can live in an agent-facing layer, and how much must remain in the certified controllers, limits, and runtime systems underneath it?

Let’s look at the MHS pilots to figure out what MHS is really solving for

in the CMU lab there was a liquid handler, a plate reader, a robot arm, and cameras spread across three different computers 1/ one controlled by dropping files into a folder, 2/ one running ancient Windows software 3/ one with no clean programmatic API. Building the AI-driven version took 8 hours. A normal vendor-built setup takes a few weeks.

MHS didn’t beat out OPC UA or another modern standard. It fought out file-drop, ageing Windows software, and a machine with barely more than a screen. That’s a very different, but a very common, challenge.

At the University of Washington, one researcher connected 6 lab instruments in less than a week and used it for remote monitoring and running experiments. This is pretty cool, even though this is still early-stage and more complex setups will need more work.

The theme is that these machines mostly had no shared standard to begin with.

From my perspective, MHS’ main competition isn’t existing standards, it’s the duct tape which comes with having none. A thin, cheap translator + plain-language notes is much less painful than months of formal integration work that is usually required. Or the alternative is someone moving lab plates by hand at 4 a.m.

So now this kind of thing exists. What does that mean?

What if the incumbent standards can absorb the agent layer? In fact, a few months before the MHS launched, the OPC Foundation has started converting its entire library of specifications into AI-friendly formats. It aims to become the semantic layer between agentic AI and industrial automation. WoT is also evolving what is already an easily digestible device-description model to do similar things.

Now if either the OPA UA or WoT deliver a clean,bridge from their existing systems straight to an AI agent, a lot of the reason to use MHS in a modern factory can disappear. While Anthropic has the advantage of moving first with an agent-native hardware layer, but OPC has the harder-to-copy advantage of having theinstalled base of industrial adoption. So will Anthropic end up serving a different market, or will it be a best-man-wins parallels, or will they converge, or will we have even more of a standards maze?

Within the standards world, honestly, adoption matters more than purity. Once enough labs and manufacturers build their tools, skills, and workflows around one system, switching is expensive, even if another approach is technically cleaner. If MHS spreads fast through labs and startups over the next year, that itself can give it an advantage. Small labs and startups especially can benefit a lot, as they can’t afford months of custom automation engineering but MHS can lower the price barrier enough that it expands who gets to run automated, round-the-clock experiments: not just big pharma and elite university labs, but smaller ones too.

The MHS developments, along with what other bodies are doing can go in a few directions.

MHS could be one more standard manufacturers are expected to bolt on top of everything else they already need to support. I don’t think any manufacturer would want to do this!

MHS could become an affordable no-frills way to connect fragmented, older equipment - the file-drop folders and dead-GUI machines of the world. This would be very valuable independent of what OPC UA or WoT do.

This is what I’m hoping happens. Where a mature standard already exists, MHS should build on it, not replace it. Where nothing exists, it can fill the gap cheaply. There have been enough industrial standards wars. A smaller, clearer view of a machine than traditional software provides is useful enough, and everything more rigorous continues running underneath it as is.

Description isn’t Execution. None of this is a runtime.

• MHS = what is this machine, what can it do, how can an agent ask it to do something

• Robot runtime, planner, PLC controller = how does the system actually do it safely and on time

In the Anthropic’s QuEra example, Claude used MHS to work through a laser recovery problem and achieved success in almost all trials but the finished process did not mean Claude controlled the laser. It became deterministic Python and ran without the agent. Explore high, execute low.

MHS’ strongest value proposition is the place where an agent gets a simplified view of the physical world.

It sits across the network of the existing machinery. OPC UA has the deep industrial semantics. WoT describes describe devices and capabilities. ROS and other proprietary runtimes handle robot execution. MQTT moves messages. Controllers act deterministically…where a mature standard is already existing, MHS can translate or compress it so agents can reason about it. Where nothing exists, it wraps around it directly.

I don’t think we need another standards race, but I do think in a field like Physical AI, we need a little more collaboration.

I’d like to avoid solving interoperability at the physical layer, just to create another interoperability problem one layer up - MHS in places, an OPC-to-agent interface somewhere else, direct agent>MCP>OPAUA/vendor API/ROS in other places, other model companies having their own versions…

Autonomous machines are complex, they need both - a solid way for agents to discover and reason about physical capabilities, as well as runtimes and controllers turning requests into safe, deterministic action.

While Anthropic’s positioning may be selling a new standard, it is actually building a shortcut through the standards, APIs and assorted duct tape we already have which would be way more useful. But this shortcut needs to become more interoperable before everyone builds their own.

Pallavi Chari,

Oh an here’s a comic strip infographic because I wanted to see what AI would do to my article and this post felt like it deserved one!

I went down a rabbit hole following the money behind Frontier Models. I started with trying to better understand what seemed fairly intuitive  - why are companies making increasingly capable models open weight... and I came out with a broader question on how we are measuring competition, who can carry the cost of Frontier intelligence, where else in the value chain is the bill moving, and whether the economic support structures we see now are the path forward.

Now updated: The Open Weight Power Atlas (deep dive interactive tool on the topic)

Open Weight Power Atlas

Over the past few days, there have been some pretty revealing developments:

Nvidia is spending $7B on a deal with Poolside.ai ($6B for a non-exclusive license + $1B equity investment + over 100 engineers to accelerate its Nemotron open-weight models). Poolside remains independent. Its people and technology are being pulled into Nvidia’s Nemotron efforts.

Alibaba announced a $10.2B share sale. It’s planning to use all of the proceeds on AI - chips, infra and models. It’s doing this even though heavy AI spending brought down its Q2 quarterly profit by 75%.

Stripe agreed to buy OpenRouter for $8B. OpenRouter doesn’t build frontier models. It routes requests between them and calls itself the “Stripe for LLMs”. It was already handling more than 10T tokens a day across 400+ models, for over 10M developers and companies.

Now these look like three very different stories.

Chip company spends billions around open-model efforts, Tech conglomerate raises equity to finance just about everything from silicon to models, Payments company pays billions for the layer that helps customers choose between all those models…

But put together, they’re pointing to an open question - with all the spending, where exactly does the return on intelligence need to turn up?

So who can afford to make intelligence the cheapest may not be the company that produces it most cost effectively. It may be the company with the strongest economic system around it.

I started here - why are increasingly capable models turning up as open weights - the first obvious answer was Complements.

Nvidia sells GPUs. Meta has advertising and distribution. Alibaba has cloud and commerce. Google has TPUs, Cloud, Android and devices.

The concept of giving something away, or making it cheaper, to increase the value of something else isn’t new. It makes sense. But let’s look at the capital structure behind these model companies.

I looked at about 20 open-weight model families (because my weekends are just so interesting) to see if this is the answer. Roughly, this is what turned up:

Alibaba owning Qwen is very different from ASML investing in Mistral, which is again very different from a government supporting domestic AI capability. And different from a normal venture investor who expects the AI company itself to eventually generate returns.

There’s no one common funding model, but what shows up is how few of these open models actually sit in a simple enough loop where model profits fund repeated frontier development.

^{(X Axis - relative strength of non model pathway to revenue, Y Axis - relative economic capacity to support repeated development, Z Axis - AI Index Model scores - This is purely a subjective analysis for demonstrating the points in the article - use it directionally)}

The frontier has researchers, data, inference, massive training runs, post-training, failed experiments, networking, power and physical infrastructure. Some of those costs are falling very quickly.

But the ambition of companies building at this frontier must also keep rising.

Yesterday’s frontier is getting cheaper while staying at the frontier remains extremely expensive - it makes it harder to assume that the winner will simply be the one who has the best model - but who has the economic system that can support the next frontier, and the next one, and the one after that.

I think while Model Leader boards are useful, they don’t tell us the full story of what sits behind the models that look similar on the board. They can be products of completely different economic systems.

One company needs to make money only from intelligence..Another can make money somewhere else because intelligence gets used…A third justifies the cost through national capability…Yet another uses public equity…And another can spread costs across infrastructure, distribution and customers...

Capability of course matters. But once the models are capable enough to be substitutes for a workload, pricing, distribution, capital, and the ability to keep funding the next generation starts to matter as well,

Second Order: Open weights can reduce concentration at the model layer but increase the value of routing, compute, distribution or proprietary data elsewhere.

OpenRouter doesn’t build models at all. The more models that exist, the harder it becomes for an app developer to answer which model should handle this request? Different models have different prices, speeds, context windows, capabilities and provider availability. It has built an intermediation layer supporting 100s of models from multiple providers through one interface, processing over 10 Trillion tokens / Day. Now Stripe is paying $8B to own it.

More competition and commoditization at the model layer is creating a valuable set of aggregation points on top of it. And you’ll see it not just in training but inference -

• Fireworks Series D funding was $1.5B at $17.5B. It reports $1B annualiazed revenue and 40T+ tokens/day.

• Baseten has raised $1.5B at $13B, reporting 20x revenue growth for deployment and serving.

• Cloud providers capture compute.

• Hugging Face captures discovery and developer distribution.

• Device companies capture value when good local models make their hardware more useful.

The bill isn’t disappearing, it’s changing home.

If you own something that will be useful when intelligence gets cheaper, you’ve got your reasons to help the intelligence get cheaper.

Not to say that all roads lead to concentration eventually - Open weights will enable self hosting, clouds will compete, accelerators are growing, inference pricing is falling fast, infrastructure is getting more competitive - customers can move between models much quicker than if every application depends only on proprietary APIs.

But there is an asymmetry - some competitors can tolerate weaker economics at the model layer than others can, and that’s a significant competitive strength.

There is a counter argument though:

Models will get cheaper. But will the Frontier keep moving faster than the speed at which yesterday’s frontier gets cheaper?

Architectural efficiency of models like Arcee also come at the time that raw pre-training scaling laws are starting to face diminishing returns (Check out the post on frontier labs actively working towards post-training and inference efficiency - it’s a very dense read, but I learned a lot)

Deep (Learning) Focus

RL Scaling Laws for LLMs

Scaling is one of the most impactful concepts in the history of AI research. For large language models (LLMs), scaling has mostly been studied in the context of pretraining, where rigorous scaling laws have allowed us to clearly define the relationship between compute and performance. Inspired by these predictable trends, the LLM researc…

Read more

5 months ago · 140 likes · 1 comment · Cameron R. Wolfe, Ph.D.

Follow the return

So in this little bit of a meandering journey, I originally wanted to learn why increasingly capable models were being made open. The bigger question is how companies will keep financing Frontier AI in the first place. Giant balance sheets, infra partners, public markets, sovereign capital , and yes, complements.

These differences can change how long a company keep investing, what the model itself needs to fund, and how aggressively it can price and distribute that intelligence.

If the Frontier stays expensive, this model is the path forward to stay in the game. But if the cost structure of building frontier models is evolving as we can see from companies like Arcee - Better data with post training, RL environments, synthetic data, are some of the approaches making things more cost efficient and modular - which path accelerates/sustains, whether this migrates the cost, or lowers the capital bar remains to be seen.

If you want to keep up to date on how Power concentration can move with Frontier Intelligence open weight model developments, check out my Open Weight Power Atlas - I aim to keep it up to date at least once a month and you’ll get notifications as a subscriber to  

Pallavi Chari ,

Who Owns the Customer When the Driver Is a Machine?

Autonomy isn’t just removing the driver- it’s breaking mobility apart into different businesses.

 Customer > Marketplace > Autonomous system > Fleet operator > Vehicle.

And once that solidifies, the real value may not be in who has the best robot, but who’s controlling the demand and keeping the machine busy?

Here’re some signals :

pony.ai has expanded its relationship with Uber to deploy more than 2,000 robotaxis across Europe.

But let’s break up how the full service is being brought together.

pony.ai brings the autonomous-driving technology. Verne operates the fleet. Uber brings the riders.

Three companies doing what used to be one business.

Uber is doing the same thing in the US - it’s planning a robotaxi service, together with a Lucid vehicle, Nuro autonomy, Uber demand and Hertz/Oro fleet operations.

So the car is just one layer in a stack.

more signals from Uber: Uber is adding zip line drones to uber eats. It’s not inventing the drone - it’s deciding how an order gets fulfilled - Human courier? Home delivery robot? Drone? Eventually an autonomous road vehicle?

It’s starting to feel less like a ride-hailing company now, and more like an orchestration layer for physical mobility.

More signals: Serve Robotics has closed up its relationship with Uber Eats, but has added Grubhub and continuing to work with DoorDash.

Serve is effectively saying the robot is “portable capacity” - something that can plug into different demand networks rather than belonging to any one.

(BTW Serve is also building out small micro-depots for charging, maintenance and dispatch)

The other path: DoorDash

It works with other providers but has also built its own delivery robot, Dot, and launched its own drone programme AND - its autonomous delivery platform can choose if an order goes to a human, robot or drone.

DoorDash is saying: If I already own the demand, how much of the stack should I own underneath it too?

So what?

So far we have seen many theories on the assumption that the company with the best autonomous technology will capture most of the value.

Maybe. Maybe not.

• Someone owns the customer

• Someone owns regulatory approvals

• Someone operates and maintains the fleet

• Someone decides which machine gets which job

• And someone has to make sure that expensive physical asset is actually doing something useful

And they’re not going to be the same company.

And I’m indexing for now on that last one because at the end of the day, a robotaxi with no passengers is just a very expensive parked car, a delivery robot without orders is a battery on wheels, a drone without enough route density is effectively just infra waiting for demand.

Now - this is going to depend on whether autonomous driving becomes an Oligopoly with companies like Waymo or Tesla cornering it - in which case capacity is the main bottleneck - and will shift power to the other end - but the signals above with Pony.ai, Serve, Nuro and more (Zoox, Baidu) are saying otherwise.

So as autonomy capabilities become better and better , utilization can likely become more strategically important than who owns the clever machine itself.

it’ll give marketplaces significant power, they may also want to own more of the stack, or some robot providers could become non interchangeable - I’m veering towards - each does what they’re best at as a wider approach with a couple of behemoths integrating vertically upward or downward.

I don’t think we know enough yet what directions will succeed but im interested enough to keep following - to understand how autonomous driving can potentially rebuild the industry around an entirely different set of control levers.

i heard this line a while ago and it’s stuck - this is basically an Industrial Revolution disguised as an AI revolution.

Frontier technology is making the machine capable of absorbing increasingly more variability. The Second Order question is what that means for everything around the machine - infrastructure, APIs, standards, safety, procurement, asset design, and deployment costs. 

Better Capability is the fastest race in Physical AI right now - better perception, better hands, better reasoning, bigger data sets, and increasingly general models that learn across tasks and robot bodies.

Open any report or tech post and it likely will be heading to - if we keep making the machine smarter, it will eventually cope with the variable world as it is.

There’s less debate about what had to change around the robot to make its performance survive a normal shift, at a real site, with real edge cases.

There are only a few places where this variability can go

1/ We make the machine absorb it with better perception, reasoning, manipulation and learning. 2/ We make the environment remove it through fixtures, lanes, standard containers or controlled workflows 3/ We clearly define the operation through maps, APIs, permissions, orchestration and human exception handling.

Either a robot can get better at finding an object, or the object can arrive in a known place. We can make a vehicle handle arbitrary traffic, or operate on controlled roads. A mobile robot can learn every lift and doorway, or the building can expose a common interface…We need to figure out where that variability is cheapest, and which is worth turning into machine capability

Here’s examples from two opposite ends of this choice: Autonomous mining and Robotaxis

1. Autonomous Mining: Komatsu has commissioned 1,000 autonomous ultra- class haul truck with customers moving 11.5B tonnes. BHP’s Escondida Norte operation has 33 autonomous trucks and 11 autonomous drills are operating in an autonomous pit (30% of Escondida’s production), moving 350K +tonnes daily).

   While mining isn’t an easy environment to operate in, it’s controllable. The trucks don’t need to solve driving in the general sense. A mining operator controls access, routes, traffic behaviour, fleet interactions, maintenance and exceptions. The mine has narrowed the problem.

2. Autonomous Driving: Waymo (500K+ trips or 4M miles/week across 10 US cities). is betting on almost the opposite thing. It can’t redesign public streets around its Waymo Driver, so a lot more variability and complexity must sit inside the vehicle and its operating system.

In Warehousing, we see both strategies in one sector. Locus Robotics’ Pick and Piece AMR proposition is based on fitting into existing operations with limited redesign (17,000+ robots across 360+ sites, 7B picks and 190M hours of autonomous navigation). On the other hand, Symbotic redesigns more of the warehouse around repeatable storage and movement of cases/pallets, and uses a system-deployment model (70 deployed systems with over $22.7 billion in contracted backlog).

Locus is absorbing more variation through mobile autonomy and software. Symbotic redesigns more of the warehouse. Both are scaling.

This isn’t a smart robot versus not situation - it’s different ways of distributing complexity. A standard container can simplify manipulation. Controlled traffic systems can reduce planning. Geofences can shrink the behaviour that must be validated…

If changing an environment is cost effective, durable and shared across multiple actions, removing the variability once can be a very good investment decision. If the environment is expensive to alter, changes often, or sits outside the operator’s control, it makes more sense to pay for adaptability in the machine.

Robotics is missing some key metrics: benchmarks versus deployed variability cost

I see advertised a lot of robot counts, autonomous miles, benchmark success, model parameters and pre-training hours. I haven’t found much advertised on what it really takes to convert those capabilities into customer accepted output at a real site.

Variability Tax: Cost created by the real-world variation the system has not designed away. (site adapting + commissioning + task-specific data + human intervention + exception downtime + validation and revalidation + site-specific support) (/) (accepted outputs meeting quality, availability and safety KPIs)

Most of those indicators to the right are private, or scattered between different parties, or not measured in a consistent way.

But the balance is moving: Frontier Physical AI is attacking the machine side of the Variability Tax.

The cost of AI capability can fall very quickly. Check Stanford’s 2025 AI Index - it found that the inference cost of GPT-3.5-level performance fell 280x in 18 months.

EgoScale trained on 20K+ hours of egocentric human video and is claiming a 54% improvement over a no pretraining baseline on dexterous manipulation. NVIDIA DreamZero, a World Action Model, claims over 2X the generalization of VLA baselines on new tasks and environments, and that it can adapt to a new embodiment with 30 minutes of play data. NVIDIA’s Cosmos brings physical reasoning, world generation and action generation into the same model family…

But it’s still early days - new limits being discovered to push through to scale - it’s worth keeping an eye on both - the developments and the constraints – e.g. Arxiv’s research paper highlights inference latency can create stale actions and discontinuities; another of their papers defines a “prediction-deliberation gap - finite-horizon prediction and action generation are not enough for to handle complex embodied tasks that require global planning, cross-stage state maintenance, execution verification, and failure recovery. The pace of research and experimentation is definitely accelerated, but not yet overcome.

In the future will the balance move towards the machine more than today's deployments suggest though? Think of it this way - concrete, steel, conveyor geometry and facility layouts don’t have anything like a software learning curve. It’s not going to get dramatically cheaper to rebuild a loading area or change workstations. Software however, does get cheaper

Now while robotics doesn’t cleanly inherit that - still needs sensors, actuators, batteries, real-time control and much higher reliability than a chatbot (this is a discussion for another day). But the difference matters when considering trade-offs.

So if frontier Physical AI delivers what it is aiming for at scale, the machine side of the equation can change very rapidly. Skills transferring across embodiments, learning new hardware in hours not months, learns exception-handling in generated worlds and plans through unfamiliar, complex multi-step tasks - then we will need far less environment engineering than now. It can wipe out a whole category of demonstrations, local tuning, bespoke integration. A multi-year site redesign may become obsolete before it wears out. Today’s cheapest architecture may not necessarily be tomorrow’s. What will survive that however will still be unified operating state, permissions, common interfaces, , exception handling…

Less physical constraint, more defined operating context

If you’ve been following VDA 5050, it’s Version 3.0 is useful as direction of travel. It now supports more AMRs to plan their own routes. The shared system will still define restricted areas, one- way rules and places where a controller must grant permission but the robot gets more freedom & the environment becomes clearer about the rules.

RoMi-H by Changi General Hospital in Singapore is another example. The hospital is operating 80+ robots across its campus. RoMi-H is a proprietary robotics Middleware that provides a common layer through which robots, building infrastructure, software and IoT systems communicate. It’s robot agnostic and Changi Hospital has made parts of the environment machine readable so every robot does not have to master every lift or door on its own.

BMW’s Figure 02 pilot is in the same vein - to deploy it, BMW also needed production IT, occupational safety, process management and shop-floor logistics. it changed safety arrangements, improved 5G coverage and created standard interfaces.

The direction I see as most important is this shift from hard constraints to softer operating handoffs. A painted lane tells a robot exactly where it can move. A semantic zone tells it where it may move. A physical barrier prevents an action. A machine- readable rule says an action is not permitted.

But what about Humanoids? A bet against redesign

Humanoids are the strongest counterargument to needing extensive physical redesign - but let’s discuss this.

Many developers are highlighting physical compatibility of the human-type form factor. And in a way, the human body plan is to some extent an installed interface standard.

This does remove some physical retrofits and point integrations. But I want to highlight that physical compatibility is not operational compatibility. Humanoids will still need to rely on mapping, workflow integration, monitoring and fleet management. Being able to press the lift button is not the same as knowing whether you are allowed on the floor.

So where should we be spending the next dollar on Autonomy?

Should we buy a better model? A better sensor or hand? A standardized tote? A redesigned workstation? A semantic map?A common lift interface? Remote assistance? Better validation?

I’ve started to build out a Variability Capture Worksheet (see warehouse example below) that I think through when i get asked this question - where’s the most cost friendly way to handle a variability, and will it survive the future?

The key points are: Don’t ask the robot to solve variability that is cost effective and pointless. Don’t redesign the warehouse to remove variability that is expensive, valuable or likely to become cheaper for the robot to handle. And don’t ask perception to rediscover facts the WMS already knows.

As I come across more of these, I’ll be building out more examples - and I’m looking for more validation and discussion from folks in the space.

Leave a comment

This is a co-design problem

I’ve worked with both operators and robotic providers in deployments. These are not decisions operators can make on one side of a procurement table, and robot companies will make on the other.

The operator knows which variability is valuable, what the downtime costs are, and what can change. The robot provider knows intervention rates, data requirements and what the next capability roadmap can be. The Integrator knows the commissioning effort. Safety teams know the validation needs - And that’s one reason it is so hard to understand the full burden of the variability tax - the data is split across the relationship.

Designing for robots that haven’t been built yet

Machines getting better at coping with physical variability gives asset owners another design headache - It may be a mistake to build tomorrow’s facility too strongly around today’s robot, but it may also be a mistake to assume future intelligence will solve every interface on its own - so where is the right middle - ground?

From the earlier point in this article on direction of travel with VDA 5050, I’d focus on autonomy-readiness. Connectivity, digital representations, programmable access, standard equipment interfaces, and machine-readable restrictions that will enable future machines to enter an operation without rebuilding the asset around any one vendor. Being Robot-Ready is about designing an environment that future robots can understand: what state it is in, what capabilities are available, where they may go and what they are allowed to do.

The two trend curves to watch -

1. How quickly is the cost of machine adaptability falling (very visible)

2. How quickly the overall Variability Tax of deployment falls (marginal visibility right now)

And that gives us an understanding of which strategies to adopt:

I’m still building my thinking on this topic and I want to hear from folk building, integrating or operating these systems.

What kind of variability is costing you the most today, and how are you handling it? If you are trialing or running these systems in production, what indicators are you using to see if the economics work?

Pallavi Chari

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

2 months 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 )}