The Open Architecture Contract: How MCP and i3X Act as the Drainage Pumps of the Autonomous Plant

Executive Takeaway

Open protocols matter because they turn agentic AI from a brittle custom-integration project into a governable architecture. ARC recommends evaluating MCP, i3X, UNS, and identity controls as architectural contracts—not as isolated technology features.

I. The Interoperability Chasm and the CPIA Reality Check

In Blog 1 of this series, “Draining the Agentic Swamp: Moving from Passive Containment to Active Architectural Remediation,” we confronted Rick Bullotta’s sharp observation that containing an agentic swamp is not enough—you have to drain it. We laid out the blueprint for assembling a composable Cyber-Physical Industrial Architecture (CPIA) to purge stale scratchpad memories before they degrade operations.

To ensure we are all singing from the same hymn sheet as we move forward, let us take a quick moment to reground ourselves in how we define CPIA in practice. Unlike standard enterprise IT data fabrics that merely move tabular records from databases to cloud dashboards, a Cyber-Physical Industrial Architecture (CPIA) is an open, multilayer control plane designed specifically for physical, high-consequence operations. It bridges information technology (IT), operational technology (OT), and engineering technology (ET) by strictly separating three concerns:

1. Deterministic Edge DataOps and Quality: Filtering noise and validating signal health locally.

2. Contextual Event Graphs: Mapping real-time asset relationships and events dynamically.

3. Operational Twins and Execution Sandboxes: Providing a single version of operational truth while isolating submillisecond deterministic vPLC control loops from asynchronous cloud agent networks.

Now, as enterprise IT and OT teams sit down together to connect autonomous AI agents across these CPIA layers, they hit a major technological wall: The Integration Chasm.

When software engineering teams attempt to connect AI agents to legacy SCADA networks, historians, manufacturing execution systems (MES), and enterprise resource planning (ERP) databases, they default to legacy IT habits. They write custom REST APIs, build proprietary JSON wrappers, or script bespoke Python data pipelines. In an enterprise with dozens of micro-agents and decades of brownfield plant systems, this point-to-point approach creates an unmaintainable integration swamp. The moment a plant engineer alters a PLC tag address or updates an ERP schema, the custom API pipeline breaks silently, feeding corrupt context to AI reasoning engines.

Why Industry 4.0 and 5.0 Failed to Solve Agentic Interoperability

At this point, my friends in plant management often ask:

“Colin, did Industry 4.0 and Industry 5.0 not already solve interoperability with OPC UA, MQTT, and connected worker frameworks?”

The short answer is no—not for the agentic era.

• Industry 4.0 was fundamentally a movement defined by connectivity and visibility—connecting physical assets to publish raw telemetry to dashboards (“sense and show”). While OPC UA provided transport standards and MQTT/UNS enabled publish-subscribe data decoupling, Industry 4.0 lacked an open, standardized, self-describing tool-execution grammar for autonomous software agents. It gave us data pipes, but no way for an external AI model to dynamically discover, query, and execute operational tools safely.

• Industry 5.0 emerged to reorient digital transformation around human-centricity, resilience, and sustainability. Now, our friends in German manufacturing will politely observe—usually over an Oktoberfest beer—that everything defined as “Industry 5.0” was already implicitly part of Industry 4.0. Furthermore, telling a brownfield plant manager who is still valiantly fighting to drag 20-year-old PLCs out of the Industry 3.0 era that the organization must now leap to “Industry 5.0” is thoroughly deflating. These high-level frameworks are largely designed for pristine greenfield dreams, whereas the real world is an uncarpeted brownfield trench.

To achieve true, governed autonomy on the legacy iron running our actual factories today, we must move beyond the passive connectivity of Industry 4.0 and the high-level principles of Industry 5.0. We must enforce an Open Architecture Contract that delivers a universal grammar and vocabulary across the entire cyber-physical stack.

II. Model Context Protocol: The Universal Grammar for Industrial Tools

The most significant open-standard development for agentic software in recent memory is Anthropic’s Model Context Protocol (MCP).

In simple plant-floor terms, MCP is the “USB-C port” for Industrial AI.

Before USB-C, connecting a camera, a hard drive, or a display to a laptop required a drawer full of proprietary cables, dongles, and drivers. MCP achieves for AI agents what USB-C achieved for hardware: it provides a standardized, open protocol built on JSON-RPC 2.0 that allows an AI model—the MCP client—to securely discover, query, and execute tools hosted by any software system—the MCP server—without custom integration code.

When an edge DataOps hub such as HighByte exposes industrial data through MCP services, or when a SCADA runtime is integrated with an MCP server—such as Siemens’ MCP Server example for WinCC Unified PC Runtime V20 and later—the architecture can expose specific operational functions as standardized, discoverable “Tools” and “Resources”:

• Tool-Binding Example: A maintenance agent queries the MCP server and discovers an available tool called Get_Compressor_Telemetry(asset_id, timeframe). The agent executes the tool call using a standardized JSON payload and receives structured time-series data without needing to know the underlying PLC tag address or historian database schema.

• Resource-Binding Example: An agent requests access to a static P&ID diagram or an equipment manual exposed as an MCP Resource, reading the document in a standardized format without direct file-system access.

• The “Trust Valve” for Data Sovereignty: MCP acts as an architectural boundary. It allows an autonomous agent to query live operational context and execute prevalidated functions without giving public cloud LLMs access to underlying source code, proprietary batch recipes, or full database schemas. The data fabric owner retains absolute custody, with the power to enable or disable tool permissions instantly.

Analyst Assessment: MCP’s Limitations and the Path Forward

As an objective analyst, I would be doing you a disservice if I painted MCP as a flawless, plug-and-play silver bullet today. In our deep research into model pricing architectures and protocol mechanics, several known limitations of early MCP implementations have surfaced:

1. Desktop/Single-User Roots: MCP was originally conceived for local desktop developer runtimes, such as Claude Desktop interacting with local files. In its raw form, it lacks native multitenant enterprise authentication, session management, and high-throughput publish-subscribe streaming.

2. Context-Window Bloat: If a software vendor naively exposes hundreds of verbose API schemas as raw MCP tools, the combined tool definitions can consume large volumes of input tokens on every agent reasoning turn, creating avoidable cloud cost exposure.

3. Ungated Tool Execution: MCP defines how a tool is called, but it does not inherently enforce physical safety envelopes or role-based access control (RBAC).

Why MCP Remains a Strong Path Forward: Despite these initial growing pains, MCP has strong momentum as an open, vendor-agnostic protocol for agent-to-tool interaction. Industrial middleware and enterprise security vendors are beginning to wrap MCP-like interfaces with enterprise-grade authentication, scoped tool exposure, and safety controls. ARC clients should evaluate MCP support carefully, verify implementation maturity, and avoid assuming that protocol support alone provides governance.

III. CESMII i3X and Smart Profiles: The Universal Vocabulary

If MCP provides the standardized grammar for how an agent calls a tool, the industry still requires a standardized vocabulary to define what the data actually means. Calling an MCP tool and receiving a raw numerical payload of 45.2 is meaningless to an AI agent unless that payload inherently carries its physical context: Is this value in Celsius or Fahrenheit? Is it streaming from a temperature sensor on Reactor 4’s cooling jacket or from a vibration monitor on a conveyor?

This is where CESMII’s Industrial Information Interoperability Exchange (i3X) and Smart Manufacturing (SM) Profiles complete the open contract, as we have explored across our recent research into the CESMII i3X framework and data decoupling debates.

Acknowledging CESMII’s Geographic Identity, Analyst Advisory Board Role, and Global Alignment

To ensure complete transparency for our international audience, CESMII—the Clean Energy Smart Manufacturing Innovation Institute—is a US-funded organization sponsored by the U.S. Department of Energy (DOE) as part of a public-private partnership valued at more than $200 million. I am privileged to serve as a member of the CESMII Analyst Advisory Board, an unpaid advisory role, working alongside industry leaders to advocate for open data decoupling and smart manufacturing standards.

It would be a major strategic error for global industrial enterprises to dismiss i3X as a localized US national initiative. On August 4, 2026, at the Scaling Smart Manufacturing & Industrial AI: The Interoperability Forum, co-hosted by CESMII and the Manufacturing Leadership Council, an extraordinary milestone was achieved. More than 32 major industrial software and automation vendors—including Siemens, AVEVA, Schneider Electric,Rockwell Automation, HighByte, Litmus, Velotic, Inductive Automation, Microsoft, Amazon Web Services (AWS), Snowflake, and Cognite—demonstrated live, working interoperability using i3X Smart Manufacturing Profiles and open MCP interfaces across plant-floor, connected worker, intelligent operations, and supply chain use cases.

As  John Dyck, CEO of CESMII, emphasized during the forum:

OT/IT convergence has too often been treated as an organizational merger. What we need is an architectural contract.

This shift is not just felt by technology providers; it is being actively demanded by enterprise manufacturers themselves. During the forum, Brian Perlstein of Owens Corning captured this fundamental power shift in a message to CESMII leadership:

For years, hardware and software vendors have largely dictated manufacturing standards. CESMII/i3X represents a fundamental shift: it’s the manufacturing community defining the requirements, with technology providers enabling the vision, not driving it. Looks like you’re finally solving manufacturing’s toughest challenge… forced interoperability alignment.

         —Brian Perlstein, Digital Manufacturing Innovation Leader, Owens Corning

CESMII’s i3X delivers that exact architectural contract. It enables Governed Freedom: Corporate IT standardizes the interoperable foundation—open profiles, conformant platform services, and the i3X API—while individual plant teams retain the freedom to innovate and deploy local applications, including low-code solutions, vendor applications, and AI agents, that are enterprise-ready by design.

More importantly, i3X actively harmonizes with major international and regional organizations and standards frameworks:

• Alignment with Europe’s Asset Administration Shell: In European manufacturing, the Asset Administration Shell (AAS) defines digital twin structures. CESMII’s i3X and Smart Manufacturing Profiles support direct alignment with AAS-style digital twin structures, helping global enterprises maintain consistent semantic asset definitions across regions.

• Catena-X and Sovereign Data Spaces: i3X’s vendor-neutral manufacturing information API complements data-space initiatives such as Catena-X and Manufacturing-X, allowing contextualized data to move securely across supply chain boundaries without forcing proprietary trade secrets into a central cloud silo.

• Smart Manufacturing Standards Alignment: i3X complements established manufacturing information-modeling standards, including IEC 62264 (ISA-95) and ISO/IEC 21823, transforming static specification documents into executable, graph-aware APIs.

• Prompt Caching and Context Efficiency: From a computational-efficiency standpoint, publishing standardized i3X profiles through MCP-style servers improves context reuse through prompt caching. Because the tool definitions and asset schemas remain static, cloud and edge AI engines may reduce repeated input-token processing, helping to neutralize the “Tokenpocalypse.”

• The UNS and A2A Connections: Published across a Unified Namespace (UNS) event broker powered by MQTT, i3X profiles allow edge platforms to wrap raw telemetry in uniform semantic definitions. When combined with emerging agent-to-agent (A2A) protocols, autonomous micro-agents can negotiate workflows across organizational boundaries using shared, trusted context.

What CESMII demonstrated at the Interoperability Forum on August 4, 2026, is a watershed moment for industrial automation. For decades, the industry treated IT/OT convergence as an organizational merger; CESMII proved it is an architectural contract. By uniting 32+ competing automation giants, cloud hyperscalers, and edge DataOps pioneers around a single plug-and-play API (i3X) and universal tool grammar (MCP), CESMII has delivered ‘Governed Freedom’—standardizing the foundation so plants can democratize innovation without adding technical debt.

        —Colin Masson, Director of Research for Industrial AI, ARC Advisory Group

IV. Headless Identity Contracts: Least-Privilege RBAC for Digital Workers

When an enterprise deploys an agentic workforce, it is effectively onboarding a new population of nonhuman personnel. Treating AI agents as anonymous software scripts that share generic database credentials is a severe cybersecurity vulnerability.

To prevent the formation of unauditable “Agentlakes,” pacesetting organizations enforce Headless Identity Contracts:

1. Agent Identity and Runtime Governance: Enterprise platforms such as Microsoft Agent 365 help establish agent identity, visibility, lifecycle governance, conditional access, and least-privilege controls. Runtime technologies such as NVIDIA OpenShell serve as sandboxing and policy-enforcement layers for agent execution, not as standalone identity systems.

2. Hard-Coded Agency Limits at the Ingest Boundary: Identity contracts enforce strict role-based access control (RBAC) directly at the data fabric layer. An Asset Performance Agent assigned to monitor boiler health possesses least-privilege access; it has no authority to query financial ERP tables, alter access control lists, or programmatically execute write-backs outside its hard-coded operational envelope.

V. Diagnostic Inquiries for Systems and Software Architects

As you evaluate your technology stack against this open architecture contract, consider posing these diagnostic questions to your software vendors and system integrators:

1. Are we building custom glue code or open interfaces?

• Why ask this: Custom point-to-point REST APIs and bespoke scripts create an integration swamp that breaks silently whenever a PLC tag address or ERP schema changes, potentially leading to silent data corruption.

• What good looks like: Mandating native Model Context Protocol (MCP) server support across SCADA, MES, and ERP systems so agents can discover tools through standardized interfaces.

2. How are we implementing MCP to minimize its known enterprise weaknesses?

• Why ask this: Deploying raw, unscoped MCP servers directly to AI agents risks context-window bloat, token-cost spirals, ungated tool execution, and single-user security vulnerabilities.

• What good looks like: Wrapping MCP servers in enterprise security and runtime governance controls, scoping exposed tools to the minimum required set, using prompt caching where supported, and enforcing hard-coded safety gates.

3. How are we defining asset vocabulary across global operations?

• Why ask this: Raw tool outputs such as 45.2 are meaningless to reasoning engines without explicit physical and semantic metadata, including units, asset parentage, and thermodynamic limits.

• What good looks like: Leveraging graph-aware CESMII i3X Smart Manufacturing Profiles over an MQTT Unified Namespace, ensuring semantic interoperability with international standards such as Europe’s Asset Administration Shell (AAS).

4. Are we taking advantage of prompt caching for static profiles?

• Why ask this: Reprocessing static asset schemas, P&IDs, and tool definitions during every agent reasoning step consumes unnecessary input tokens and inflates cloud API bills.

• What good looks like: Structuring static system prompts, tool definitions, and i3X profiles to take advantage of prompt caching where supported, while validating projected savings with each model provider and deployment pattern.

5. How are we authenticating nonhuman workers?

• Why ask this: Allowing AI agents to operate under shared administrator logins or unmonitored API keys creates severe cybersecurity vulnerabilities and unauditable “Agentlakes.”

• What good looks like: Establishing explicit nonhuman identities, scoped permissions, audit logging, and runtime sandboxing for AI agents, using enterprise identity tools and policy-enforcement runtimes rather than shared administrator accounts or unmonitored API keys.

ARC Client Action: Ask vendors to demonstrate live how identity, role boundaries, tool scoping, audit logging, and safety gates operate—not merely whether an open protocol is mentioned in product messaging.

Up Next in Blog 3: With our technical foundation assembled and our data fabric secured through open standards, it is time to confront the most sensitive, high-stakes question in C-suite strategy: What is the true mathematical and economic trade-off involved in replacing human FTEs with autonomous silicon reasoning? In our next post, “The Silicon vs. Carbon Ledger: The Unforgiving Mathematics of the Agentic Labor Trade-Off,” we will synthesize Jared Spataro’s “Tokenomics as Headcount” framework with Puranam’s Headless Firm to deliver a financial playbook for the CFO.

Engage with ARC Advisory Group

The Industrial AI (R)Evolution is moving faster than ever. To dive deeper into the frameworks and data shaping the future of the industrial sector, explore my latest research:

• Navigating the AI Wars and the escalating Industrial Robot Wars

• Closing the Digital Divide by Embracing Industrial AI

• Assembling your Industrial-Grade Data Fabric

• Charting the new frontier of Physical Intelligence and transitioning to a Cyber-Physical Industrial Architecture (CPIA)

• Mapping your maturity and strategy with ARC's 3-Axis Industrial AI Models Taxonomy

Where Do You Stand in the Industrial AI (R)Evolution?

Take our Industrial AI Assessment to benchmark your organization’s maturity, identify critical gaps in your IT/OT/ET convergence, and receive actionable recommendations to accelerate your path toward becoming an Industrial AI Pacesetter.

Don’t guess what your global operations or prospective customers need. Use empirical data to align your stakeholders and dehype the market with ARC Advisory Group’s Voice of Market Service.