The frontier of robotics has produced real intelligence breakthroughs. But the most impressive demonstrations still require large models running on remote servers or desktop-class GPUs. Action chunking, which grew out of Stanford’s ALOHA/ACT research and is now standard practice at labs like Physical Intelligence, where we’re investors, stretches each inference call further. Even so, a cloud roundtrip can still take up to a few hundred milliseconds per decision. 

Our view is that latency, as much as intelligence, now decides which robots make it out of the lab. The field is racing to make models smarter while one of the biggest factors gating deployment is whether a decision arrives before the physical world moves on. For the assemblers we wrote about in “Robotics’ Missing Piece: Assembly Required,” that makes latency a product decision as much as an engineering one. Solving it takes two things: purpose-built decision models, which we expect assemblers to own, and silicon designed for how robots actually compute, which we think could anchor some of the most important infrastructure companies in robotics. Most of them don’t exist yet.

Take a warehouse robot; it picks up a box from a moving conveyor and carries it across the floor. The box shifts in its grip, and a worker steps into its path. Each moment exposes a different latency failure:

• Seeing the box too late: The conveyor keeps moving while the robot processes its camera images. By the time it reaches for the box, the box has moved. Faster perception lets it act on a fresher picture of the world.
• Adjusting grip too slowly: As the robot lifts the box, it starts slipping. Grip adjustments need to happen through fast, local controllers. Waiting for a large model to reason through the problem could mean dropping it.
• Stopping too late: A worker steps into its path. If stopping depends on sending observations to the cloud and waiting for instructions, network delays become physical risks. Immediate safety responses need to happen on board.

The answer taking shape is a three-tier stack. Reflexes stay local and instant. A fast decision layer, operating at roughly 100 milliseconds, picks which skill runs now. And frontier models handle the genuinely unfamiliar at whatever speed they need, because the robot has already been stabilized by the layers below. The two bottlenecks worth building against sit in that middle tier and in the silicon underneath it. We cover both below. 

1. Frontier models learn the skills. Decision models pick them 

A robot facing a genuinely new task may still need a frontier model. But deployed robots encounter the same grasps, obstructions, and failure modes repeatedly. Once those behaviors are encoded as reusable skills, the runtime question narrows to a decision: which skill should run now?

Making the decision requires a model built to choose from a menu.  A new architecture class is emerging for exactly this, sometimes called System One models: non-autoregressive models that output a decision across a fixed menu in a single forward pass rather than generating token by token. 

The most visible example is Jev, from TypeSafe AI. Instead of generating a full trajectory, the model chooses from a constrained menu: regrasp, re-align, retry, stop, request help, or escalate to a larger vision-language-action model (VLA) for an unfamiliar case. Because the output is a single decision rather than a long sequence, the decode step is massively reduced. 

Most of the inference load shifts to prefill, which today's hardware handles far more efficiently. System One models can run orders of magnitude faster than traditional text-generating transformers. TypeSafe reports speedups of 40 to 200 times on decision-shaped queries. Those figures come from the vendor and its developer community and haven’t been independently benchmarked. The architecture itself has held up: independent reproductions of the mechanism show nearly 2x latency gains over standard generation. 

For now, these models accept only text. A robot's decision inputs are images, forces, and point clouds. Multimodal System One models are the obvious next step, and we expect them quickly.  

Standalone companies may emerge around physical AI System One models, but we expect assemblers to own this capability as a core part of their stack. The substantial fine-tuning required for each robot and operating environment should concentrate differentiation and value at the deployment layer, leaving less value for third-party base-model providers. That’s the same pattern we see across robotics: components create the possibility, and assemblers capture much of the reward. We hold this view loosely and want to hear from founders building the case against it.

2. Build compute for the physical world

Smaller models reduce inference time, but they don’t eliminate network latency.

The average matters less than the tail.  Imagine a network that returns an answer in 30 ms most of the time but takes 300 ms on one in every hundred calls. At ten calls per second, that slow response would occur roughly once every ten seconds. For a robot in motion, that means acting on a stale picture of the world every ten seconds. 

One option is to bring compute closer. A warehouse can run servers on site, reducing the distance between its robots and the models they use. But that approach gets harder for robots moving across a large area, like an excavator on an open jobsite or a drone over a utility corridor, where a reliable connection cannot be assumed.

NVIDIA’s Jetson platform is the standard answer today. It’s the most capable edge hardware available, and that capability comes with a hard tradeoff.  Jetson Thor operates across a 40 to 130 watt power range. That’s workable inside a humanoid or construction vehicle. It is punishing inside a small drone or compact mobile robot that has only a few hundred watts of total power budget, most of it spent on locomotion. That’s the battery and charging tradeoff assemblers have to settle before a pilot, and today’s silicon forces it on them.

This leaves room for a new class of physical-AI silicon. The winning architecture will be designed around the workload robots actually run:

• Batch size one. A robot cares about the latency of its own next action. Aggregate datacenter throughput doesn’t help it.
• Strict tail latency. Predictable p99 performance matters more than an impressive average.
• Hard power limits. More compute is useless if it destroys battery life or requires impractical cooling.

We think the silicon and inference clouds for the physical world are a large venture opportunity, and we want to back the technical teams building them.  

Seeking speed

Robotic models are getting smarter, but a model that can figure out how to grasp an unfamiliar object is less useful if its answer arrives after the object has slipped. The silicon, inference infrastructure, and decision models around them are still catching up. Closing that gap is where we think the next great physical AI infrastructure companies get built. It’s also what will let assemblers turn smarter models into robots that hold up on a live floor.

If you're building the decision models or silicon the next generation of robots will run on, we want to hear from you.