Industry 4.0 promised connected factories, intelligent automation, and seamless data flow between machines, systems, and humans. The technology arrived. The connectivity did not.
The reason is a number called N times M.
An enterprise manufacturing facility might have 12 AI agents across quality, maintenance, and planning — and 28 data sources including ERP, MES, SCADA, IoT sensors, databases, CAD repositories, and supplier APIs.
Without a standard protocol: 12 agents multiplied by 28 data sources equals 336 custom integrations.
Each integration is bespoke code. Each breaks when either side updates. Each requires maintenance. Each represents a point of failure and a security surface that must be independently managed.
IBM VP Armand Ruiz stated this precisely: "Without a common standard, every integration is costly duct tape."
MCP and ACP together replace 336 pieces of duct tape with two standard protocols — one governing how agents connect to systems, one governing how agents connect to each other.
The smart manufacturing market is projected to reach 374 billion dollars by 2025 at 11.8 percent CAGR. Over 50 percent of companies in industrial automation are expected to adopt MCP-based connectivity. The integration problem is not theoretical. The solution is being deployed at scale right now.
MCP connects agents to tools and data — the vertical integration layer. It handles the connection between an AI agent and everything it needs to interact with in the external world.
MCP was created by Anthropic, open-sourced in late 2024, and donated to the Linux Foundation's Agentic AI Foundation in December 2025. MCP 1.0 shipped in early 2026 with a mature specification. Over 18,000 community-indexed MCP servers are listed on Glama.ai and MCP.so as of March 2026. Tens of millions of monthly SDK downloads confirm it as the de facto standard for agent-to-tool connectivity.
MCP standardizes how applications deliver tools, datasets, and sampling instructions to LLMs — akin to a USB-C connector for AI systems. It supports flexible plug-and-play tools, safe infrastructure integration, and compatibility across LLM vendors.
MCP follows a client-server architecture with three components:
The Host is the AI application or agent runtime that initiates MCP connections and orchestrates communication workflows.
The MCP Client lives inside the host and manages the connection to one or more MCP servers, handling protocol-level communication.
The MCP Server is a lightweight service that wraps a specific tool, data source, or system and exposes it through the MCP standard. The server holds the credentials and logic to communicate with the underlying resource. The format of requests and responses is standardized regardless of transport.
MCP exposes three capability types through every server:
Tools are executable functions the agent calls to take action or retrieve information. Query a database. Execute a SCADA command. Read a sensor. Update an inventory record. Each tool has a name, a description the model reads to decide when to use it, and a typed input schema.
Resources are data sources the agent reads. A machine specification file. A maintenance history record. A production schedule. A CAD drawing. Passive data the agent accesses rather than executes.
Prompts are versioned instruction templates managed server-side. Centralized prompt logic accessible to any agent connecting to that server.
MCP communicates over JSON-RPC 2.0. Every tool call follows this exact structure:
{
"jsonrpc": "2.0",
"method": "tool.call",
"params": {
"tool": "machine_sensor_api",
"action": "read_vibration",
"arguments": {
"machine_id": "CNC-412",
"sensor_type": "spindle_bearing",
"interval_seconds": 60
}
},
"id": 1
}
The MCP server executes against the actual sensor system and returns:
{
"jsonrpc": "2.0",
"result": {
"machine_id": "CNC-412",
"vibration_rms": 4.87,
"threshold": 3.50,
"status": "anomaly_detected",
"timestamp": "2026-05-08T09:14:22Z"
},
"id": 1
}
The agent receives this structured result and reasons over it — without knowing anything about the sensor hardware, the communication protocol it uses, or the data format of the underlying system. MCP handles all of that abstraction.
MCP supports two transport mechanisms suited to different deployment contexts:
stdio transport runs the MCP server as a subprocess. The host communicates via standard input and output. Zero network exposure. Secure by design. Optimal for local deployments and air-gapped industrial environments.
HTTP with SSE runs the MCP server as an HTTP service with Server-Sent Events for streaming. Optimal for remote servers, cloud deployments, and multi-tenant architectures.
In industrial environments, stdio is preferred for on-premises machinery with security constraints. HTTP with SSE is used for cloud-connected systems, ERP integrations, and supplier data feeds.
The practical connectivity that MCP enables in production covers every layer of the industrial data stack.
ERP Systems
An MCP server wraps the SAP or Oracle ERP API. The AI agent queries production orders, inventory levels, and supplier lead times through standard MCP tool calls without custom ERP integration code. The same MCP server is used by the production planning agent, the procurement agent, and the quality control agent — each consuming the same interface for different purposes.
MES (Manufacturing Execution Systems)
An MCP server wraps the MES API to expose real-time production status, work order management, and operator assignments. The maintenance agent queries the MES for shift schedules when planning downtime windows. The quality agent reads process parameters to correlate with defect events.
SCADA and IIoT Sensor Networks
An MCP server wraps the SCADA system's data historian or OPC-UA interface. The AI agent reads real-time and historical sensor data — temperature, pressure, vibration, flow rate, electrical consumption — through structured MCP tool calls. Commands can flow in the reverse direction: the agent calls the SCADA tool to adjust a setpoint or trigger a controlled shutdown through the same protocol.
Databases
An MCP server wraps any SQL or NoSQL database. Natural language questions become structured queries executed through the MCP tool interface. The agent does not write raw SQL — it calls the database tool with structured parameters, and the MCP server handles query construction, execution, and result formatting.
Hardware and Robotics
A recent robotics project demonstrated an AI-powered robot using Claude AI with MCP as middleware between the AI and the hardware. Using MCP, the agent queries a CAD document repository for product specifications, fetches current machine status from IIoT sensor platforms, and sends commands to the robot's control interface — all through the same unified protocol.
This is the N times M solution in practice. Each data source or hardware system is wrapped once in an MCP server. Every AI agent in the organization that needs access connects through the standard protocol. New agents get immediate access to all existing MCP servers without writing new integration code.
Predictive Maintenance
The Stuttgart factory scenario from the opening is precisely where MCP delivers its highest value. The maintenance AI agent connects through MCP servers to vibration sensor streams from 847 CNC machines, historical failure records from the maintenance database, parts inventory from the ERP system, service manuals from the CAD repository, and operator schedules from the HR system.
All five connections use the same MCP protocol. The agent calls different tools — sensor reading, database query, inventory check, document retrieval, schedule lookup — each implemented as a separate MCP server wrapping a separate underlying system. The agent's code is identical regardless of which system it is querying.
Quality Control Vision Systems
An MCP server wraps a computer vision API inspecting products on a conveyor belt. The AI agent calls the vision tool, receives defect classification and severity scores, queries the process parameter database through a second MCP server to identify correlation with upstream conditions, and generates a process adjustment recommendation — all through standard MCP calls, all in real time.
Energy Management
MCP enables AI agents to control factory equipment through structured, schema-based tools. Whether controlling manufacturing workflows or optimizing energy consumption, MCP translates natural language instructions into action on physical systems. JSON-RPC based toolchains enable structured, real-time interaction between LLMs and physical systems across industrial IoT environments.
An energy management agent connects through MCP to electricity meters, HVAC systems, compressed air networks, and production scheduling. It reads current consumption, queries production plans, and issues setpoint adjustments to reduce peak demand — all through MCP tool calls to different underlying systems, all through the same protocol.
Smart Manufacturing Context
MCP creates a secure two-way connection between industrial systems — ERP, MES, Unified Namespace — and AI tools. It does not just pass data. It gives context, allowing AI to truly understand the system it is working with. This shifts industrial integration from fragile patchwork connections to intelligent, universal connectivity — a necessary leap for factories that truly think for themselves.
ACP was designed to complement MCP. ACP connects agents to agents. MCP connects agents to their tools and knowledge. ACP is to agent communication what HTTP was to web documents. Its stated goal from IBM: to build the HTTP of agent communication.
ACP was developed by IBM Research and contributed to the Linux Foundation's BeeAI community in March 2025. It is now officially part of the Linux Foundation's Agentic AI Foundation. BeeAI is the official open-source reference implementation — a platform for discovering, running, deploying, and orchestrating ACP-compliant agents regardless of the framework they were built with.
ACP is designed with a production-grade focus, prioritizing security, scalability, and observability to ensure reliable performance in real-world, large-scale deployments. ACP remains intentionally agnostic to internal implementation details, specifying only minimal requirements for compatibility. Agents built with LangChain, CrewAI, BeeAI, or custom code can interoperate seamlessly — fostering a truly modular and scalable ecosystem.
Where MCP solves the vertical problem — one agent connecting to many tools — ACP solves the horizontal problem — many agents connecting to each other.
The ACP architecture is a modular, HTTP-based system composed of three primary components: the ACP Client, the ACP Server, and one or more ACP Agents.
The ACP Client initiates communication by submitting requests in ACP-compliant format. It supports message composition using ordered message parts, session-based interactions for multi-turn workflows, and both synchronous and streaming execution modes.
The ACP Server acts as middleware, translating external HTTP requests into internal agent executions.
ACP features a minimalist, web-native approach to multi-agent interoperability. Every agent — whether an LLM, a simple tool wrapper, or a microservice — is treated as an easily accessible REST-style web service. ACP's message schema centered on roles and multi-modal Parts allows agents to seamlessly exchange text, images, audio, or artifacts within a unified envelope without requiring complex payload parsing. It natively supports a router agent topology to mediate complex workflows and task distribution.
An ACP message between two agents looks like this:
{
"type": "request",
"from": "maintenance_agent",
"to": "procurement_agent",
"action": "check_parts_availability",
"payload": {
"part_number": "SKF-6205-2RS",
"quantity_needed": 2,
"required_by": "2026-05-09T06:00:00Z",
"priority": "critical"
}
}
The procurement agent responds:
{
"type": "response",
"from": "procurement_agent",
"to": "maintenance_agent",
"status": "completed",
"result": {
"in_stock": true,
"quantity_available": 8,
"warehouse_location": "B-14",
"estimated_delivery": "2026-05-08T22:00:00Z",
"alternative_supplier": null
}
}
The maintenance agent receives this structured response and continues its workflow — scheduling the maintenance window with confidence that parts are available — without the maintenance agent and procurement agent sharing a codebase, a framework, or even a deployment location.
ACP supports three execution modes suited to different industrial workflow requirements:
Synchronous uses standard HTTP POST returning JSON. The calling agent waits for the response. Optimal for fast queries where the result is needed before proceeding. Suitable for inventory checks, schedule queries, and status requests.
Asynchronous uses fire-and-forget with a taskId returned immediately. The calling agent polls or subscribes for progress. Optimal for long-running tasks like complex analysis, report generation, or coordination with external systems.
Streaming via SSE has the responding agent stream intermediate results back as the work progresses. Optimal for real-time monitoring, live analysis feeds, and any task where intermediate results are valuable before final completion.
ACP uses offline discovery. Agent capabilities are declared at build time through agent manifests — not negotiated at runtime. This design choice eliminates runtime discovery dependencies and makes capability contracts explicit and version-controlled.
All ACP calls are OTLP-instrumented. BeeAI ships traces to Arize Phoenix out of the box. Agent lifecycle states — INITIALIZING, ACTIVE, DEGRADED, RETIRING, RETIRED — are emitted as OpenTelemetry spans, enabling operations teams to automate rollouts or garbage-collect zombie agents.
Built-in observability is a production requirement in industrial environments. An agent that has gone DEGRADED due to sensor connectivity loss needs to be detected and replaced automatically — not discovered through a maintenance incident two hours later.
Multi-Agent Manufacturing Orchestration
The Stuttgart factory scenario requires not just MCP tool access but ACP agent coordination. When the maintenance agent detects the bearing anomaly on CNC-412 through MCP sensor tools, it initiates an ACP coordination sequence.
The maintenance agent sends an ACP request to the production planning agent to assess the impact of taking CNC-412 offline. The production planning agent queries its own MCP tools — scheduling database, customer order backlog, alternative machine capacity — and responds with a recommended maintenance window and a revised production plan. Simultaneously the maintenance agent sends an ACP request to the procurement agent to verify bearing stock. The procurement agent uses its own MCP tools to query the warehouse system and responds with availability.
Three agents. Three independent tool sets accessed through MCP. One coordination sequence through ACP. All completing before the human supervisor finishes reading the alert.
Cross-Company Supply Chain
ACP was built for cross-company workflows. Companies can automate order processing between suppliers, coordinate shipping updates, or handle questions that span multiple organizations. The protocol works with OAuth 2.0, API keys, and custom business identity systems. Cross-company capabilities create new business models through secure agent collaboration between organizations.
A manufacturer's procurement agent sends an ACP message to a supplier's inventory agent requesting lead time on critical parts. The supplier's agent queries its own internal systems through its own MCP servers and responds. No custom API integration between the two companies. No data exposure beyond the specific query. ACP handles authentication, message structure, and response format — both sides built on the same open standard regardless of what internal frameworks they use.
Incident Response Automation
When a monitoring agent detects a performance issue, it can automatically trigger an incident response agent to create tickets, notify teams, and coordinate with deployment systems to roll back changes. ACP enables this cross-platform integration across the full technology stack — monitoring, analytics, development tools, and communication systems.
In an industrial context: a quality control agent detects a defect rate spike through MCP vision tools. It sends an ACP message to the process engineering agent to analyze root cause. Simultaneously it sends an ACP message to the production manager agent to assess hold decisions. Both specialist agents use their own MCP tool access to gather data and respond with their analyses. The quality control agent synthesizes both responses and escalates to human review through a defined ACP human oversight channel.
IoT Device Management at Scale
ACP's simplicity and REST-based design make it ideal for IoT device management where thousands of sensors need simple HTTP communication without heavy protocol libraries. A fleet management agent uses ACP to coordinate with 200 regional monitoring agents, each responsible for a geographic cluster of IoT devices. Each regional agent uses MCP to connect to its cluster's sensor data, maintenance records, and control systems. The fleet agent coordinates through ACP without knowing the internals of any regional agent's implementation.
Understanding these six differences precisely is what prevents the most expensive architectural mistake in industrial AI deployment — using the wrong protocol for the wrong layer.
Difference 1: Direction of connection
MCP is vertical. It connects an agent downward to tools, databases, APIs, and hardware systems. The agent is always the caller. The tool is always the callee. The relationship is hierarchical.
ACP is horizontal. It connects agents laterally to other agents. Either agent can initiate. Either agent can be the callee. The relationship is peer-based.
Difference 2: What is on the other end
On the other end of an MCP connection is a system — a database, an API, a sensor, a file, a hardware interface. It does not reason. It does not make decisions. It executes and returns data.
On the other end of an ACP connection is an agent — an intelligent system that reasons, plans, uses its own tools, and returns the product of intelligence rather than raw data.
Difference 3: State model
MCP is stateless. There is no built-in session persistence between calls. Each tool call is independent. The agent maintains context in its own memory or state object — not in the MCP protocol.
ACP supports stateful multi-turn sessions natively. An ACP conversation between two agents can span multiple message exchanges with session context maintained at the protocol level. This is essential for complex coordination workflows that cannot complete in a single message exchange.
Difference 4: Transport and infrastructure requirements
MCP uses stdio or HTTP with SSE. Lightweight. Works in air-gapped environments. No SDK required on the tool side — any system that can respond to JSON-RPC requests can be wrapped as an MCP server.
ACP uses JSON-RPC over HTTP and WebSockets. Supports both synchronous HTTP POST and async streaming. Designed for clusters and local-first environments before scaling to public internet. The BeeAI reference implementation provides thin async clients, graphical inspection, and OTLP instrumentation out of the box.
Difference 5: Discovery mechanism
MCP tools must be pre-configured. The agent host lists which MCP servers to connect to. No automatic capability discovery at runtime.
ACP uses offline discovery. Agent capabilities are declared through manifests at build time. Clients can discover agents via direct invocation, registry lookup, or offline metadata embedded in agent packages.
Difference 6: Governance and maturity
MCP: Anthropic origin, Linux Foundation governance since December 2025. MCP 1.0 specification mature. 18,000 plus community servers. Tens of millions of monthly SDK downloads. The de facto standard.
ACP: IBM Research origin, Linux Foundation BeeAI governance since March 2025. Now officially part of the Linux Foundation's Agentic AI Foundation. Production-grade focus with security, scalability, and observability as primary design constraints.
MCP ensures an AI model or agent can connect to external tools and knowledge. ACP ensures multiple agents can share results and coordinate actions once they have that data. Together they form the complete communication infrastructure for multi-agent AI systems.
ACP intentionally reuses MCP message types where possible. Nothing prevents an ACP agent from also using MCP internally — an agent receives an ACP coordination request, uses its MCP tools to gather the data it needs to respond, and returns the result through ACP.
The complete industrial AI stack with both protocols:
HUMAN OVERSIGHT LAYER
|
v
ORCHESTRATOR AGENT
Uses ACP to coordinate specialist agents
|
ACP Protocol (horizontal)
|
-----+---------------------
| |
v v
MAINTENANCE AGENT PROCUREMENT AGENT
Uses MCP for tools Uses MCP for tools
| |
MCP Protocol (vertical) MCP Protocol (vertical)
| |
+----+----+ +----+----+
| | | |
v v v v
SCADA Maintenance ERP Supplier
Sensors Database System API
Every agent in this architecture uses both protocols. MCP downward to access its own specialized tools and data. ACP horizontally to coordinate with peer agents. The protocols do not overlap. They compose.
Use MCP when:
An agent needs to read from or write to an external system — database, API, sensor, hardware interface, file system, ERP, MES, SCADA. The connection is from one intelligent agent to one non-intelligent system. You need the same tool accessible from multiple AI frameworks or agents. You want to eliminate N times M integration complexity at the tool layer. You are building for an air-gapped or security-constrained industrial environment where stdio transport is required.
Use ACP when:
Two or more AI agents need to coordinate, delegate, or share results. The connection is between two intelligent systems that both reason and decide. You need stateful multi-turn coordination that cannot complete in a single message. You need cross-framework agent interoperability — a LangChain agent coordinating with a CrewAI agent without custom integration. You are building cross-company workflows where agents from different organizations need to collaborate securely. You need production-grade observability of agent-to-agent interactions with OpenTelemetry instrumentation out of the box.
Use both when:
You are building any serious multi-agent industrial AI system. MCP handles tool connectivity at every agent's leaf level. ACP handles coordination at the system level above. This is not an either-or choice. It is the correct layered architecture for any production multi-agent deployment.
MCP connects agents to tools and data.
ACP connects agents to each other.
Together they form the communication stack for next-generation AI systems.
In industrial terms:
MCP is the wiring between the brain and the sensors.
ACP is the communication between the brains.
A factory that installs sensors without connecting the machines to each other has data. A factory that connects machines to each other without sensing the physical world has conversation.
MCP plus ACP together gives you both. That is the factory that thinks.