The Gap Nobody at Automate Has Named Yet
I spent a couple of days earlier this week walking the floor at Automate, the largest robotics trade show in North America, looking for one specific thing.
What I found wasn't a gap in anyone's effort.
It was a question almost nobody is asking yet, and a market-sized opportunity sitting underneath it.
I spent a couple of days this past week walking the floor at Automate, the largest robotics and automation trade show in North America. I went in with a simple list of questions: what's actually working, what isn't, what's the real use case hiding in plain sight, who's worth talking to, and what's conspicuously missing from all the noise about the next era of robotics.
The answer to that last question is the one I keep coming back to.
Using an AI model to actually control a robot, not just help a person program it faster, is a genuine paradigm shift. It's early. By my count, walking hall after hall, only a handful of companies on that floor are building toward it. That's not a knock on anyone. It's a young idea in a young part of the industry, and most of the floor's energy is, understandably, pointed somewhere else right now.
There's a quiet split happening in robotics software right now, and most of the industry is on one side of it without realizing there are two sides.
A lot of automation companies are racing to make robots "easier to code." Increasingly that means AI writing the robot code for you. That's a real and valuable improvement. It's also solving a different problem than the one I went to the show looking for.
"Easier to code" speeds up programming a robot for a high-throughput, low-mix task: same parts, same positions, same motion, over and over, just faster to set up. That's a genuinely useful problem to solve, and a lot of sharp engineering is going into it. "AI controls the robot" is aimed at something else entirely: high-mix, low-volume work in unstructured environments, where the part, the position, and the situation change every time, and hard-coding every case isn't practical. Most of the floor's attention is on the first problem. The second one is wide open.
Here's why that second problem is harder than it sounds, and also why it matters.
Industrial integrators have spent decades getting extremely good at eliminating uncertainty. A customer comes to them to automate a process, and the integrator's whole value proposition is designing a work cell where every variable is known in advance: exact part, exact position, exact motion. That's not a limitation. That's the product, and it's a genuinely impressive discipline built over decades. It also means that adding a model built to handle uncertainty into that world isn't simply a feature you bolt on. It changes a basic assumption the whole discipline is built around, which is exactly why it takes time, and why it's a much bigger lift than it might look from the outside.
"Go to the counter and get me a glass of water" is not a hard-automation task. The robot doesn't have fixed coordinates for the world, doesn't know what kind of glass it's reaching for, doesn't know where anything actually is until it looks. That flexibility is the whole point of an AI-controlled robot. The question I kept circling on the floor is what the industrial version of "get me a glass of water" actually is. Not a demo. A task someone will pay to automate, that hard-automation genuinely cannot solve, in volumes worth solving for.
I didn't leave with a single clean answer. I left with a sharper question, and a few candidates worth chasing.
The clearest signal I got was less a booth and more a pattern across two of them.
In one hall, a capable mobile robot rolled around on a wheeled base with a full arm attached. Genuinely good hardware, well built, clearly a serious engineering effort. On its own, it was waiting for something to tell it how to interpret and interact with the world in front of it, which is a hardware achievement looking for its missing half. A few aisles over, a small team had built a genuinely charming demo where you could play a board game against a robot arm, complete with a "hard mode" that quietly cheated and then needled you about it when it won. Everyone loved it, myself included. It was also entirely hard-coded: every piece position, every board square, fixed in advance. It's a clever piece of programming solving a fixed, well-defined version of the problem, by design.
That's the dividing line, in two booths I happened to wander past within minutes of each other. A capable body waiting for a brain. A clever brain that works precisely because the world it operates in was fully specified ahead of time. Closing that gap, body and adaptable brain together in the same system, is still rare on the floor.
A few exhibitors are pushing in that direction, combining force sensing with vision so a system can sense and feel its way through a task instead of just executing a fixed path. It's genuinely exciting progress, and exactly the kind of work that needs to happen for this to mature. It's also early days. There's real room left to run, which is precisely where I've chosen to spend my time.
One more conversation is worth sharing because it isn't about robots at all, and it's the clearest argument I heard all week for why this problem is bigger than humanoid robotics.
At one station, a team was using an AI model to catch product defects on a line moving fast enough to be genuinely fun to watch. The constraint that mattered wasn't the model's accuracy. It was speed: they needed a defect decision in roughly 50 milliseconds, in time to eject the bad unit a couple feet down the line. Getting there took serious compute hardware and serious optimization work, just to hit that one number, on one line.
That's the same problem I've been writing about, wearing a different costume. Not a robot arm this time. A vision model that has to make a real-time decision against a hard deadline, with real consequences if it's late. The companies that figure out how to compress AI inference to meet hard timing constraints aren't just solving robotics. They're solving a much larger category of industrial problem that happens to look like this one from the side.
So where does this leave the thesis from the last two posts?
Confirmed, but not the way I expected going in. I thought the floor would show me a clean split between booths that had the control layer and booths that didn't. What it actually showed me is that the question itself, how do you give a capable robot body a brain that can handle the world as it actually is, isn't yet the question most of the industry is asking. That's not a gap in anyone's effort or talent. It's just early. Most of the floor's enormous energy is, for good reason, focused on getting incredibly good at the problems already in front of it.
I find that encouraging rather than discouraging. A question that hasn't been widely asked yet, sitting underneath a market everyone agrees is enormous, is exactly the kind of opportunity worth building into.
I came home with a sharper question instead of a clean answer: what's the real industrial task that today's hard-automation approach can't quite reach, that's worth solving at volume. I have a few candidates. Working through them is exactly what I'm spending my time on right now.
If you were on the floor at Automate this year, I'd be curious whether you saw the same split, or something different.
Reach me at arif@faris-capital.com
This thesis was originally published on LinkedIn. Join the discussion, add your thoughts, and follow for regular updates.
View on LinkedIn