← All essays

Strategic Finance · Robotics ·

Robots. When Are They Going to Make My Breakfast?

A few weeks ago, I attended an event at Stanford with the topic of Humanity and AGI. There were a few companies that used the event as a marketing channel to demonstrate the capabilities of the humanoids they've built and are selling to consumers, some priced at $6,000 a piece. Two humanoids dancing on stage fell off it; one shattered the presenters' TV. When another humanoid almost fell on a person while taking the stairs to get off the stage, I wondered how close we really are to having a robot making an omelet for breakfast. With all the advancements in the AI space, why is it so hard to make a humanoid that can be invited to our homes to give us relief from activities we crave to outsource to robots the most, the house chores? As a strategic finance expert in frontier tech, I saw the performance failures of humanoids at the Stanford event as clear signals that developing robots that can actually be useful must be a very expensive endeavor. I wondered how strategic finance can get involved to help the companies in the robotics space to manage engineering challenges in a financially sound manner.

My investigative journey led me to a key conclusion that the humanoid industry has a structural bias towards spending capital where physics makes data cheap (locomotion, demos) rather than where the economic value actually lives (manipulation, hand dexterity), and closing the gap between demo-ready and commercially-ready humanoid is as much capital-allocation problem as it is an engineering one. Let me take you through the journey.

Robot

Aristotle said in his Politics: "If every tool, when ordered, or even of its own accord, could do the work that befits it... then there would be no need either of apprentices for the master workers or of slaves for the lords." The idea of having robots supporting the advancement of humanity existed in our imagination since at least 350 BC.

Isaac Asimov defined a robot in his fictional universe as a computerized, mobile machine equipped with a "positronic brain" capable of performing complex tasks and governed strictly by the Three Laws of Robotics. Practically, I see two versions of robots:

  1. Programmed Robot — a machine equipped with mechanical and electronic parts, which can accomplish a prescribed task in a physical world without the need for understanding it.
  2. Intelligent Robot — a machine that requires an understanding of the world to accomplish a prescribed task in a physical world using its mechanical and electronic parts.

In both versions, Robot is a physical, tangible object. It is instructed to achieve a task, transforming one state of the physical world into another state. However, a Programmed Robot, like the industrial robotic arms that assemble cars, does not understand what piece of a car it attaches to what piece of a car and why; it relies on humans and the operational process design. Programmed Robots don't need to make judgment calls; they operate with a clear set of instructions in a structured environment. Intelligent Robots, like autonomous cars, make judgment calls all the time. They constantly analyze the physical environment, understand surrounding objects, make predictions, create alternatives for behavior, assess the cost function of each alternative, and make a call on what action to take with safety being the primary objective.

We entered a new stage of evolution with the large language models powering functionality of ChatGPT, Claude, Replit, and other AI tools. However, understanding the unstructured physical world is extremely complicated, more so than understanding the language world. Per Fei-Fei Li's essay, A Functional Taxonomy of World Models: language models learn the statistical structure of text, while world models learn the statistical structure of space and time — how light falls on a surface, how objects respond to force and follow the laws of physics. Learning to understand the physical world requires a new codified version of the world, a different kind of data than the one that fed LLMs, a vast amount of that data, and maybe even a different kind of learning.

Hardware

Humanoid is not software, it's a physical object navigating through a physical space and interacting with physical objects. Deploying Intelligent Robots to the environment designed for humans without radically changing it is the holy grail — it will unlock trillions of dollars of value. However, that path is not without its challenges:

  • Movement. The human body has ~350 joints enabling over 200 skeletal degrees of freedom, with approximately 80 utilized for everyday whole-body motion. The human hand itself is nature's miracle with 27 degrees of freedom. Humanoid robots typically are built with 30 to 50+ degrees of freedom. Each joint is a mechanical part with sensors that must generate data for training, execute commands when in production mode, withstand extensive hours of use, and be easily serviceable. Humanoids developed for demos might not need to handle the complexity that comes with dexterity. However, for commercial applications, dexterity is one of the key drivers for customers' willingness to pay and adoption rates.
  • Power. Most humanoid platforms on the market can operate for two to four hours on a single charge. That might be okay for personal use, but not sufficient for deployment in industrial settings. A humanoid must carry its energy source inside a human-shaped body and balance that mass over two feet. Bipedal humanoids like Tesla Optimus and Figure 03 have a much broader set of use cases making them significantly more commercially attractive, but that design choice creates limitations for the size of a battery and where it can be placed without wrecking the robot's center of gravity.
  • Technical limitations. Use cases for humanoids include deployments for dirty, dangerous, and demeaning jobs. Making standard robot joints and wiring harnesses durable enough to survive these conditions adds weight, cost, and power demand. Harsh environments degrade mechanical joints quickly. Imagine what happens if a humanoid carrying hazardous material loses power or one of the knee joints malfunctions — that can cause a secondary accident with catastrophic consequences.

These technical challenges are very expensive to solve. Enhancing hand dexterity, solving for durability, addressing power limitations, and expanding versatility of deployment use cases impacts BOM, maintenance costs, warranty, replacement cycles, and cost-to-serve — i.e. TCO, which is the number the buyer actually cares about. A 2-4 hour battery life is not an inconvenience; it's a utilization ceiling that drags down ROI. In my own experience, I witnessed the consequences of engineering roadmaps designed without finance inputs, setting engineering objectives around demonstration of capabilities at the expense of investing in the actual capabilities, failing to account for full cost impact of hardware architecture in the product pricing, and scaling with negative unit economics. Those are expensive decisions that can be avoided if finance is brought to the table to partner with the C-team ahead of time.

World Model

We interact with the world through our senses. We have spatial awareness to navigate through the physical world without stumbling over objects. We recognize objects and their functional purpose even before we assign a word to that object. We have the capability to predict the outcome of our interactions with the physical environment before we execute the action.

And that's what I have in mind when I say "world model." It's not the simulated version of the world like the one you see in a video game. It's a dynamic interaction model between physical action and the state of an environment. A transformer LLM is trained on next-token prediction. A world model predicts the next state of an environment, conditioned on an action. LLM is text-in, text-out. World Model is action-in, future-world-out.

There are many competing schools of thought on how a robot should model the world. There is a Latent Dynamics Model, which predicts how an environment evolves inside a compact, abstract mathematical space — the most prominent example is Meta's V-JEPA 2. There is a Generative Video Prediction Model, which creates realistic future video frames of a scene — Nvidia Cosmos and DeepMind's Genie are instructive production examples. There is a World-Action Model, a fusion approach that blends video generation and continuous motor-control policies into a single architecture. There is also a camp that argues you don't need an explicit world model at all — Figure's Helix and Physical Intelligence's π₀ are direct vision-language-action imitation. Which approach is the most efficient and future-proof, only time will tell.

Regardless of what world model architecture is used, model training needs data, and data for training intelligent robots is not cheap: text is nearly free and effectively infinite, while physical-interaction data has to be generated through simulation, teleoperation, human video demonstration, or real robot time — all of which are slow and expensive. The most valuable stream, the action, is the one the internet can't provide. What data flywheel to build, what data to collect, what functionality that data should enable, what customers are going to pay for that functionality, and how that impacts hardware architecture and margins — these are finance questions that need answers before data consumes the capital provided by investors.

Data

The most advanced consumer-facing robotics product, in my opinion, is a robotaxi. By summer of 2024, when Waymo opened its robotaxi to all San Francisco users, Waymo had driven about 20 million fully autonomous miles on public roads vs. tens of billions in simulation. This gap is exactly the economics of physical data. And that was for modeling behavior in a constrained environment — roads designed for vehicles. Now, if we want intelligent robots to operate in space shared with humans or even come inside our house, that's a whole different game. That environment is unstructured with more ambiguous rules of behavior. The goal of an intelligent robot is not to avoid the objects, but to interact with and transform them from one state to another.

Training a humanoid takes a massive amount of data. And not just one dataset, like text used for training LLMs, but several distinct data streams, each answering a different question about the robot's understanding of the world:

  • Vision. "Where am I and what's in front of me?" Cameras on the head or torso read the scene, and often cameras mounted on each wrist give a close-up view of whatever the hands are manipulating.
  • Proprioception. "What shape am I in right now?" Joint positions and velocities, read from encoders on each motor. This is entirely internal — it tells the robot's pose without any reference to the outside world.
  • Balance and inertial state. "Which way is down, am I tipping, and am I about to fall?" The IMU measures linear acceleration and angular velocity — the same principle as a human's inner ear. Manipulation and locomotion aren't separable in a humanoid, because they share one body, one balance problem, and one power budget.
  • Force and torque. "What is pushing on me, and how hard?" Where proprioception is not designed to understand contact, force and torque are entirely about the boundary between the robot and everything it touches. It's the sense of effort, not position.
  • Tactile feedback. "What is happening at the exact points where I'm touching something?" A tactile array gives a spatial map — a small image of pressure across the contact patch. It's the stream that catches an object beginning to slip a fraction of a second before it falls.
  • Action. "What am I trying to achieve?" The actual commands issued to the mechanical parts. It's the single most valuable stream and the single most expensive, collected through teleoperation, motion-capture suits, egocentric human video, or simulation.

A few data challenges worth highlighting:

  • Time synchronization. A vision-language model with billions of parameters takes something like 100 to 200 milliseconds to produce an action — maybe 5 to 10 decisions per second. But physics doesn't wait. If a humanoid's foot slips, the fall develops over tens of milliseconds. You get an inversion of authority: the system component that understands the task can't react in time, and the component that can react in time doesn't understand the task.
  • Limitation of simulation. Sim-to-real works great for locomotion, because rigid-body contact with the ground is something physics engines model reasonably well. It works poorly for dexterous manipulation, because grasping involves soft contact, friction, deformable objects, and multi-finger force closure. That explains why you see so many robots walking, jumping, doing flips, but you don't see many robots using their hands to open a can of Coke. But it's the hand where most of the economic value of a robot actually is.
  • Compounding errors over long horizons. Humanoid tasks are typically long. "Unload the dishwasher" is dozens of sequential sub-behaviors. Success rate compounds multiplicatively: eight steps at 95% each gives you 66% overall. That might not be sufficient for customers to pay for.
  • Failure recovery might be missing from the data. Human demonstrators are competent. The training set is full of successful execution and nearly empty of failure recovery, which means the robot has no idea what to do once something goes wrong — precisely when you need it to know.
  • Knowledge transfer is imperfect. The robot's body is the interface to the world, and every body is different. Every hardware revision risks partially invalidating the data collected for model training with the older generation hardware.

This is exactly the problem the robotics field is trying to solve. Rather than accepting that intelligence is trapped inside a specific body, some companies are trying to decouple the intelligence layer from the hardware entirely. Skild AI, for example, is building a single foundation model on data pooled across many robot morphologies to create an "omni-bodied" intelligence layer. If that approach works, the diversity of hardware stops being a tax on the data and becomes the thing that feeds the flywheel.

Why is this a strategic finance problem?

Every problem mentioned above eventually requires a decision about where to spend a finite amount of capital. And the humanoid industry has a structural bias toward spending it in the wrong place.

Simulation is cheap for locomotion and nearly useless for manipulation. So the cheapest data produces walking, jumping, and backflips — the things that make a compelling demo and raise the next round. But the true economic value of a humanoid sits in the hand, in reliable manipulation of objects, which is exactly the data that has to be manufactured slowly and expensively. A company optimizing for what it can show on stage and a company optimizing for what a customer will pay for are pointed in different directions. Left alone, engineering and marketing pull toward the demo. The job of strategic finance is to resist the temptation and to influence capital allocation towards the boring but more commercially oriented data collection and training.

Willingness to pay for a physical task is a step function tied to reliability metrics: if a humanoid can accomplish the task only 66% of the time, customers are highly unlikely to pay for it. This means there is a wide valley between the impressive demo and the first payable task, and a company has to cross that valley on investor capital with no revenue underneath. What commercializable use cases to target first, what hardware setup that will require, how much capital it takes to achieve the reliability threshold — these are finance questions before they become engineering ones. Market sequencing is a capital allocation problem.

The unit economics also doesn't behave like it does in pure software products, and pretending that it does is how these companies die. Failure-and-recovery data has to be deliberately produced and never stops being expensive. Every hardware revision partially invalidates the data behind it. A two-to-four-hour battery is a hard ceiling on utilization, and utilization is a key revenue driver. The number the buyer actually computes is total cost of ownership — purchase, power, maintenance, warranty, replacement cycles — not the sticker price quoted for a demo robot. A $6,000 humanoid that falls off that stage is not a $6,000 product.

Decoupling intelligence from hardware isn't only an engineering choice; it's a choice that impacts capital structure, unit economics profile, and value pool allocation. A company that builds the brain independent of the body can amortize combined data-collection cost across many robot platforms and customers instead of funding new model training with every hardware revision. That is a more attractive capital story than vertical integration — assuming generalization across hardware architectures actually holds.

So what does strategic finance actually need to do? It needs to decide which task to commercialize first, mapping reliability thresholds against customer willingness to pay. It needs to allocate capital across the data strategy — real robot time vs. teleoperation vs. simulation vs. human video. It needs to choose the business model — outright sale, robotics-as-a-service, outcome-based pricing — which is really a decision about who carries the utilization and reliability risk. It needs to establish pricing guidelines that correspond with value generation. It needs to build the investor and board narrative that models unit economics honestly, instead of importing software assumptions that don't hold. And it needs to enforce the discipline of tying capital deployment to commercial-ready milestones rather than demo milestones.

None of these are questions engineering can answer, and none of them can wait until the technology is finished, because the technical choices and the financial ones are the same choices. The hand design sets the bill of materials and the data cost. The data strategy sets the capital profile. The first market sets the runway. A humanoid company that treats finance as the team that books the numbers after the fact will make its most expensive decisions blind.

The robots will make breakfast eventually. But at the cost of many companies failing to account for economic realities of hardware-software products or failing to run engineering choices through the lens of capital deployment optimization. The companies still standing to sell humanoids will be the ones that were as rigorous about the economics as they were about the engineering. And economic rigor is what strategic finance brings to the table.