3 Comments
User's avatar
Jan Olsson's avatar

Great article!

Jon Scholz's avatar

As a researcher turned entrepreneur, I can confirm that working on deployments is a game changer in how I thought about the tech. Trying to build without it is like trying to train a classifier without a loss.

In addition to this great list of reasons, I'd add one more: problem discovery. If you push past "deployable robot" to "teachable robot" you start getting all sorts of ideas about stuff the robot can do... from the customer.

We've built R2 around this concept, and we're already finding applications we never would have dreamed up in a million years.

Bradford Stephens's avatar

I'd push it one step further: the deployment gap is infrastructural, not organizational. Even teams that rebalance toward operators hit a wall because the post-deployment learning loop doesn't exist. When a composed policy fails at a customer site, there's no systematic way to diagnose which training modality broke, reconstruct it in sim, validate the fix, and propagate it across the fleet. Every deployment starts from scratch.

This is what we're building at Square Hammer Labs -- the continuous adaptation layer between deployed fleets and the next rollout. And the talent point resonates: our founding team is distributed systems engineers and ML researchers, not traditional roboticists. Turns out fleet-scale robot learning is fundamentally a distributed systems problem.