The last mile of physical AI

A robot picks up a part. It turns the part, places it precisely, and returns for the next one. The video is compelling. I want to know what happened just outside the frame.

Who arranged the parts? Who noticed the failed grasp? Who restarted the cell? How often did the system encounter something its designers had not anticipated? What did the operator stop doing in order to help it?

These questions can sound like an attempt to diminish a technical achievement. They are how I would find out whether the achievement can become a business. My interest in physical AI comes from the junction of engineering and commercialization: what has to happen between a capability becoming possible and a customer being able to rely on it?

Failed robots in food tech: SousX¶

My questions about robots come with some bruises. At SousX, we tried to automate food preparation. The ambition was convenient, personalized meals from fresh ingredients. The first prototype had a much smaller job: pick up a piece of produce, put it into a cutter, and push it through a blade grid. Even that exposed how much work was hiding inside the word “prepare.”

The original V0 report records what happened when we tried different foods. It is an engineering notebook, with unfinished sections and proposed fixes, rather than a controlled reliability study. That makes it a useful record of where our assumptions met the kitchen.⁴

V0: the arm, the actuator, and the actual food¶

V0 combined a suction-equipped uArm, a 3D-printed produce holder, Arduino controllers, and a linear actuator driving a modified French-fry cutter. The hardware made the idea tangible. The food made it complicated.

Play the demonstration here

Open on YouTube if the player is unavailable ↗

The demonstration belongs beside the test record.⁵ The report describes the suction gripper succeeding on, at best, about 80% of trials; it does not provide the sample count or a statistical protocol. It also records a sensor sometimes reporting a successful grip after the produce was no longer touching it. A failed action is one problem. A controller believing the action succeeded creates another.

What we tried	What the V0 notes recorded	What it exposed
Lettuce	Pickup failed; leaves jammed or spilled from the cutting area	Grasping, containment, and preparation were still human work
Whole tomatoes	Crushing, liquid, and skin left in the cutter	A repeatable actuator motion did not guarantee an acceptable cut
Extra-firm tofu	Worked well with clear blades; became mush when earlier food remained	The previous ingredient changed the next result
A bunch of carrots	More jamming than with an individual carrot	Input arrangement mattered as much as ingredient identity
A meal-sized sequence	Preparation remained necessary, followed by difficult cleaning	The useful task extended beyond the cutting cycle

The last row is the one I would put at the top of a product review. Our notes describe cleaning as inconvenient because too many components had to come apart. If a machine moves effort from cutting into preparation, supervision, jam clearing, and washing, the customer still has that effort. Counting only the automated seconds gives an incomplete answer.

V1: simplify the handoff¶

The V0 report recommended replacing the arm and its storage boxes with an inventory module that would drop produce into the cutter. The V1 work explored a rotating carousel, queued ingredients, and a more explicit sequence of loading, dropping, cutting, and recovery. It also considered additional cutting modes. Those were design directions, with open questions about lids, jam detection, power interruptions, and safe stopping.

Original V0 architecture & archive notes

The lesson I carry forward is to make the whole job easier. Sometimes that means better perception or control. Sometimes it means fewer moving parts, a constrained ingredient size, a removable food-contact surface, or a narrower promise.

I want the failed robots in the story because they changed the questions I ask. Before another impressive demonstration, I want to see the awkward ingredient, the next ingredient, the interruption, and the cleanup. Then I want to know how much of the customer’s evening we actually gave back.

A measurement taught me where to look¶

In the SignAiture experiments, the instrument produced changing traces. The next challenge was deciding whether those changes could support a repeatable process decision. That experience gives me a concrete reason to distrust a demonstration as the final unit of analysis. A robot and a sensor are different systems, but both have to survive the move from an interesting output to an accepted outcome.

Start with the completed workflow¶

The useful unit of analysis is an accepted job, with the surrounding work included. A picked object is one event. A completed workflow includes the arrival of work, preparation, execution, inspection, exception handling, and a handoff someone accepts.

The boundary matters. If a machine saves ten minutes inside its assigned task but creates fifteen minutes of preparation elsewhere, its local performance can improve while the operation gets worse. The team purchasing the machine and the team supplying its inputs may even report opposite results without either being dishonest.

NIST’s robotics performance work makes the technical version of this point: system performance depends on interactions among perception, mobility, and dexterity, and should be evaluated through tasks.¹ My commercial extension is to widen the boundary again, until it includes the people and processes required to deliver accepted output.

This does not mean every early experiment needs a complete financial model. It means the experiment should say which part of the eventual workflow it has demonstrated, and which parts remain assumptions.

The economics of an exception¶

Suppose a cell takes thirty seconds per operation. A recoverable exception stops it for three minutes. For this deliberately simplified example, each operation ultimately yields one accepted unit, and recovery time is additional to the normal cycle.

Across one thousand operations, the base work takes five hundred minutes. At a two-percent exception rate, recovery adds sixty minutes: about 107 units per hour. At ten percent, recovery adds three hundred minutes: 75 units per hour. The nominal movement of the robot has not slowed down. The system has.

Try the assumptionsIllustrative model

The cost of an exception

1,000 operations · 30 seconds each · 3-minute recovery

Exception rate

2%

0%20%

107.1accepted units / hour

60minutes in recovery

Normal workRecovery

The toy model leaves out maintenance, setup, queues, scrap, and concurrent recovery. Its purpose is to show a dependency, not forecast a factory. It also explains why an intervention count is incomplete. A one-minute reset, a specialist’s two-hour visit, and an unnoticed quality failure are very different events.

I would therefore ask for both the distribution of interventions and their consequences. The average can conceal a failure mode that makes a shift unstaffable or a delivery unreliable. Improving the worst recovery path may be worth more than making the ordinary cycle a little faster.

A deployment record I would trust¶

For a bounded customer trial, I want a record that someone on the operating side recognizes:

Question	Useful evidence
What work was actually completed?	Accepted units, rejected units, and the acceptance definition
How much time did it take?	Total elapsed time, including setup and recovery
Who was still needed?	Operator minutes, specialist minutes, and tasks displaced elsewhere
What changed across conditions?	Results by shift, product variation, and operating environment
What happens when it fails?	Detection, safe state, recovery owner, and time to resume
Can the next customer use it?	Commissioning work and modifications required for another installation

A strong trial need not produce a perfect result. It should produce an interpretable result. If all the difficult inputs were removed before the trial, record that restriction. It may be a sensible first market boundary. Concealing it prevents everyone from learning what the product is.

There is another distinction worth protecting. DROID’s researchers describe the considerable work involved in collecting diverse robot demonstrations.² Such data can support better policies. It is not itself evidence of profitable unattended operation. Training data, benchmark results, customer trials, and commercial operating records answer different questions.

The case for generality¶

The strongest objection is that I am describing a world of narrowly engineered cells just as broader robot policies may reduce the need for them. If a system can adapt to new objects and settings, some integration costs could fall dramatically. A diligence process obsessed with today’s exceptions might miss a discontinuity.

I take that objection seriously. Physical Intelligence’s π0.5 work reports generalization to tasks in previously unseen homes, while also acknowledging imperfect performance.³ That is a reason to investigate the rate of improvement and the range of conditions a policy can handle. It is not a reason to stop measuring the operating consequences of its failures.

Breadth and a specific commercial entry point can coexist. A general model may be the reason a narrow deployment becomes affordable. The question is how much reusable capability carries into the second and third installation, and how much work starts over.

What would change my mind?¶

I would become more optimistic about broad deployment if independent operating records showed that new installations needed substantially less commissioning, maintained performance across representative variations, and reduced human work after all interventions were counted. A falling model error rate would be encouraging; falling total cost per accepted job would be stronger evidence of a product.

I would become less optimistic if each successful pilot depended on an expert permanently standing nearby, if failure recovery remained unpredictable, or if the business model treated customer integration labor as free.

The opportunity I want to understand is the part between the model and the customer's accepted result. Sometimes that part will be commoditized by better intelligence. Sometimes it will contain the durable business. The work is to determine which, one workflow at a time.