LLM Agents on the Factory Floor: MCP Architecture and the Governance Gaps

On September 29, 2026, IIoT World published the second of three installments drawn from audience questions left unanswered in the session "From Data Streaming to Autonomous Action" at the Industrial AI Summit 2026. Peter Sorowka, CEO of Cybus, answers six architecture questions. One caveat up front: the article is labeled as sponsored by Cybus ("Editorially Independent"), and the session was sponsored by Cybus, Barbara and HiveMQ. It is therefore a vendor's point of view, not independent research, and should be read as such.

The MCP server as the gateway to the factory

MCP (Model Context Protocol) is a standard way for an agent to discover and call tools. In an industrial setting, the "tool" is the factory model itself: namespaces, assets and real-time values. These are exposed under the same access rules that apply to people. As a result, any LLM, conversational or agentic, can understand the data and context, read it and act on it.

Cybus sees three recurring patterns among its customers:

• hosted assistants, such as Copilot Studio, connected via API key;
• internal GPT interfaces built on models from OpenAI, Anthropic and Google;
• self-hosted models, when data must stay on the plant site.

According to the company, its Connectware platform behaves the same way regardless of which model is used.

Standards: connectivity is there, context is not

For Sorowka, connectivity is "largely solved" thanks to OPC UA and MQTT. Contextualization is not: AAS, i3X and UNS conventions compete with one another, and most plants model their data differently from site to site. There is also no industry standard for governance in human-AI interaction. MCP governs the call, not the permission: to scale, you need a portable way to express who can read and who can act.

MCP covers the call, not the permission.

The role of the LLM and the policy layer

Today the LLM is mainly an interface and orchestrator. Industrial value still comes from purpose-built models for anomaly detection, forecasting and optimization. The LLM gathers context, calls these models and explains the results in a single loop. For decisions with physical consequences, the recommendation is to bind them to declared rules and interlocks: the model proposes, and a policy layer decides what is allowed.

Agent-to-agent: the identity problem

Today an assistant reaches Connectware via MCP with a key that acts on behalf of an identified person. In agent-to-agent chains, "on behalf of a person" is no longer enough. A separate identity for the agent, with a clearly assigned owner, is listed as a roadmap item. Cybus's position is that governance belongs at the factory boundary.

Change the process, not just the tool

Sorowka describes most projects as a "steam-to-electricity swap": an agent in place of a dashboard, in a process that stays the same. The real benefit comes from shortening the decision cycle, that is, the number of handoffs. He also warns against underestimating security and approval workflows in closed-loop agentic production.

Key takeaways

For those leading AI projects on the plant floor, the practical guidance is:

• place MCP at the plant boundary, with access limited to the caller's identity;
• insert a policy layer and interlocks between AI and actuation;
• declare the data model in a form that can later be projected onto AAS or i3X, rather than waiting for one standard to prevail;
• weigh the claims with caution, since this is a vendor perspective.

The article's value lies in its honesty about limits: contextualization and agent identity remain open. Modeling data in a portable way is a low-regret step you can take now.