Factories are shifting toward smaller lot sizes with high product customization, requiring frequent re-programming of flexible and reconfigurable automation systems. LLM-based agents can be deployed in two complementary roles: Offline, they generate deterministic production sequences, reducing programming effort; online, they operate live machines and handle unforeseen runtime faults that static programs cannot anticipate. We propose a solution in which each factory module is paired with a dedicated LLM-based agent and an MCP tool server that exposes the module's skills via OPC UA method calls, with agents coordinating over MQTT and grounded by real-time updates of the factory state. We compare three agent architectures (orchestrator, peer-to-peer, and monolithic) across nine production challenges of increasing complexity in a simulation of a physical six-module hexagonal factory, including silent hardware fault detection. The monolithic and peer-to-peer architectures both achieve the highest mean solve rate (93%), while the orchestrator uniquely resolves a silent conveyor-belt fault in all ten runs by autonomously rerouting plates around the blocked segment. All architectures exhibit emergent fault-diagnosis behavior without any explicit failure-handling logic, establishing standardized MCP tooling, MQTT-based inter-agent communication, and real-time state injection as a viable and reproducible foundation for LLM-programmed smart manufacturing.
Figures & tables
Fig. 1: For each factory module, OPC UA method calls expose the module’s skills, which can be invoked by the module’s corresponding LLM-agent over MCP tools. The agents communicate over MQTT.
Fig. 2: Overview of the three agent architectures.
Fig. 3: Example product featuring five wooden blocks of different shapes on a plate, placed at 0 ° or 180 ° rotation.
TABLE I: Factory modules and their corresponding OPC UA methods.
Fig. 4: Real-time dashboard of the factory simulation. The six outside modules dock onto the hexagonal conveyor belt backbone in the middle. The ToolAvailabilityManager dynamically enables each module’s operation tools based on the factory’s state. As shown in the screenshot, the only permitted operations are loading the plate into the recycling module, moving the plate, or placing an additional plate onto the conveyor belt.
#
Opt
Orchestrator
Peer-to-Peer
Monolithic
SR (%)
Calls
Time (s)
Tok. (k)
SR (%)
Calls
Time (s)
Tok. (k)
SR (%)
Calls
Time (s)
Tok. (k)
1
18
100
18
71±10
44±3
100
18–25
196±93
98±38
100
18–24
94±46
117±49
2
18
100
18
70±8
44±2
100
18–24
192±60
96±24
100
18–24
77±36
100±40
3
20
100
20
83±4
53±0
100
20–28
153±61
76±22
100
20–24
72±30
102±31
4
21
100
21–32
164±53
103±34
100
22–26
291±76
105±18
100
21
48±3
78±5
5
41
100
41
141±6
137±1
100
41–70
468±377
262±150
100
41–61
160±70
306±137
TABLE II: Evaluation results of the agent architectures across 9 production challenges (mean over 10 runs). Opt = optimal tool calls; Calls = Tool calls on solved runs (min–max across runs). Bottom row: mean ± std across the nine challenge means. Tool call ranges are omitted from the summary row as min-–max ranges are not comparable across challenges with different Opt values.
Variant
SR (%)
Time (s)
Tokens (k)
Monolithic
93%
163 ± 111 s
312 ± 294 k
Monolithic (no injection)
88%
128 ± 72 s
264 ± 203 k
TABLE III: Ablation: effect of state injection on the monolithic agent (mean over 10 runs, across all challenges). SR = Solve Rate.
Fig. 5: Comparison of mean total token consumption for successful runs across the nine production challenges of the peer-to-peer and orchestrator architecture. Tokens are stacked per agent.