Physical AI: The Model is Never the Hard Part

What actually breaks when you commercialize Physical AI

In early 2020, a Physical AI company I had spent five years building lost 87% of its revenue in a single quarter. The product worked the entire time.

Nothing about the product had changed. We built a knowledge graph for industrials and continuous manufacturers: we programmed physics into the models, made data across 100+ databases queryable within seconds, and helped industrials predict equipment failures months before they occurred. The models worked! The platform was in production across refineries, chemical plants, and manufacturing sites. Our customers still needed exactly what we had built.

What changed was that they stopped running their plants because of the pandemic. We priced on usage, so when throughput went to zero, our revenue did too. I had made a pricing decision four years earlier that felt like good alignment: we get paid when customers get value. I hadn’t noticed it was also a decision to put a variable I didn’t control at the center of our P&L. We projected we wouldn’t be able to recover for ~2 years. As a growth-focused venture business, we couldn’t keep operating as we were. That quarter, I laid off 85% of the company.

Right now the conversation about physical AI is almost entirely about model capabilities. Better world models. Better policies. Better sim-to-real. That work matters, and it is getting cheaper and better fast. But capability has rarely been what stopped these companies. What stops them is that verifying a physical system is expensive and unglamorous, and that the commercial structure of selling into the physical world breaks in ways software people do not expect.

Here is what actually breaks.

Capability isn’t the bottleneck. Verification is.

In language models, evaluation is cheap. You generate an output, a human reads it, and you know within seconds whether it’s good. You can do that ten thousand times in an afternoon.

In the physical world, none of that holds. Judging whether a system behaved correctly often requires the physical world to cooperate: the right lighting, the right clutter, the right unlucky combination of events that happens once every ten thousand hours. You can’t easily reproduce the failure. Sometimes you can’t even confirm it happened. And no benchmark tells you a system is safe in an environment it has never seen, which is the only question that matters before you deploy.

This asymmetry shaped almost everything about how we shipped computer vision at Amazon. The bar before release was far higher than anything I’d experienced in software, for an obvious reason: you cannot hotfix a device sitting in someone’s living room. You need to be unbiased. You need to handle an “infinite” long tail of scenarios. A bad web deploy is embarrassing for an hour. A perception bug on a robot navigating a home is in the world, in someone’s house, until you can ship a firmware update they may or may not install.

The economics of getting to that bar are what pushed me into synthetic data. Real-world collection works for the common case and fails for the tail. You cannot pay enough people to stage every configuration of a stairwell, every failure mode of a pet crossing a sensor, every combination of glare and occlusion that a camera will see across millions of homes. So we built simulated environments to generate training and evaluation data at scale, because that was the only way the numbers worked. Today’s world models and compute have made this cheaper. But when you look at driverless cars, which train on synthetic and real-world data, you can see that it still doesn’t handle all the issues in such critical systems.

But here’s the part that took me longer to understand. Simulation makes trial and error cheap, and the more you lean on it, the more your evaluation inherits your simulator’s blind spots. You end up with a system that performs beautifully against the world you modeled. Every physical AI company running on synthetic data faces a version of this: your verifier is only as honest as your generator, and both were built by the same team with the same assumptions.

A timing problem stacks on top of it. Software lets you decide late. Hardware forces product decisions eighteen months early, when the sensor suite and the silicon freeze. Compute, thermal, and memory budgets set hard ceilings on what the model can be, and different products in the same portfolio ship different sensors, so the same capability has to degrade gracefully across hardware you chose before you knew what your models could do. You are making product commitments against a model roadmap that doesn’t exist yet.

None of this is a reason to be pessimistic about physical AI. It’s a claim about where the value accrues. Capability is getting cheaper on a steep curve. Verification is not, because it’s bounded by physics and by liability rather than by compute. Whoever solves verification for embodied systems (cheap, honest confidence that a system will behave in a place it has never been) captures more value than whoever has a marginally better model. Verification is what gates deployment, and deployment is where the revenue is.

Physics writes your roadmap, and it locks earlier than you think

Software product management assumes you can decide late. You can ship a feature in six weeks, watch what happens, and change course. The cost of being wrong is a sprint.

Hardware inverts that. The sensor suite, the compute, and the thermal envelope freeze roughly eighteen months before the product reaches a customer, and everything downstream inherits those choices. That means the most consequential product decisions are the ones you make before you know what your models will be able to do.

At Amazon, I was choosing capabilities against silicon that had already been selected. Compute, thermal, and memory budgets set hard ceilings on model architecture — not preferences, ceilings. A model that ran well on a bench with a GPU was irrelevant if it couldn’t fit in the power envelope of a device that also had to stay cool in someone’s hand. And because a portfolio ships at multiple price points with different sensors, the same capability had to work on the flagship and degrade gracefully on the device with one fewer camera and half the compute. You don’t get to say “this feature requires the good hardware” when the customer bought the cheap one and saw the ad.

The uncomfortable part is that you’re forecasting your own model roadmap. When silicon freezes, you’re implicitly betting on what your team can train and ship a year and a half later. Bet too conservatively, and you’ve capped the product below what the technology can do by launch. Bet too aggressively, and you’ve promised a capability your models can’t deliver on hardware that can’t be changed. I’ve been wrong in both directions, and the aggressive error is worse, because the conservative one just leaves value on the table while the aggressive one leaves you shipping something that doesn’t work.

This leads to a specific discipline. Hardware constraints aren’t an engineering detail to hand to product as a requirements document. They’re a product input, and they need to be in the room when you’re deciding what the thing is. Teams that treat them as someone else’s problem tend to ship exactly on schedule and ship the wrong thing.

Every deployment is bespoke until the model of the world is shared

Every plant is different. Every home is different. Every warehouse, substation, and production line is different. That is not a temporary condition to be engineered away; it is the nature of the physical world, and it is why physical AI companies drift into consultancies. The first deployment teaches you a great deal. The second teaches you almost nothing reusable, because you built the first one against the specifics of one site. The escape is not FDEs (aka better service delivery). It is a digital model of the world that generalizes.

At Element, we built a digital twin of industrial operations, and what I underestimated was how much of the work was in the representation rather than the analytics. The models were the easy part. The hard part was that the knowledge required to interpret a plant lives in artifacts nobody thinks of as data: SCADA drawings, control schematics, tag hierarchies with thirty to sixty years of accumulated naming conventions, P&IDs, equipment manuals. That is where an engineer’s understanding of the plant actually resides. Until you can ingest that and turn it into a structured model, every deployment starts from zero, because your software has no idea what a pump is, what it’s connected to, or what a moving reading means.

Three twins, and why one is never enough

There are really three kinds of digital twins, and I’ve watched companies fail by building one and assuming it was sufficient.

A physics twin encodes how the system behaves according to first principles: thermodynamics, flow, mechanical relationships, the actual governing equations. It can extrapolate to conditions you’ve never observed, which is exactly what you need for extreme scenarios. It is also expensive to build, hard to calibrate, and wrong in the ways all models are wrong.

A data twin encodes what the system has actually done: historical sensor streams, failure events, operating envelopes (from engineering designs (how it should operate) and how it was constructed (what actual equipment can operate and how its been maintained). It is empirically grounded and cheap to grow. It is also blind to anything that hasn’t happened yet, which means it is worst precisely where the stakes are highest.

A spatial twin encodes where everything is and how it relates geometrically: topology, adjacency, physical layout, what’s upstream of what. At Amazon, I built one of these for the home (a live spatial model from SLAM and sensor fusion), and it mattered because it grounded everything else. A reading without a location is trivia. A reading you can place in space, adjacent to other things, becomes inference.

Each of these is useful alone, and none of them is sufficient. A physics twin without data can’t be calibrated against reality. A data twin without physics can’t reason about a scenario outside its history. Either one without a spatial twin can’t tell you that the anomaly in sensor A and the anomaly in sensor C are the same event propagating through connected equipment.

And here is the failure mode: when you build them in isolation, you get bespoke deployments by construction. Each twin ends up encoding site-specific assumptions, and the integration between them becomes custom work at every new customer. Repeatability comes from the layers of abstraction between the twins — a shared representation that lets you swap in a new plant’s schematics, a new sensor history, and a new layout, and have the same product work on top.

Sensor data and simulated data are not the same, and you need both

There’s a reliability asymmetry here worth being explicit about. Sensor-generated data is real but sparse, noisy, and biased toward normal operation, because most of the time nothing is wrong. Simulated data is abundant and covers scenarios you’d never survive collecting, but it is only as honest as the model that generated it.

I ran synthetic data generation at Amazon for exactly this reason: real-world collection could not cover the long tail at any price. Simulation was the only way to cover rare and dangerous cases. But the trap is that the more you train and evaluate on your own generated data, the more your system becomes excellent at the world you modeled. Your verifier inherits your generator’s blind spots, and both were built by the same team with the same assumptions.

The discipline that keeps this honest is boring and non-negotiable: explicit evals that separate what you learned from simulation from what you validated against reality, deliberate simulation of extreme and adversarial scenarios rather than more of the average case, and active watching for overtraining on your own synthetic distribution. If your model’s performance on simulated data is diverging from its performance on real data, that gap is your actual uncertainty, and it should be a number someone owns.

The question that matters before you scale

The question is not “can we make this work for this customer.” You almost always can, with enough engineers on site. The question is “what generalizes across customers on day one” — and the answer lives in the shared model of the world, not in the analytics on top of it.

If nothing generalizes, you don’t have a platform. You have a services business with a software logo and a valuation that assumes otherwise.

Pilot purgatory is a pricing problem, not a product problem

Look at almost any physical AI company’s deck, and you’ll find a wall of logos. Ask how many are in production, and the number gets smaller, and the answer gets longer.

The confusing part is that the pilots usually succeed. The technology works, the champion is delighted, the results are real. And then nothing happens. Six months later you’re running another pilot with another division of the same company, and you’ve hired two more forward-deployed engineers to service the ones you already have.

Physical AI is unusually prone to this for three structural reasons. Every site is genuinely different, so expansion doesn’t look like a rollout to the customer: it looks like starting over, which means another pilot. Production carries safety and liability weight that software doesn’t, so the step from “this works in the test bay” to “this runs the line” is terrifying in a way that a SaaS rollout isn’t. And the person with the pain usually can’t sign. The plant manager or operations lead who desperately wants this is not the person with a budget, and the person with the budget is measured on something else entirely.

The instinct is to treat this as a product problem: the pilot didn’t convert because we need more features, better integrations, more proof. I spent a year at Element Analytics (the industrial knowledge graph company we created) believing that, and I was wrong. It was a pricing and packaging problem, and I owned it.

Free pilots are the trap

A free pilot feels like removing friction. It’s actually removing commitment. Nobody’s budget is on the line, so nobody’s performance review depends on it working, so it gets the attention of a side project: genuine enthusiasm, no consequences. Innovation-team budgets are where pilots go to be admired and die.

Initially, we switched to paid pilots so they had “skin in the game.” But nothing changed. Then we switched to outcome-based contracts (getting paid for our insights), but that just made us a services company where we had to win a bid for every problem a customer had; it wasn’t repeatable.

The escape is counterintuitive: get a small real contract instead of a large one. Twenty to fifty thousand dollars. Signed, with an MSA.

Money buys you three things a free pilot structurally cannot produce. It creates a named owner, because someone had to justify the spend and now has skin in the outcome. With the MSA, you now have a template that lets you scale without having to get a second contract signed (a pilot requires a pilot purchase and an enterprise purchase). And it forces an actual success criterion, because you can’t ask for money without answering “for what.” A free pilot’s success criteria are aspirational. A paid one’s are contractual.

The other half is setting the price. Below the procurement threshold, so a line-of-business director can approve it alone. That single constraint removes the twelve-month gauntlet: no committee, no security review cycle, no annual budget planning process. At Element Analytics, the shift from bespoke deals that required a procurement process to a productized offer a director could sign took our sales cycle from twelve months to three. That was the inflection point for the entire company, and none of it was a technology change.

None of that works, incidentally, without the shared model of the world from the previous section. A productized offer at a low price point is only viable if you can bring a new customer’s site online without a team of engineers encoding it by hand. Repeatable pricing and a repeatable representation are the same problem viewed from two ends.

The small entry deal is also not a small deal. Those twenty-to-fifty-thousand-dollar contracts had a fast path to seven figures, because once you’re in production with a named owner and demonstrated value, expansion is a budget conversation rather than a new sale. You’ve already cleared the hard part, which was never the money — it was being real.

Where usage-based pricing earns its keep

This is where consumption pricing is genuinely powerful, and it’s where people get it backward.

Usage-based pricing is an excellent land mechanism precisely because it lowers the perceived risk of saying yes. A buyer committing to an annual license has to defend a number they’re not sure about. A buyer paying for what they use is making a much smaller decision, and the internal argument they have to win is correspondingly smaller. That compresses your sales cycle and gets you out of the pilot conversation and into a real contract.

It also aligns you with the customer at exactly the moment when trust is lowest. Early on, they don’t believe your numbers. Charging for consumption says: don’t take my word for it, pay in proportion to what you get.

So use it. Get in the door on consumption, get the MSA signed, get into production with an owner.

Just don’t stop there; which is what I did, and it’s the subject of the next section.

Pricing structure is a risk decision, not a monetization decision

Everything I just said about consumption pricing is true. Here is what it leaves out.

Consumption pricing is a land motion, not a revenue architecture. It is the right way to get in the door and the wrong way to stay there. My mistake at Element was not choosing usage-based pricing, but it was not converting off it once we had earned the right to ask for a floor.

We priced on platform usage, which tracked how much our customers were actually running their operations. For four years, that felt like the most honest arrangement possible. We got paid in proportion to the value we created. Customers never argued with an invoice. Our revenue grew as their production grew, which meant our incentives were genuinely aligned with theirs.

Then in 2020 their production stopped, and we discovered what we had actually built.

Revenue fell roughly 87% in a quarter. The platform was still running. The models were still accurate. Every customer still needed exactly what we had built, and most of them said so. But we structured our revenue as a derivative of industrial throughput, and industrial throughput fell to approximately zero for reasons that had nothing to do with us and that we could not influence. As we projected out what it would take to recover (wide-scale testing + vaccination where kids could go back to school), it was clear in March 2020 that the earliest we could “end” the lockdown and get to some level of manufacturing normalcy was not until August 2022.

The second thing I learned that quarter is that our diversification was fake. Twenty-plus Fortune 500 customers across refining, chemicals, and manufacturing look like a diversified book. It was one bet wearing twenty jerseys. Every one of those customers was driven by the same underlying variable: physical production volume. So when that variable moved, the entire book moved together. Logo diversity told us nothing about correlation. You could argue that no one predicted a once-in-a-100-year pandemic, but it was still a systemic risk we didn’t address.

Three things I’d do differently

Hybrid, not pure consumption. A committed platform fee or annual minimum, with usage on top. I assumed enterprises would resist a floor, and I was wrong: enterprise buyers want budget predictability at least as much as you want revenue predictability. A finance team would rather commit to a known number than explain a variable line item to their own leadership every quarter. If sixty percent of that $40M had been contracted minimums, we would have gone to $25M instead of $5M. That is a survivable company. The one we had was not.

Diversify by risk factor, not by logo. The question isn’t how many customers you have or how many industries they span. It is: what single external variable, if it went to zero, takes the company with it? If you have an answer and it’s one variable, you either hedge it contractually or you deliberately acquire customers driven by something else. Most companies never run this exercise, because the customer list looks reassuring on its own.

Consumption revenue is not ARR. We called it ARR. Our board called it ARR. Everyone treated a number that could evaporate in ninety days as though it carried the durability that the word “recurring” implies. The honest practice is to report and manage contracted revenue and variable revenue as two separate lines, because they justify completely different decisions about hiring pace, burn, and how much cash you hold. Calling it all ARR is not a reporting nicety. It’s a mistake in how you run the company.

The part that took longest to see

A demand shock and a pricing-model shock look identical on a revenue chart and require completely opposite responses.

If demand for what you do has collapsed, change what you do. If demand is intact and your pricing structure simply failed to capture it, change how you charge and keep building.

In our case, demand was arguably higher. Fewer people were allowed on site, which made remote monitoring and a digital model of a plant more valuable, not less. But our revenue said the opposite, and revenue is what you make decisions with. We read the chart as the market and cut accordingly. I still think the cut was right given the cash we had. I’m less sure it was right given what was actually happening in the market, and I couldn’t tell at the time because our pricing model had destroyed our ability to distinguish between the two.

That’s the real lesson, and it’s why I now treat pricing structure as a risk decision that also determines revenue, rather than a revenue decision that happens to carry some risk. Land on consumption. Convert to a floor. Know which variable you’ve bet the company on, and make sure you chose it on purpose.

The technology is usually the easy part

Everything so far has been about verification, representation, and pricing. Those are the failure modes I’ve spent the most time inside. But the most consistent surprise across fifteen years is simpler than any of them: the part of the work that felt hardest going in was almost never the part that determined whether we won.

At Ring, we built a business called Virtual Security Guard. The concept was straightforward to describe and genuinely novel to deliver: computer vision would flag an event at a customer’s property, and a remote professional responder (sometimes via an Astro robot dispatched into the space) would respond in real time. We took it from a blank page to eight-figure ARR in a year, with churn under five percent and tens of thousands of customers within months of launch.

The perception stack was not what kept me up at night. It was hard, and my team was good, and it worked.

What was hard was everything that had to exist around it before anyone would pay for it. Pricing a service nobody had bought before, with no comparable to anchor against. Standing up an in-house inside-sales organization, because the product needed explaining and existing channels couldn’t do it. Building a distributor channel to reach small operators we’d never reach directly. Designing onboarding for customers who had to trust the system before they’d let it run. And the hardest piece by a wide margin: designing operating processes for a third party acting on a customer’s behalf inside their home, which meant treating fraud, privacy, and legal exposure as product problems rather than compliance paperwork.

That’s the general lesson. When your AI acts in the physical world, you are not shipping a feature. You are shipping an operational system with liability attached.

A wrong recommendation engine shows someone a bad movie. A perception model that’s wrong dispatches a stranger to someone’s door, or doesn’t dispatch anyone when it should have. Those are different categories of product, and the second raises questions software teams rarely have to answer. Who is accountable when it’s wrong? What does the operator see, and what are they permitted to do? How do you prevent the system from being abused by the person who bought it? What do you tell law enforcement, and what do you refuse to tell them?

None of that can be retrofitted. This isn’t a compliance review you schedule before launch. It shapes the product surface, the interface, the data model, the staffing model, and the price. We designed those processes into the product from early on, and I’m certain that’s why it scaled in a year rather than dying in legal review.

This connects to the verification argument from earlier in a way worth naming. The reason evals matter so much in physical AI is not academic rigor. It’s that when a system acts in the world, someone will eventually ask you to prove it behaves correctly: a customer, a regulator, an insurer, a plaintiff’s attorney. Your eval framework is the artifact you hand them. Teams that treat evaluation as an internal engineering concern discover late that it was actually a commercial and legal asset they failed to build.

The practical implication for anyone building here: staff the trust and operational layer at the same time as the model, not after it works. It is on the critical path to revenue; it takes longer than you think because it requires judgment calls nobody has made before, and it is the piece that a competitor with a better model cannot easily copy.

Four questions I ask now

None of this made me pessimistic about physical AI. It made me specific. When I look at a company building in this space now (or think about what I’d build myself) I ask four things, and the answers tell me most of what I need to know.

What is the verifier, and what does confidence cost? Not “is the model good?” How do you know it will behave in a place it has never been? What does that assurance cost per unit of deployment? And does that cost fall as you scale or rise with every new site? If the answer is that a senior engineer flies out and watches it for a week, you have a services business with an unpriced verification problem.

What generalizes on day one? Not after a pivot, not once you’ve built the platform. What is the shared model of the world that lets customer number five look like customer number four instead of customer number one? If the honest answer is nothing yet, that’s fine. But know that you’re pre-product, whatever your revenue says.

Who is the buyer with both budget authority and urgency? In physical and industrial markets, these are frequently different people, and that gap is where pilots go to die. The plant manager has the pain. The VP has the budget and different incentives. If you can’t name someone who has both, you don’t have a go-to-market motion. You have a series of interesting conversations.

What happens to revenue when demand goes to zero? Ask it literally. Model it. If the answer is that you collect nothing, you have taken your customers’ volatility onto your own balance sheet, and you will find out how much of it you absorbed at the worst possible moment. I know what that costs.

The capability curve is falling fast, and it will keep falling. Models that seemed remarkable eighteen months ago are commodity infrastructure now, and the same will be true of today’s frontier in another eighteen. That is genuinely good news, and it also means capability is the wrong thing to build a durable advantage on.

What isn’t falling is the cost of proving a physical system is safe in a place it has never been, the difficulty of building a representation of the world that generalizes across sites, and the work of making an AI system that acts in the world something a customer will actually sign for. Those are bounded by physics, liability, and organizational reality rather than by compute.

The teams that win the next decade of physical AI will be the ones who treated verification and commercial structure as first-class engineering problems from the beginning. Not as things to figure out once the demo works. The demo working was never the hard part.

About the author

Sameer Kalwani has spent fifteen years building AI that operates in the physical world. He founded Element Analytics, an industrial digital-twin platform that turned SCADA drawings and control schematics into a structured plant model, and scaled it from an empty repo to over $40M in ARR with twenty-plus Fortune 500 customers. At Amazon Lab126, he owned computer vision across the device portfolio, including the Astro home robot, Echo, Halo, and the Ring drone, and led the synthetic data, SLAM, and world-modeling programs behind them. As GM of Ring’s Virtual Security Guard, he built a new business where computer vision dispatched human operators and robots, taking it from a blank page to eight-figure ARR in a year. He is a four-time founder, currently building Enrich, and an electrical engineer by training.