Brett Adcock streamed something unusual this week: humanoid robots sorting packages for eight consecutive hours. No human stepping in. No pauses for recalibration. Just robots, battery swaps, and multi-robot coordination in a live production environment.
This wasn't a benchmark. It was a shift.
What Changed
Figure's robots ran on-device inference - meaning the decision-making happened locally, not in the cloud. When a robot's battery ran low, another robot took over. The coordination was autonomous. The tasks were repetitive but real: picking, sorting, moving packages through a warehouse flow.
Previous humanoid demos showed impressive dexterity in controlled settings. This showed something harder: long-horizon autonomy. Can a robot work a full shift without human intervention? According to Adcock's livestream, yes.
Why Eight Hours Matters
The difference between a 90-second demo and an eight-hour shift is everything. Demos optimise for spectacle. Shifts optimise for reliability. A robot that works for eight hours must handle:
Battery management - knowing when to swap out, coordinating handoffs without downtime.
Edge cases - packages that fall, paths that get blocked, tasks that don't fit the expected pattern.
Multi-agent coordination - multiple robots sharing space, avoiding collisions, dividing work without a central controller.
Figure's system handled all three. The robots didn't just complete tasks - they kept working. That's the part that matters for deployment.
The Deployment Gap
Most robotics companies show what their robots can do. Figure showed what their robots did do, for hours, on camera. The gap between capability and deployment is where most automation dies. A robot that works 95% of the time still needs a human babysitter. A robot that works 99.9% of the time for eight hours straight changes the economics.
Warehouses run on thin margins. Labour costs are predictable. Robots are capital expenses with unpredictable maintenance. The break-even point is reliability over time, not peak performance. If a robot can replace a shift worker, it needs to work like a shift worker - consistently, for hours, without drama.
Figure's livestream was a signal that they're past the capability phase and into the reliability phase. That's a different kind of hard problem.
On-Device Inference
The technical detail that matters most: on-device inference. The robots aren't pinging a cloud service for every decision. The neural networks run locally. This means:
No latency - decisions happen in milliseconds, not after a round-trip to a server.
No connectivity dependence - if the Wi-Fi drops, the robots keep working.
Better data privacy - nothing leaves the warehouse floor.
Running inference on a robot is harder than running it in the cloud. You have tight power budgets, limited compute, and heat constraints. But the trade-off is autonomy. A robot that depends on the cloud is never truly autonomous. A robot that thinks locally can work anywhere.
What This Means for Builders
If you're building automation tools, the question isn't "can my system handle the task?" It's "can my system handle the task for eight hours without me?"
Long-horizon reliability is the new benchmark. Demos don't matter. Deployments do. The gap between a working prototype and a production system is resilience to the boring edge cases - the 1% of situations that break everything if you haven't planned for them.
Figure's approach - local inference, battery coordination, multi-agent systems - is a blueprint for what reliable automation looks like. Not flashy. Not perfect. Just working, for hours, without intervention.
That's the shift. The robots aren't getting smarter. They're getting more reliable. And reliability is what gets deployed.