Does industrial deployment actually need robot learning?

Lately I've been pondering - what tasks actually need (robot) learning, and what doesn't?

Obviously we have to go after new markets and new opportunities that today's new tech and new paradigms have just unlocked, not the existing market, which is traditional integration & programming - people can already do that stuff, but it costs a ton to do.

There are two new paradigms that have just unlocked

• The learned policy itself: doing tasks that were impossible before, like folding clothes, manipulating deformable objects, the stuff where every contact is different. This is where System 1 (VLA, WAM) is genuinely valuable - you could never write enough rules for it before, now you can learn it
• Learning a task really, really fast: show once, know how to do. @Machenta is a key player in this. Drag the arm through the workflow once, or throw in an SOP or a video, and it breaks the task down and figures it out on its own. It's basically a kind of in-context learning, but I realized it doesn't necessarily need a learned policy. The learning can live entirely in System 2, which understands the task and breaks it into steps; the actual execution is still classical motion planning and force control

The reason I've been thinking about all this is that I visited a precision CNC machining shop yesterday - I wanted to see whether machine tending had real potential for deployment

They do small-batch, high-mix work, prototyping for small teams, only 5-10 parts per batch, which means they change over pretty often, which also means they've never even thought about automation (because in their world, automation can't handle variation and high-mix)

When I got home I looked up the CNC machining process online, trying to understand the SOP and the whole flow, and it turns out plenty of shops already use robot arms for automated loading and unloading. Looking closer, they're all on a very traditional stack, pre-programmed tending. Which honestly makes sense, because this process needs extremely, extremely high precision, so it's not a great fit for learning (it'd just introduce variation and unnecessary uncertainty)

Actually this is a video posted 4 years ago... back then this firm already has 20 wheeled manipulator tending 60 machines. So you see this isn't new, they probably use a combination of nav2 and move it and program the robot to repeat fixed motions.

So now that raises a whole lot of new questions that are important to address!

• Does that mean this use case (CNC machine tending) isn't worth doing? If the traditional approach can already do it, where's the new opportunity?
• But if older tech could already do this, why aren't machine shops all over China and the world packed with robots replacing the operators doing the repetitive, laborious and potentially dangerous work? Is it because it's too expensive?
• If it's the cost, would a traditional stack plus a new financing model (aka RaaS - robot-as-a-service) be a viable business too?
• But even if RaaS solves the upfront cost, a traditional stack means I’m basically a traditional integrator... right? (maybe not quite, but could be a valid hypothesis to test) - every new part, every changeover is custom programming again. My cost grows with every deployment, it doesn’t come down. Isn’t the whole promise of learning (and the neo-integrator idea) that deployment gets cheaper each time, like software?
• Then what exactly is the learning supposed to make cheaper - the motion itself, or the setup? If it’s the setup, does the learning even need to be in the policy?
• If I use a traditional stack, the robot repeats the same pre-programmed motion every time. Is that kind of manipulation data even valuable for models like VLA or WAM?
• And if it isn’t, is there any point in me deploying at all? The whole reason I want to be on site is to collect data a model can learn from - especially the moments where something goes wrong and gets corrected
• But with a traditional stack I’d push precision to the limit and make sure the robot executes “perfectly”. Then every run looks the same, all “perfect” - and ten thousand identical runs carry about as much information as one...?
• So am I going against the Bitter Lesson here? Am I betting on hand-engineering instead of on data and learning?

So I think the test is - where does the variation happen, that's the key

• If every run is different, like folding towels, then you need a learned policy
• If every run is almost identical, but every so often you switch to a new part number, like CNC tending, then maybe it doesn't actually need a learned policy - what it needs is changeovers that are fast enough and cheap enough. And changeovers are exactly what factory owners actually care about. Flexible manufacturing means small batches, many runs, a changeover every time. There's no way I'm paying an integrator 1 million RMB one week to program 20 robots, then calling them back the next week when the part changes. So for this kind of scenario, the new opportunity isn't in System 1, it's in System 2 and tooling: turning an SOP or a single demonstration directly into a reliable, classical program.

But that's also the new opportunity, which is what I keep coming back to - what if a robot shows up on site, you teach it the job once, and it learns right there on the spot and starts producing value?

What I care about isn't the learned policy, it's - how to get a robot into the workcell and producing as fast, as efficiently, and as cheaply as possible