What it takes to deploy robots: 8 lessons from The Deployment Moat

Six people who deploy robots, two panels

Fact On October 29, Embodied Collective hosted The Deployment Moat at Mission Robotics in San Francisco. More than 300 people registered. Six speakers who build, deploy and fund robots joined two panels: Saman Farid (Formic), Judah Longgrear (Robot.com), Ruslan Bekbulatov, Rajesh Senthil Kumar (RLWRLD), Natalia Kokoromyti (Cybernetic Physics) and Evan Tao (Chestnut Robotics). Robert Scoble opened the evening. Everything below comes from what was said on stage. Each lesson has two parts: what we heard, then what we think it means and what to do with it.12

Reliability is a product of every layer, not a property of the model

Fact Saman Farid said a demo that works 85% of the time in a lab often gets mistaken for success. In production it isn't close. If a robot does a task 10,000 times a day, nobody will tolerate hundreds of failures a day. And overall uptime is the model's reliability multiplied by the hardware's, multiplied by how fast you respond and repair. To land near 99.99% overall, each layer has to be well above 99.9% on its own. Formic reports 99.96% uptime over the trailing twelve months across about 150 factories, including sites in Idaho, Wyoming and Alabama.12

Our read The most common mistake we see in robotics pitches is quoting the model's success rate as if it were the product's reliability. Buyers experience the whole chain. A great model on a hand that breaks, with a technician three hours away, is an unreliable product. What to do: Write down a reliability number for each layer: model, hardware, response time, repair time. Multiply them. That number, not the demo, is what your customer will feel.

The customer is buying an outcome, so someone has to own the risk

Fact Saman said people mistake payment terms for a pricing question. It's a risk question. Companies moved to the cloud not to pay later, but so that someone else is responsible when a server goes down. A chocolate chip cookie factory shouldn't have to become a robotics operator. So Formic's offer includes the hardware, software, maintenance, spare parts, financing, uptime guarantees and insurance, and it only gets paid if the robot works. 98% of its robot subscriptions renew at contract end.12

Our read A component, however good, is too hard for most factories to digest. What they can buy is a working result with one throat to choke. The guarantee is the product. What to do: List everything your customer would have to handle themselves to get value from your robot: installation, repairs, spare parts, financing, insurance, monitoring. Every item you leave on their side is a reason to say no.

Agree on what success means before the robot arrives

Fact Judah Longgrear said Robot.com's first customer was Sodexo, and it started with a pilot. What mattered was "a very simple kind of understanding from the get-go of what success would mean." That pilot grew into more than 40 college campuses and a seven-year contract. Saman described the other side of the same problem: corporate innovation teams often measure success differently from the people running the production floor, so a trial can impress one group and never move the other. Formic skips proofs of concept and goes straight to deployment, with the risk on its own balance sheet.12

Our read Both companies are solving the same thing. A trial only turns into business when the people who will live with the robot every day agreed in advance on what "working" means. Without that, a pilot is a demo with a longer timeline. What to do: Before any pilot, write one sentence with the floor owner: "If the robot does X at Y rate for Z weeks, we will do W." If you can't get that sentence, treat it as a demo and price it like one.

Your first customers are the ones who need it most and can decide fastest

Fact Saman said early adopters share two traits: their success depends on your robot, and they can make decisions fast. For Formic that has often meant mid-sized manufacturers and small warehouses checking their margins every month and asking how to cut 30% of cost or add 30% of throughput to win the next order. Famous logos look good on a pitch deck but rarely jump first. Judah added that trust is the biggest barrier: "Most people do not trust robots." Once Robot.com earned that trust, customers started asking where else it could save them money.12

Our read Early in a robotics company, urgency beats brand. A customer who must solve the problem this quarter will tolerate a young company. A customer planning for the next twenty years won't. What to do: Rank your pipeline by two columns: how painful the problem is for them right now, and how many people have to sign. Start at the top of the first column and the bottom of the second.

Measure usage, not revenue

Fact Saman said revenue is a lagging indicator. A customer can be paying while the robot sits idle because of a production issue or a line that isn't running. Formic tracks usage hours across its fleet every day, robot by robot, against the day before. The day of the panel, that was 4,800 hours. Judah defined a real deployment the same way: it's one thing to ship a robot, and another for it to work 12, 24 or 36 months later, hit its service levels and get renewed.12

Our read Usage hours are the honest metric. They catch problems months before a renewal conversation does, and they're the number your next customer will actually ask about. What to do: Put usage hours per robot on a daily dashboard. Look into any robot that drops below the day before.

Plan for humans in the loop, permanently

Fact Formic doesn't keep staff at customer sites. A fleet command center monitors every robot, 70 to 80% of issues are fixed remotely, mean time to respond is 10 minutes and mean time to resolve is two hours. Saman noted that this only works with deployment density. Natalia Kokoromyti said Cybernetic Physics runs a safety check before every robot action in a data center. If the check doesn't pass, the robot doesn't improvise. It pings a remote operator, who takes over. Some customers are happy with teleoperation alone, because it saves sending someone to a remote site to power-cycle a server. Evan Tao said teleoperation will never go away: even at 99.99% autonomy, someone will need to step in for the rare corner case.12

Our read Full autonomy is a direction, not a launch requirement. The companies deploying today design the human handoff on purpose, and use every handoff as training data. What to do: Before you ship, decide three things: what triggers a human, who that human is, and how many minutes it takes them to reach the robot, remotely or in person.

In the field, every extra moving part is a liability

Fact Rajesh Senthil Kumar described a hand with 21 degrees of freedom that worked well in the lab. On the first day at a customer site, it broke and had to be shipped back to China for repair. His conclusion: degrees of freedom and robustness are inversely correlated. Evan said Chestnut Robotics deliberately limits degrees of freedom to what the task needs, because complexity makes failure rates climb fast once a hand leaves the lab. Evan, Rajesh and Saman all named sensors, especially tactile sensors, as the part that breaks first. Evan added a benchmark from his time on Tesla's Optimus hand: the first milestone was 100,000 grasp cycles, while a Foxconn line worker opens and closes a hand 7,000 to 8,000 times a day. At that pace, 100,000 cycles is about two weeks of work.12

Our read Lab capability and field robustness pull in opposite directions. The winning hardware for deployment is often the simplest design that can still do the job. What to do: Ask any hardware supplier for cycle-life data under real duty cycles, not peak capability. Then do the math against how many times a day your task actually runs.

Narrow, repeatable sites are what make deployment compound

Fact Natalia said focusing on one vertical, data centers, is what makes integration repeatable. Racks follow shared standards, ports are evenly spaced, aisles are laid out in known patterns, and robots run on triggers a few times a day instead of 24/7. That makes deployments much easier to de-risk than a home robot expected to be on all day in every kind of apartment. Surprises still happen: server rails differ by manufacturer, and the Velcro humans love for cable management is terrible for a robot gripper. A first deployment in a constrained cage can take one to two weeks. Rajesh said RLWRLD reaches about 95% on predefined tasks in a proof of concept within a week to ten days, and getting to 99%+ for production takes longer. But each deployment feeds back into the model, so the next time the same task starts near 90% instead of 70%. Natalia added why deployment comes first: there will never be petabytes of video from inside data centers, so the only way to find the edge cases is to be on site.12

Our read Deployment only compounds when the next site looks like the last one. That's why a narrow vertical often beats a general-purpose robot in the early years. What to do: Before choosing a market, check how standardized the sites are. If every customer's floor is different, your tenth deployment will cost what your first one did.

One more thing on data

Fact Rajesh ranked today's bottlenecks as hardware first, then accurate post-training data, then the model. On how to get that data, the speakers described three tools for three jobs. RLWRLD uses teleoperation for the last mile, the best it has found so far, though slow and expensive. Chestnut builds a wearable exoskeleton so people can record natural hand motion and feel contact through haptic feedback. Cybernetic Physics is seeing promising results from high-fidelity simulation for narrow insert-and-extract tasks like handling cables.12