LLM-Driven Multi-Agent Control for Skill-Based Smart Manufacturing

I. INTRODUCTION

• Silent hardware faults can report success without physical effect, so they cannot be enumerated in advance by deterministic schedulers.The introduction says LLM agents can reason over expected-versus-actual factory-state discrepancies and reroute production without pre-programmed failure handling.Source: §I · p. 1
• Prior approaches lacked the combined use of structured agent architectures, MCP-based modular tooling, and OPC UA as the standardized execution interface.The paper compares orchestrator, peer-to-peer, and monolithic architectures in a six-module factory simulation across nine production challenges.Source: §I · p. 1

A. Skill-Based Manufacturing and OPC UA

• Skill-based manufacturing organizes machine functionality into discrete, callable skills that abstract away internal implementation complexity.OPC UA methods provide the standardized, invocable interface for a module’s skills.Source: A. Skill-Based Manufacturing and OPC UA · pp. 1–2

B. LLM-based Agents and Model Context Protocol (MCP) Tools

• An LLM-based agent receives environmental context, selects tool actions, and iterates until it reaches a goal.MCP provides a structured client-server interface for invoking external functionality such as OPC UA methods.Source: B. LLM-based Agents and Model Context… · p. 2

III. RELATED WORK

• Existing approaches either lack standardized tool interfaces, structured inter-agent communication, or a connection between MQTT coordination and OPC UA actuation.The paper positions its combination of multi-agent architecture, MCP-based per-agent tool servers, OPC UA execution, and MQTT communication against these gaps.Source: §III · p. 2

IV. CONCEPT

• Each factory module’s skills are exposed as agent-callable tools, agents coordinate over publish/subscribe messaging, and current factory state is injected into their reasoning context.Figure 1 describes module skills exposed through OPC UA method calls and invoked by corresponding LLM agents over MCP tools, with agent communication over MQTT.Source: §IV · p. 2, Figure 1 · p. 2

A. Factory Module Agent Architecture

• MCP servers wrap each module’s OPC UA methods as tools while hiding endpoint addresses and method signatures from the agent.Updating or extending module functionality requires changing its MCP server, not the agent orchestration logic.Source: A. Factory Module Agent Architecture · p. 2

B. Multi-Agent Coordination via MQTT

• The orchestrator delegates from a global factory view, peer-to-peer agents communicate directly, and a monolithic agent controls all modules.The three patterns differ in coordination overhead, fault resilience, and reasoning scope.Source: B. Multi-Agent Coordination via MQTT · p. 2, Figure 2 · p. 3
• MQTT decouples agents through a broker, supports topic-based one-to-many routing, and lets new agents join without modifying existing ones.The prototype uses plain MQTT for simplicity and broad native support in edge environments.Source: B. Multi-Agent Coordination via MQTT · pp. 2–3

C. Real-Time State Injection

• The state tracker maintains plate locations, belt occupancy, block inventory, and inspection results, and supplies this snapshot to agents at each inference step.Skill-completion events arrive via MQTT; the structured context also permits aggressive trimming of conversation history.Source: C. Real-Time State Injection · p. 3
• A tool availability manager filters each agent’s tools to operations physically valid in the current simulation state.For example, inspection is unavailable until a plate has been loaded into the module.Source: C. Real-Time State Injection · p. 3

A. Factory Simulation

• The simulated factory models a hexagonal conveyor backbone with inner transit and outer docking belts serving six peripheral modules.Plates must be positioned at the correct outer belt segment before a module can load or unload them; module operations follow loading.Source: A. Factory Simulation · pp. 3–4

V. IMPLEMENTATION

• Mock OPC UA servers update the simulated factory state, and each change publishes an MQTT event that updates the internal state tracker.The live dashboard subscribes to those same events, while the simulation is decoupled from the agent architecture and can be replaced by an OPC UA component such as physical hardware or a higher-fidelity digital twin.Source: A. Factory Simulation · p. 4

• The three implementations are orchestrator, peer-to-peer, and monolithic architectures.The monolithic design gives one agent all factory tools, while the other designs distribute control across agents.Source: B. Agent Implementation · p. 4
• In the orchestrator design, a central agent coordinates module agents and controls the conveyor belt.Source: B. Agent Implementation · p. 4
• Peer-to-peer agents control the belt at their docked edges to move plates to adjacent modules.Source: B. Agent Implementation · p. 4

1) Orchestrator Architecture:

• The orchestrator coordinates six specialist agents, with routing logic and current factory state supplied in its prompt.Specialists use dedicated MCP servers for their module’s OPC UA methods and exchange requests and replies with the orchestrator over MQTT; a ToolAvailabilityManager publishes currently valid tools.Source: 1) Orchestrator Architecture · pp. 4–5

2) Peer-to-Peer Architecture:

• In peer-to-peer control, six module agents message permitted peers over MQTT and hand plates to downstream modules after processing.The plate module agent initiates production, and a per-agent lock serializes incoming messages.Source: 2) Peer-to-Peer Architecture · p. 5

3) Monolithic Architecture:

• The monolithic design gives one agent access to all module tools and encodes the full workflow, layout, and production orders in its prompt.It uses a larger history window and tool-call budget, removing outdated factory states to limit context growth.Source: 3) Monolithic Architecture · p. 5

• Nine increasingly complex challenges were run ten times each in the Python-based factory simulation.The reported means are across successful runs.Source: §VI · p. 5
• Gemma4:31B was run locally through Ollama using a 30.7B-parameter dense model with Q4 K M quantization on an Nvidia RTX 6000 Pro Blackwell Workstation GPU.The authors chose local inference to avoid datacenter-load variability and network latency as timing confounds.Source: §VI · p. 5
• Inference temperature was set to 0.3 to let agents explore different recovery strategies in repeated silent-fault runs.Source: §VI · p. 5

Challenges 1–2

• Challenge 1 verifies a single-module pipeline with five identical blocks, inspection, and AGV delivery; Challenge 2 requires mapping five block types to magazine IDs at one station.Source: A. Production Challenges · p. 5

Challenge 3

• Challenge 3 tests cross-module routing and 180° orientation handling for one block in the rotation module.Source: A. Production Challenges · p. 5

Challenge 4

• Challenge 4 adds an empty magazine and requires a refill request, operator confirmation, and resumed assembly.Source: A. Production Challenges · pp. 5–6

Challenge 5

• Challenge 5 tests recycling after inspection detects a defective block, followed by a successful second assembly attempt.Source: A. Production Challenges · p. 6

Challenge 6

• Challenge 6 runs two orders simultaneously, requiring interleaved transport and per-plate order tracking across modules.Source: A. Production Challenges · p. 6

Challenge 7

• Challenge 7 requires agents to infer repeated inspection failures and reroute assembly without an explicit fault signal.Source: A. Production Challenges · p. 6

Challenges 8–9

• Challenge 8 tests diagnosis of an assembly module that reports successful insertion without placing blocks, then rerouting to another module.Source: A. Production Challenges · p. 6
• Challenge 9 injects a silent fault on the clockwise edge 0-to-1 belt segment, requiring counter-clockwise rerouting.Source: A. Production Challenges · p. 6

• Solve rate measures the percentage of runs that successfully fulfill the production order.Source: B. Evaluation Metrics · p. 6
• Time measures wall-clock duration from the first agent action to successful product delivery.Source: B. Evaluation Metrics · p. 6
• Token consumption measures input and output tokens per run, while tool calls count the calls used to fulfill the order.Tokens are broken down per agent and serve as a measure of operational cost and context efficiency.Source: B. Evaluation Metrics · p. 6

• For Challenges 7–9, the optimal tool-call lower bound assumes prior knowledge of silent defects, so it is not a baseline available without that knowledge.Source: §VII · p. 6
• All architectures achieved 100% solve rate on baseline Challenges 1–5; solve rates on Challenge 6 were 90–100%.Source: §VII · p. 6
• 100% on Challenge 9 was unique to the orchestrator; peer-to-peer reached 50% and monolithic 40% on the silent conveyor-belt fault.The orchestrator identifies the blocked clockwise path and reroutes the plate counter-clockwise; the monolithic agent encounters retry loops and timeouts.Source: §VII · p. 6
• On silent assembly faults, peer-to-peer scored 90% and 100% on Challenges 7 and 8; monolithic switched modules in all ten Challenge 7 runs, while orchestrator scored 20% there.Source: §VII · p. 6
• 163 ± 111 s was the monolithic architecture’s overall execution time; peer-to-peer used the fewest tokens at 222±143 k, versus 312 ± 294 k for monolithic and 375 ± 600 k for orchestrator.Figure 5 splits token consumption by agent: usage is distributed evenly across peer agents but concentrated in the orchestrator’s backbone agent.Source: §VII · pp. 6–7, Figure 5 · p. 7
• 93% mean solve rate: monolithic and peer-to-peer tie for the highest overall result, though no architecture dominates across all metrics.Source: Table II · p. 7, §VII · p. 7
• 93% versus 88% overall solve rate with versus without factory-state injection; injected-state runs used 312 ± 294 k versus 264 ± 203 k tokens and 163 ± 111 s versus 128 ± 72 s.Without injection, solve rates fell from 100% to 90% on Challenges 7 and 8, and from 40% to 20% on Challenge 9.Source: §VII · p. 7, Table III · p. 7
• The orchestrator’s centralized design is a single point of failure, while peer-to-peer lacks global replanning for faults spanning agents.Shared memory or a global broadcast channel is proposed as future work for peer-to-peer coordination.Source: §VII · p. 7

VIII. CONCLUSION

• Each factory module is paired with an LLM agent and MCP tool server exposing its skills as OPC UA calls; three architectures were evaluated across nine increasingly complex challenges.The challenges include multi-module assembly, block rotation, human-in-the-loop, simultaneous multi-plate production, and silent defect detection.Source: §VIII · pp. 7–8
• 93% mean solve rate for monolithic and peer-to-peer; the orchestrator alone solved Challenge 9 at 100% by rerouting plates counter-clockwise around the blocked segment.The monolithic and peer-to-peer architectures achieved 40% and 50% on Challenge 9, respectively.Source: §VIII · p. 8
• Validation was exclusively in simulation; realistic network latency and bandwidth were not evaluated, and scalability to larger layouts and more complex module topologies remains open.Physical deployment may introduce variability such as sensor noise or communication latency.Source: §VIII · p. 8
• The paper presents what the authors identify as the first integration of MCP tool servers with OPC UA in a multi-agent LLM framework for factory automation.Source: §VIII · p. 8