Editor's note: This is the second article of a new five-part series by Colin Masson of ARC Advisory Group where he's taking a no-nonsense look at how the latest wave of AI collides with the physical laws of the plant floor.

He’s stripping away the hyperbole about AI, deconstructing the vendor marketing narratives, and providing plant managers, operations executives, and enterprise architects—part of our core audience—with actionable blueprints for governed and profitable implementations.

See Part 1: Why billion-dollar AI model claims fall apart on the factory floor

If I have to sit through one more software vendor keynote where an executive proudly presents a 30-year-old software stack as a "ground-up, AI-native, autonomous enterprise engine," I might just pull the emergency stop on the entire convention center.

Let’s be brutally honest: "AI-native" has officially overtaken "cloud-native" as the most egregiously overused, sanitized, and meaningless marketing label in enterprise software.

See also: Smart Industry's annual State of Initiative Survey is open!

Over the past 18 months, incumbent software providers across supply chain planning, ERP, MES, and warehouse management systems have been scrambling to slap generative AI co-pilots onto legacy relational screens, containerize monolithic databases in hyperscaler clouds, and rebrand themselves as AI-native platforms.

Here is the great irony: In mission-critical physical operations, being "AI-native" from scratch is actually an operational disadvantage.

Deconstructing the vendor M&A genealogy

When you peel back the slick marketing layers and examine the actual computational engine of modern enterprise software, what do you really find?

Look at the historical genealogy of industrial computing. Over the last three decades, software giants expanded their portfolios through aggressive mergers and acquisitions.

They acquired Manugistics for mathematical supply planning, absorbed i2 Technologies for constraint-based factory scheduling, integrated RedPrairie for high-throughput warehouse logistics, and acquired dozens of localized MES point solutions to manage plant-floor execution.

See also: Hitachi maps where manufacturers are successfully deploying AI and where they're falling short

Did these software giants secretly burn tens of millions of lines of proven C++, PLC logic, and procedural execution code to rewrite their entire portfolios from scratch as pure neural networks? Of course not.

Doing so would have been commercial suicide and an operational catastrophe for their customers. If a software vendor replaced a deterministic linear solver with a probabilistic neural network, your warehouse picking routes would hallucinate, supply chain constraints would dissolve, and safety interlocks would fail.

The pragmatic alternative: Encapsulating IP into “skills”

What pacesetting software vendors are actually doing—and what industry leaders should be praising them for rather than letting them hide behind buzzwords—is making an intelligent, pragmatic architectural trade-off.

Instead of undertaking a high-risk, multi-year "rip-and-replace" refactoring project that breaks customer operations, software architects are encapsulating legacy intellectual property into reusable, deterministic “skills” for modern agentic AI.

In a production-grade industrial architecture, an “AI skill” is not an open-ended natural-language prompt. It is a strictly typed, governed block of encapsulated domain logic:

• Defined interface: Standardized input/output schemas, explicit parameter boundaries, and role-based permissions.
• Deterministic execution path: Under the hood, the skill executes a battle-tested linear programming solver, an optimized C++ routing algorithm, an MES dispatch routine, or a validated machine control script.
• Safety and governance boundaries: Hard operational corridors that limit the scope of execution, preventing non-deterministic AI behavior from causing physical or financial havoc.
• Domain competence: A discrete, highly specialized capability—such as “calculate dynamic safety stock under lead-time variance,” “re-wave picking zone B for urgent cross-docking,” or “validate pump discharge pressure against operational envelopes.”

By placing an agentic orchestration layer above the deterministic execution engine, the platform lets probabilistic AI do what it does best: parse unstructured exceptions, reason over contextual anomalies, and communicate naturally.

Podcast: Takeaways from IFS Unleashed and how industrial AI is advancing

When it comes time to execute a mathematical optimization or update a transactional database, the agent calls the legacy solver as a deterministic tool.

The buyer's tri-domain dilemma

As operations executives evaluate candidate platforms across their enterprise, they quickly discover that the storyline changes dramatically depending on where you sit in the software stack. Industrial software spans three distinct operational domains:

• Supply chain solutions: The core IP consists of decades of dynamic safety stock formulas, multi-echelon inventory constraint math, and C++ linear programming engines. Pure-play cloud overlays offer cross-silo decision intelligence, but incumbent suites that own the underlying execution tables maintain the upper hand in automated, closed-loop execution.
• Factory-floor operations (OT/MES): IT executives have spent twenty years predicting the demise of MES, calling for it to be replaced by cloud analytics or ERP. Yet MES has proven to be the ultimate cat with nine lives. Why? Because the shop floor cannot tolerate probabilistic decision latency or network outages in execution-critical paths. If a cloud model encounters network jitter during a high-speed packaging or chemical batch run, equipment breaks, product is scrapped, and worker safety is compromised.
• Enterprise Core (ERP/CRM/EAM): In the enterprise core, legacy IP is defined by financial ledgers, statutory compliance rules, tax codes, SOX/GxP audit trails, and complex workflow authorizations. Here, an ungrounded AI decision does not break a physical machine; it causes financial misstatements, regulatory non-compliance, or corrupted master data.

The fallacy of the monolithic 'industrial data platform'

Before modernizing, enterprise architects must confront a terminology trap: the attempt to revive the legacy concept of an all-in-one “industrial data platform.”

Twenty years ago, calling an on-premises historian or MES database a “data platform” made operational sense. It was a self-contained silo that gathered time-series tags, compressed them into proprietary files, and served them to local screens.

In 2026, closed monolithic platforms are indefensible. No single software package can simultaneously serve as a sub-second edge connectivity broker, a hyperscale analytical cloud repository, an enterprise-wide knowledge graph, and a deterministic machine execution core.

See also: The death of conversational chatbots in industrial organizations

Industry pacesetters—including Emerson/AspenTech, AVEVA, Schneider Electric, and Cognite—are actively proving this shift. Rather than defending all-in-one platform silos, they are engineering open, decoupled industrial data fabrics:

• Decoupling data from applications: Storing high-scale telemetry in open formats (such as Apache Iceberg or Parquet) across cloud lakehouses.
• Standardizing semantics: Leveraging open semantic profiles like CESMII’s i3X and Europe’s Asset Administration Shell (AAS) over MQTT Unified Namespaces.
• Preserving proven-solvers: Wrapping deep domain logic into open APIs and model context protocol tool endpoints.

The central takeaway for plant managers and operations leaders is clear: Do not tear out your operational systems to chase algorithmic fashion.

Wrapping battle-tested domain logic into governed, type-safe skills within an open industrial data fabric isn't a compromise—it is the smartest, most resilient architecture in software.