Nvidia is bringing Les Karpas to the TechCrunch Disrupt 2026 stage to explain why robotics still hasn't had its ChatGPT moment. The talk announcement doesn't preview the argument: it says the industry is still waiting for its leap into everyday life and that Karpas has an answer. I'm flagging that up front because it changes how you should read everything that follows: right now there is no published thesis, there's the promise of one.
Why it matters
The signal isn't in what Karpas is going to say, it's in who's saying it. Nvidia sells the compute that much of this industry trains on. Having someone from the inside frame the problem as unsolved, in public and on the most visible stage of the year, is an admission that the bottleneck isn't in the layer they sell. If GPUs were the shortage, the panel would have a different title.
And here's my read. The "ChatGPT moment" was never a capability leap: it was a packaging leap. The transformer already existed, large models already existed, and what changed was that anyone could use them without understanding a thing about what sat underneath. That trick worked because the cost of a wrong answer was zero: you read it, laughed, and wrote the prompt again. In robotics, that free-error economy doesn't exist. An arm that misreads an instruction doesn't produce a weird answer, it breaks something. That's why wrapping the capability better isn't enough: the wrapper isn't the problem.
What changes in practice
Almost none of us are going to write firmware for a robot. But the same conceptual leap shows up every time you connect a model to something that acts instead of answering: an agent that runs a deploy, issues a credit note, sends emails to customers, modifies a ticket in production. At that point you stop having a chat and start having an actuator, with all the consequences that brings.
| Dimension | Model that answers | Model that acts |
|---|---|---|
| Cost of error | Retry and move on | Persistent effect outside the system |
| Rollback | Trivial: throw the text away | Requires explicit compensation |
| Evaluation | You judge the output | You judge the consequence |
| Data | Abundant and already digitized | You have to generate it by interacting |
| Iteration | Cheap and parallelizable | Limited by the physical world or by risk |
Three architecture decisions come out of that, ones I've been holding for a while and that this announcement reinforces. First: separate the layer that decides from the layer that executes. The model proposes a structured action, another component validates it against hard rules, and only then does it run. Second: every irreversible action needs an explicit contract, idempotency, and a written compensation before you enable it, not after the first incident. Third: log the intent alongside the action. When something goes wrong you'll need to know what the model thought it was doing, not just what it ended up executing.
If your product is still at the demo-that-works-on-my-laptop stage, the prototype-to-production panel from that same edition —featuring people from Foxglove, MBRYONICS and Bedrock Robotics— aims at exactly that transition. It's the stretch where most of these ideas die.
When NOT to use it
First, the obvious thing nobody says: this is the announcement of a conference talk. It brings no benchmarks, no architecture, no dates, no definition of what would count as the leap. Taking it as technical evidence is a mistake. It's an agenda signal, and agenda signals are useful for deciding where to look, not for justifying a migration.
Second: don't rebuild your stack waiting for a leap nobody has demonstrated. If your roadmap depends on robotics becoming a commodity in the next twelve months, you don't have a roadmap, you have a bet. The fact that there's venture capital watching the space confirms interest, not technical maturity.
Third, and this is where I see most people getting it wrong: the "agent that decides and executes on its own" pattern is a bad idea when the domain has hard rules and little ambiguity. If the conditions can be enumerated, a state machine with explicit transitions beats a model on cost, on latency, on testing and on auditability. Save the model for where there genuinely is linguistic or perceptual ambiguity. And if your vendor doesn't give you traceability of what ran and why, you're better off waiting: without that you won't be able to explain an incident to a customer, and that conversation is expensive.
What I'd do today
I'd put the talk on my calendar and read it when the real content lands, without drawing conclusions beforehand. In the meantime, I'd invest in the boring layer: typed action contracts, idempotency, compensations and intent logs. That layer serves you just as well whether robotics has its ChatGPT moment next year or never, because it's the same layer you need for any agent that touches production. The leap, if it happens, will reward whoever already has the rails laid down.