Robots Run on the Same Stack: Embodied AI Is a Power-and-Compute Story

The robotics coverage is all about the robot. The hands, the gait, the backflip, the uncanny demo where a humanoid folds a shirt. It's great footage and it's the wrong altitude. We don't sell robots, and this isn't a post about whether the humanoids are real — Goldman Sachs Research thinks the humanoid market is a tens-of-billions story by the mid-2030s, others think sooner or smaller, and that argument will resolve itself without me. What I can tell you, from the desk where the power and compute orders actually cross, is the part the demos hide: an embodied-AI company is an infrastructure company that hasn't admitted it yet. A fleet of robots is a distributed data center that moves. It learns on the same silicon we help data centers buy, it runs on the same electrons we help them source, and — the part with no equivalent in software — it has to physically fail somewhere before it's trusted to physically work. Three constraints, and all three rhyme with the AI-infrastructure story we've been telling.

A robot is a data center with legs

Follow the compute. A modern robotics program is a training operation before it's ever a hardware operation. The policies that run the machine — the models that turn camera pixels and joint angles into motion — are trained on the same NVIDIA accelerators that train language models, on clusters that look identical to any other AI buildout. Simulation makes it heavier, not lighter: teams train in massively parallel physics sims, generating synthetic experience across thousands of virtual robots at once before a single real joint moves, and that simulation load is GPU-hungry in its own right.

So the first question an embodied-AI team faces is the one we walked through in which GPU to buy in 2026: what rung of the ladder does the workload actually need? Frontier policy training pushes you toward Blackwell and rack-scale systems; a lot of the fine-tuning and the inference that runs on or near the fleet lives comfortably on Hopper, where a well-priced H100 or a memory-rich H200 still clears the job. Same ladder, same trap — buying the frontier part when a cheaper rung clears the workload with headroom — same answer: buy the cheapest rung that fits, and check what your building can cool before you check the spec sheet. The robot is downstream of a GPU-procurement decision that looks exactly like everyone else's.

The fleet runs on electrons

Now follow the power, which is where robotics stops looking like software and starts looking like an energy business. Every robot in a fleet is a battery that has to be charged, and charging at fleet scale is a real electrical load — a warehouse or yard full of machines cycling through duty and recharge is a power-density problem, not a wall outlet. Behind that sit the parts nobody photographs: the power electronics that condition and convert the current, the battery chemistry and thermal management that decide whether the fleet runs eight hours or three, the charging infrastructure that has to be sized like a small substation.

This is the sentence I'd underline for anyone building in the space: the robotics team's power-electronics problem is the energy team's product. The same inverters, converters, storage, and thermal engineering that make a microgrid work are what make a robot fleet work — which is why, in a place where energy hardware is already being built and cheap firm power is already being poured, a robotics company gets a supply chain and an input-cost advantage for free. And the macro logic is the same one that governs data centers: a fleet that draws real, steady load wants power that's cheap and firm and soon, not power stuck in a five-year interconnection queue. The behind-the-meter argument we made for compute halls applies to charging yards with almost no translation. Embodied AI doesn't escape the time-to-energized clock. It's on it.

The constraint software never had: a place to fail

Here's the leg with no analog in the AI you can run from a laptop. Software fails in a sandbox and you roll it back. A robot fails in the physical world, and before anyone trusts it to work at a customer site, it has to break, drop things, run into walls, and get caught doing it — safely, legally, repeatedly, on ground where that's allowed. Proving grounds are not a nice-to-have for embodied AI. They're a gating input, the same way a coolable hall is a gating input for compute.

That single requirement reorders the map. A robotics team doesn't just need cheap power and cheap GPUs; it needs acreage with a permitting regime that says yes — outdoor space for wheeled and legged machines, airspace for drones, and a jurisdiction that treats physical testing as a feature rather than a liability. That's a short list of places, and it overlaps almost exactly with the cheap-power, cheap-equipment, fast-permitting stack we mapped in the convergence post. Nevada was the first state to authorize autonomous-vehicle testing, back in 2011, and it's one of the FAA's designated unmanned-aircraft test-site states — the regulatory groundwork for exactly this was laid years before the current wave. Layer that on top of the industrial base out at the Tahoe-Reno corridor (Tesla building robots and Redwood building the batteries that move them, thirty minutes away) and the physical-test leg lands in the same county as the power leg and the compute leg. Not by coincidence. By the same gravity.

Where this leaves the buildout — and us

Put the three legs together and the shape is unmistakable: an embodied-AI company sources training compute, fleet power and power electronics, and a physical place to test, and if it's honest about the bill of materials it wants all three cheap, fast, and near each other. That's not a robotics decision. It's an infrastructure decision, and it's the same infrastructure decision a data-center operator makes — which is why the two keep converging on the same ground.

We sit at the two legs we actually source: the compute the fleet learns on and the power — and the harder middle of connecting a site to generation — that the fleet runs on. We don't build robots and we don't sell them; the machine is someone else's genius. What we can do is read the deal flow and tell a serious embodied-AI team the thing the demo reel won't: that their hardest procurement problems aren't in the robot, they're in the stack underneath it, and that stack has a cheapest, fastest address. We're plugged into that ecosystem — the power developers, the integrators, the OEM channels — in the exact geography where physical AI is cheapest to build.

If you're standing up a fleet and the compute-and-power side of the plan is still on two different desks, that's the same mistake we watch data-center operators make, and it strands the same way. Talk to us about the stack underneath the machine, or browse the iron we put around builds like this. The compute, power, and convergence halves of this story are where the specifics live.

Pantheon Research is our series on the infrastructure behind AI: power, turbines, cooling, compute, and the procurement reality that decides who actually ships. Field notes from the deal flow, not the keynote.