Jensen Huang Is Right. That Is Exactly Why Industrial Operations Need a Different Answer.
NVIDIA's CEO just told every technology executive on the planet that agentic AI is the new computer. He is correct. The question is what that means if your company runs a refinery, a mine, or a power plant.
Pieter van Schalkwyk · March 25, 2026
At NVIDIA GTC 2026, Jensen Huang made a claim worth taking seriously.
He called OpenClaw the most rapidly adopted open-source project in history, surpassing Linux’s 30-year adoption curve in weeks. He put it alongside HTTP and Kubernetes. And then he said something that every industrial executive should write down:
“Every single company in the world today needs to have an OpenClaw strategy and an agentic systems strategy. This is the new computer.”
He is right. The question is what that means if your company runs a refinery, a mine, or a power plant.
The Market Education Problem Is Solved
For the past two years, those of us building in the industrial AI agent space have spent a significant portion of every conversation explaining why agentic AI matters: why it is fundamentally different from dashboards, why it changes the operational calculus, why it is not just automation with a better interface.
Jensen Huang has just done that work for us. At scale. Globally. In a keynote watched by every technology executive on the planet.
This is good news. Category creation is expensive and slow. When the world’s most influential technology executive declares that every company needs an agent strategy, the question inside every industrial organisation shifts from “should we be doing this?” to “what does this look like for us?”
That second question is the one industrial AI practitioners actually need to answer. And it is harder than Jensen’s framing suggests.
What Happens Next Is the Problem
The natural response to “every company needs an agent strategy” is to reach for the tools that are already available, already marketed, and already familiar. General-purpose agent platforms are being positioned for industrial operations right now, from large well-resourced vendors with relationships that go back decades into your organisation.
Those platforms are technically impressive. The investment is real, the marketing will be compelling, and the vendors behind them understand OT environments far better than they did five years ago.
What most of them have not built is an architecture that began with the requirements of governed, safety-critical industrial operations.
That distinction matters more than it sounds.
The Starting Posture Problem
There is a concept in software architecture called starting posture. It describes not what a system can be made to do, but what it was designed to do first, before any adaptation, before any configuration, before any professional services engagement.
Most of the agent platforms now being marketed to industrial operations have a starting posture of enterprise IT. They begin with the assumption of a connected network, a permissive security model that can be tightened, and governance that can be layered on afterward. They are being adapted for OT.
Consider the CPU and GPU. For years, engineers tried to run GPU-shaped workloads on CPUs, adding cores, increasing cache, improving scheduling. It was rational. It was also structurally limited, because the CPU was never designed for massively parallel floating-point computation. The performance gap was not a configuration problem. It was an architecture problem.
Industrial agentic operations have the same structure. The requirements of OT environments include air-gapped or severely restricted networks, default-deny permission models, immutable audit trails built to regulatory incident post-mortem standards, and domain knowledge of historian protocols, alarm schemas, and P&ID structures. These are not features you bolt on. They are architectural decisions that shape every other choice downstream.
When you start from enterprise IT and adapt for OT, governance ends up as a layer. When you start from OT requirements, governance is the foundation.
Five Differences That Are Not Marketing
To be specific rather than abstract, here are five places where architectural starting posture produces different outcomes in production.
1. Permission model. OT-native platforms are designed with default-deny from the ground up. Every tool call is explicitly granted, scoped, and auditable. Platforms adapted for OT typically begin with a permissive model and tighten it through configuration. In a safety-critical environment, the difference between “tighten what is permitted” and “explicitly grant what is required” is not semantic.
2. Network assumptions. Platforms designed for connected enterprise environments can be configured for restricted OT networks. Platforms designed for air-gapped and severely restricted networks as the baseline require no configuration to run safely in those environments. This matters increasingly for any industrial operation in a jurisdiction with data sovereignty requirements.
3. Audit trail architecture. Enterprise logging, even good enterprise logging, is not the same as an immutable structured record of every decision, every tool call, and every input built to support regulatory incident post-mortem. The difference only becomes visible after something goes wrong. By then, it is too late to rebuild the audit architecture.
4. Domain knowledge depth. Language models trained on the general web know what a pump is. An OT-native platform encodes how a specific class of pump behaves across a specific process configuration, what the alarm schema means in context, and what a 3% deviation at 2am on a Saturday actually implies for operations. That knowledge gap is the Operational Identity Model problem. You cannot close it through configuration alone.
5. Failure mode design. General-purpose platforms fail gracefully for IT applications. OT environments require that hardware, network, model, and governance failures all produce safe states as a default, not as a configuration option.
The Three-Layer Problem Beneath the Architecture Problem
There is a deeper issue that starting posture alone does not capture.
Foundation model labs are building what I call Layer 1 knowledge: physical and world dynamics. What sensors read. How materials behave. Equipment failure modes. This is the layer NVIDIA’s inference stack, NemoClaw, and the foundation models beneath them are optimised for.
Industrial operations require two more layers. Layer 2 is operational and KPI dynamics: production schedules, quality targets, maintenance windows, energy budgets, throughput constraints. This is operational policy, not physics. It changes when the product changes, when the market changes, when the contract changes. Layer 3 is socio-technical and organisational dynamics: escalation protocols, approval workflows, the heuristics experienced operators carry that exist nowhere in any formal system.
An agent that only understands Layer 1 generates recommendations that are physically plausible and operationally wrong. It will recommend throughput maximisation during a grade transition. It will miss the maintenance window opening tomorrow morning. It will not know that this team escalates differently on night shift.
Getting the architecture right means starting from OT requirements. It also means building for all three layers of knowledge, not just the one the foundation labs are racing to solve.
What This Means for Your Agent Strategy
Jensen is right that every industrial organisation needs an agent strategy. Where I part from the straightforward reading of his message is in the assumption that platforms designed for enterprise IT environments are automatically the right architecture for operations technology.
The most common failure mode in industrial AI deployments is not ambition. It is the assumption that a platform designed for a different problem shape can be adapted to fit. It can, often, to a degree. The degree is the question.
If your organisation is building its agent strategy for industrial operations, the right starting question is not “which of the available platforms should we configure for our environment?” It is “what does a platform look like that was designed for our environment from the first line of code?”
That is a different question. It leads to a different answer. And given the governance, safety, and audit requirements of industrial operations, it is worth asking before the deployment is in production.
Jensen has told you the category is real. The architecture you choose to build it on is the decision that actually matters.
IndustrialClaw is built for that decision. OT-native architecture, three-layer knowledge, governed from the ground up. See how it works or talk to us about what your agent strategy looks like in an industrial context.
Pieter van Schalkwyk is CEO of XMPro and lead author of the Digital Twin Consortium’s Industrial AI Agent Manifesto.