Robotics in 2026: Real Progress, Real Limits

Francois Chaubard opened Y Combinator's recent robotics Paper Club with a line that deserved a longer pause than it got: "This is the 10th year of 'next year, robotics will be solved' that I've encountered in my career."

He wasn't being cynical. He was being precise. AlphaGo in 2016 suggested the algorithm was basically done. MuJoCo showed robots learning to walk in thousands of training iterations. The ALOHA system made a Keurig coffee and everyone exhaled like the hard part was over. Then diffusion policy arrived and the pitch reset again. Now we have vision-language-action models — VLAs — and the promise was 2026. It's July 2026. You can pre-order a humanoid. You cannot buy one.

What the session mapped, across five presentations from researchers at Stanford, Waymo, and YC-backed General Instinct, is something more useful than a prediction: a clear-eyed inventory of what is actually unsolved, alongside some genuine technical progress on specific sub-problems. That combination — honesty about the walls, real work on getting over them — is rarer than it should be in a field that runs on hype.

The Four Walls

Chaubard's framework for why robotics keeps missing its deadlines is worth taking seriously. He identified four fundamental problems, and the interesting thing is that none of them are software problems in the narrow sense.

The first is physical world modeling. Current video models, even impressive ones, don't respect physics. Drive a simulated car into a Whole Foods and it turns into a highway. No crash. The sim-to-real gap — the difference between what works in simulation and what works in a warehouse at 3 a.m. — remains genuinely unsolved.

The second is action representation. Figuring out how to encode what a robot should do, at what granularity and in what format, is still an open research question. The action space problem compounds the data collection problem: if your representations are wrong, more data doesn't help.

The third, and Chaubard was emphatic about this, doesn't get enough attention: the sensorimotor gap. Human skin is a dense sensor array. We detect normal force, tangential force, moisture, temperature, vibration, and friction coefficient — everywhere, all the time. A state-of-the-art robot hand has a force-torque sensor on each fingertip and a wrist camera, and that's considered good. "There's no way we have robots that can do that now because we don't have an epidermis," he said. The hockey skate analogy he used captures it well: try tying your skates in extreme cold and you'll feel your own motor policy fail.

The fourth is embodiment drift. Actuators corrode. Dust gets in. Batteries degrade. The mapping between "command applied" and "force delivered" shifts over months of operation, which means training data goes stale and you have to recollect it. This is mundane, unglamorous, and genuinely hard.

Three Approaches Worth Watching

Against that backdrop, the session's research presentations were refreshingly grounded.

Memory. Marcel Torne, a PhD student in Chelsea Finn's lab at Stanford who worked on this at Physical Intelligence, presented a system called MEM — Multi-Scale Embodied Memory. The problem he addressed is almost comically basic: most current robot policies have no memory. At every timestep, the robot gets a new observation and has no context for what came before. The demonstration failure modes — a robot washing dishes indefinitely because it doesn't know it started, a grilled cheese left on a burner until it burns — are less funny when you're trying to deploy these systems in real kitchens.

MEM splits memory into two tiers: dense visual frames for short-term dexterity at the low level, and a compressed text-based "memory scratch pad" for long-horizon task tracking at the high level. The architecture sidestep is elegant — text tokens are far cheaper computationally than image tokens, so the high-level planner can maintain a rolling summary of what has happened without the inference cost exploding. The practical result is a robot that notices it made a mistake and corrects course, rather than attempting the same failed grasp in a loop. Text memory has its limits — "ideally we would have a latent embedding that would just keep track of all the memory," Torne acknowledged, "but just with text you can actually put a very strong bias there and be able to supervise it, be able to debug it" — and that pragmatism seems like the right call for now.

Selective reasoning. Milan Ganai, a Stanford PhD student researching at AWS and Waymo, tackled a more subtle problem: not what robots should do, but what they should think about before acting. The chain-of-thought reasoning that made LLMs dramatically more capable has an obvious appeal for robotics. But applying it naively creates a different problem — too much reasoning is as bad as none. Planning at every timestep is redundant. Cataloguing every object in a scene is distracting. Ganai's framework, called R&B EnCoRe, uses a self-supervised cycle to discover which types of reasoning are actually action-predictive for a given embodiment. For manipulation tasks, tracking the gripper position helps; cataloguing all visible objects mostly doesn't. For legged locomotion, reasoning about structural affordances matters more than terrain analysis. The finding that "selective reasoning is way more important than exhaustive reasoning" sounds obvious once stated, but nobody was measuring it systematically before.

Simulation as a data source. Tyler Lum presented SimToolReal, which approaches the data scarcity problem from the opposite direction of teleoperation. Rather than collecting human demonstrations, the system trains entirely in simulation using massively parallel reinforcement learning — tens of thousands of virtual robots running simultaneously, generating the equivalent of decades of experience in days. According to Lum and the published SimToolReal paper, the resulting policy simultaneously controls a 22-degree-of-freedom hand and a 7-degree-of-freedom arm at 60 Hz, zero-shot, across tools and tasks it has never seen. What makes it work is the framing: rather than learning separate policies for grasping, reorienting, and using each tool, the system learns a single goal-conditioned policy — move this object from here to there — and a human video demonstration provides the target trajectory at inference time. The video doesn't train the policy; it just specifies what "done" looks like. The gap between demo and deployment has long been robotics' defining embarrassment; the strength of SimToolReal is that it was evaluated on novel tools in real hardware, not just impressive simulation footage.

The Business Case for Starting Small

Perhaps the most practically useful talk came from Niko West, co-founder of Rerun.io, who has spent years watching robotics companies succeed and fail from the infrastructure side. His argument is straightforward: the next generation of successful robotics companies won't be the ones trying to build general-purpose humanoids. They'll be focused application companies that own a specific business problem end-to-end, start with teleoperation to validate the business before training any models, and treat autonomy as a gradual scaling factor rather than a prerequisite.

"The physical world is brutal," he said. "Everything that you do is going to break, and you will not have thought of all the different failure modes up front. It is not possible to think of them all in the lab."

His prescription: pick one customer problem someone will pay you to solve, deploy with off-the-shelf hardware and a human operator, learn what actually breaks in production, and then start training models on the data that proves itself useful. The point about data collection discipline is one that keeps surfacing from practitioners — don't collect all your data first and train later. That is, apparently, a very common and very expensive mistake.

The Hardware Economics Problem

General Instinct, a YC company building inference infrastructure for physical AI, pointed to a constraint that the research presentations mostly sidestepped: the compute cost of running world action models at scale. The most capable architecture — dream about the future, predict the kinematics — requires substantial hardware. Bill Jiao noted during the session that running such a model can require two GB200 GPUs, and according to reporting by Tweaktown, NVIDIA's GB200 superchip costs up to $70,000 per unit. Multiply that across a robot fleet and the economics collapse before you even discuss the software.

Their response is a compression stack: knowledge distillation on both the encoder and the diffusion transformer, splitting the video and action transformers rather than running a single monolithic model, and reducing the diffusion sampling steps. The engineering direction is clear even if the results are still being validated. The question of how to preserve the representational richness of world models while making them deployable on hardware that doesn't cost more than the building the robot is working in is going to define the next phase of commercial robotics development.

The research in this session is real. The problems are also real, and older than the solutions. Chaubard's ten-year count suggests some humility about when the walls finally come down — but for the first time in a while, the people identifying the walls are the same people doing the climbing.

---

By Bob Reynolds, Senior Technology Correspondent, Buzzrag