By Kenrick Tjandra
Earlier this month I spent five days at ICRA in Vienna — the largest gathering of robotics researchers in the world, and the closest thing the field has to a state-of-the-union. I went to give a ten-minute talk at a workshop on long-term robot deployment. I came back thinking about a tension that ran underneath the whole week.
Humanoids were the headline act. Every other booth, every other talk: robots that walk, fold laundry, mimic a person’s gait. The energy in the building was on capability — on expanding what a robot can do — and it’s genuinely exciting work. Foundation models trained on web-scale data. Synthetic worlds where robots rehearse a million times before they ever touch reality. Dexterity that would have looked like science fiction five years ago.
But there was a second frontier in the building, quieter and a few rooms down the hall. It wasn’t about what a robot can do in a demo. It was about whether a robot can do it again tomorrow, and the day after, in the rain, on a site nobody mapped, without anyone standing next to it. Those are two different problems. The field spends most of its visible energy on the first. I spend all of mine on the second. And I’ve come to believe they’re two halves of the same problem — you can’t sell the first without solving the second.
Give the headline act its due
The progress on general-purpose robots this year is real, and it deserves the spotlight. A decade ago, getting a robot to reliably pick up an unfamiliar object was a research milestone. Now the conversation is about generalist machines that learn a new task from a handful of demonstrations, transfer skills across different bodies, and reason about a scene they’ve never encountered. The conference theme this year was “Robots for all,” and you could feel the field reaching for it.
That reaching matters. The capability frontier is where tomorrow’s tools get invented, and much of what my team relies on — better perception, better learning, cheaper sensing — flows downhill from exactly this kind of research. I’m not here to roll my eyes at the humanoids. I’m here to point at the part of the problem the demos don’t show you.
The room that fights back
The room I felt most at home in was the one working on robots for places that fight back. Long-term deployment in the wild — forests with no GPS, open water, snow, sites where the map you trained on stopped being true a season ago. One session was titled, almost perfectly, around tough physical AI for harsh environments. The researchers in that room weren’t asking whether a robot could do a task once. They were asking how it stays dependable when the world stops cooperating — when the lighting, the dust, the vibration, and the weather all shift out from under the model it learned.
Sitting there, the construction sites I deal with every day suddenly looked tame by comparison — and also exactly the same problem. A building under construction is a harsh environment. It has no clean map; the structure changes by the hour. It has dust, wind, temperature swings, other trades walking through the workspace, and a schedule that doesn’t care about your sensor’s comfort zone. The thing that separates a robot that survives that from a robot that doesn’t isn’t how impressive it is on its best day. It’s how it behaves on its worst one.
How reliability is actually won
That’s the frontier I came to Vienna to talk about, and it’s worth saying concretely what it takes — because “reliability” is an easy word to nod at and a hard thing to earn. Here are three things our deployments taught us that I don’t think you can learn anywhere but the field.
Test the assumption, not the task. On one of our first high-rise deployments, in Dallas, the robot was setting clips into curtain-wall channels — a task it had performed in the lab thousands of times, flawlessly. On site, it started failing. The channels weren’t clean; prior trades had left packing foam and the occasional protruding nail, and the robot was trying to install on targets that, to a veteran glazier, were obviously not ready. The robot wasn’t broken. Our test plan was. We’d validated the task — installation on a clean channel — and never validated the assumption that the channel would be clean. The lab had quietly handed us a perfect world. We now catalog every assumption the lab makes and design a field test to try to break each one. A demo proves the task; only the field proves the assumptions.
The field ships every variable at once. On a summer deployment in Nashville, we knew the chassis would run hot, so we engineered cooling and added fans. Sensible — except the fans pulled fine construction dust straight through the chassis. We’d tested for heat. We’d separately dealt with dust. We had never tested heat and dust together, which is exactly how a Nashville summer delivers them. This is the deepest difference between a lab and a job site: the lab lets you test one variable at a time; the field ships all of them at once, coupled, in combinations you didn’t plan. Any one is manageable alone. The site never sends them alone.
Perception needs three stages, not two. Put those lessons together and you get a structural point. Most prototypes treat perception as two steps: see the task, do the task. The field taught us to add a step in front — verify the precondition, is the target actually in the state the task assumes — and a step behind — check the work before you call it done. Precondition, execution, post-task QA. The first is the one almost everyone collapses into an assumption, and it’s the one the field punishes hardest. When we rebuilt our system around all three, our first-pass quality rate — the share of work the robot gets right the first time, with no rework — became the number I watch most closely. A rolling drop in it is the earliest warning that something upstream is drifting, long before it becomes a visible failure.
And reliability isn’t only a question of getting it right the first time — it’s getting it right the hundredth time, and the thousandth. The longer a robot lives on a site, the more a different failure mode takes over: wear. Components that sailed through the first week start drifting by the third. Off-the-shelf parts get pushed past the envelopes they were rated for, because at this scale there isn’t always a premium alternative. Which parts to upgrade, which to swap cheaply and often, which to replace outright — those become product decisions you can only make well once you have real telemetry from real deployments. The lab can tell you a robot works. Only time on site tells you it keeps working.
None of that is glamorous. None of it makes a good demo video. All of it is what reliability is actually made of.
The five-nines problem
The sharpest version of this I heard all week didn’t come from an engineer. It came from a venture investor, on stage, talking about how his world decides what to fund. He put it bluntly: a robot that’s 99% reliable is a robot falling down the stairs about once a week. The value, he argued, doesn’t show up until you reach 99.999% — five-nines reliability, the kind that photographs terribly and quietly decides whether anyone will trust you to leave a robot alone in their building.
That line stuck with me because it’s the whole game stated as a number. The distance between a robot that works in a demo and a robot you can walk away from isn’t one nine. It’s four of them. And every one of those nines is bought the unglamorous way — in preconditions and joint-variable testing and QA stages and wear logs, deployment after deployment. Capability gets you onto the field. Reliability is what lets you stay. The investor was looking at the same gap I stand in, from the opposite end, and calling it the thing that actually determines value. He’s right.
What five-nines looks like when you earn it
On the surgery tower at St. Jude Children’s Research Hospital in Memphis, our robot set more than 10,000 curtain-wall clips at one-sixteenth-of-an-inch accuracy, across fourteen floors and two towers, through rain and freeze and wind. The glazing contractor had already absorbed six figures of rework from manual layout on earlier floors; with the robot, that number went to zero. That outcome isn’t the product of a better demo. It’s the product of knowing, down to the assumption, what the machine can and can’t do when the weather and the schedule and the other trades all show up at once — and building for the worst day, not the best one.
What this means for what you’re building
So if you’re a contractor or an owner weighing robotics, here’s the translation from the conference floor to your job site. Both frontiers are real, and both matter. The capability frontier will keep producing more impressive machines every year. But the question that decides whether one of them belongs on your project isn’t “what can it do in a video?” It’s “what has it been proven to do reliably, under conditions like mine — and does the team behind it know exactly where its edges are?” A vendor who can only show you the clean-channel demo hasn’t met your site yet. A vendor who can tell you precisely what breaks their robot, and what they do about it, has — and that’s the one whose numbers will hold up when the weather turns.
That’s the conversation I went to ICRA to start, and it’s the one we have on every site. The research community keeps expanding what’s possible. Our job is to make it dependable. The gap between those two is exactly where the buildings get built.
Kenrick Tjandra leads robotics deployment at Raise Robotics, where he has directed deployment across ten commercial projects in eight states. He authored the company’s peer-reviewed decision framework for scaling early-stage robotics, built the operator-training curriculum now in the IUPAT national catalog, and spoke at ICRA 2026 in Vienna.