MCP on the Plant Floor: Connecting LLM Agents to the Factory, and What's Missing

On September 29, 2026, IIoT World published the second of three installments drawn from the questions left unanswered during the "From Data Streaming to Autonomous Action" session at the Industrial AI Summit 2026. The answers come from Peter Sorowka, CEO of Cybus. The article is labeled "Sponsored by Cybus | Editorially Independent", so it should be read as the view of a vendor's CEO, not as a neutral assessment of the market.

What MCP does on the plant floor

The Model Context Protocol (MCP) is a standard way for an agent to discover and call tools. According to Sorowka, in a plant the "tool" is the factory model itself: namespaces, assets and live values, exposed under the same access rules that apply to people. The result is a single entry point into the plant for any LLM, conversational or agentic, which can understand data and context, read them and act on them.

Sorowka also says customers use a range of platforms:

• hosted assistants such as Copilot Studio, which connect through an API key;
• internal GPT front ends built on OpenAI, Anthropic and Google models;
• self-hosted models when data must stay on site.

Cybus states that Connectware behaves the same way regardless of which model sits on the other end.

Standards: connectivity is there, the rest is not

For Sorowka, connectivity is "largely solved" thanks to OPC UA and MQTT. Contextualization is not: AAS, i3X and UNS conventions compete, and most plants model their data differently from site to site. There is no industrial standard at all for governance between humans and AI: MCP defines the call, not the permission. To scale, a portable way to declare who can read and who can act is needed.

His practical advice is to declare your own model in a form that can later be projected onto AAS or i3X, rather than waiting for one standard to win.

The role of the LLM

Today the LLM is an interface and an orchestrator. Industrial value still comes from purpose-built models: anomaly detection, time-series forecasting, optimization. The LLM retrieves context, calls these models and explains their output. For decisions with physical consequences, declared rules and interlocks must remain binding.

"The model proposes and the policy layer decides."

Agent-to-agent and identity

Today an assistant reaches Connectware through the MCP server using a key that acts on behalf of an identified person. Agent-to-agent chains instead require a distinct identity for the agent, with a clear owner: Cybus lists this as a roadmap item. The company's position is that governance belongs at the factory boundary.

Process matters more than tooling

Sorowka describes most projects as a "steam-to-electricity swap": an agent replaces a dashboard inside an unchanged process. The real gain, he argues, lies in shortening the decision cycle, that is, in reducing handoffs. He expects "hybrid org charts" and warns against underestimating the governance of closed-loop agentic manufacturing.

Practical takeaways

For anyone looking to expose PLC, SCADA and UNS data to LLM agents, the key points are:

• apply least-privilege access, using the same criteria as for people;
• keep interlocks and safety rules deterministic and out of the LLM's reach;
• model data declaratively so it stays portable to AAS or i3X;
• treat agent permissions and identity as open issues and manage them explicitly.

Since this is a partisan source, it is worth verifying these claims against your own use case. The underlying approach, however, is sound: the LLM proposes and explains, while authority over physical actions stays with deterministic rules and controls.