A Large Language Model-based Multi-Agent Manufacturing System for Intelligent Shopfloors

TL;DR

Flexible factories that make many small batches of different parts constantly have to decide, in real time, which machine should process the next workpiece. The classic fix — a fixed heuristic rule (“shortest processing time,” “least busy machine”) — reacts fast but is dumb: one rule can’t be right for every shopfloor situation. The other classic fix, deep reinforcement learning (DRL), reasons well but needs a custom simulator and a training run per shopfloor, and its performance degrades as the number of machines grows. This paper swaps the decision-maker for a Large Language Model, wired into a multi-agent bidding protocol: every machine is an “agent” with five small modules, machines bid for work in natural language, and an LLM reads all the bids plus the heuristic rules’ own recommendations and decides. Nothing is trained; the whole “policy” is a markdown-formatted prompt. Tested on a real physical shopfloor (lathes, mills, AGVs, robots) against five classic dispatching rules across five LLM engines, the LLM-based system produced the lowest and most consistent makespan (total completion time) in nearly every combination — and a follow-up ablation shows most of that win evaporates if you don’t hand the LLM the heuristic rules’ answers as reference knowledge, which is the paper’s most important caveat.

Problem & Motivation

Picture a shopfloor making custom parts in small batches — a warehouse, a couple of lathes, a milling machine, an engraving machine, a robot arm, and an AGV shuttling parts between them. Every time a part finishes one operation, something has to decide which machine does the next operation. That decision has to happen over and over, for every part, in real time, because orders keep changing (a rush order lands, a machine breaks, buffers fill up).

Three approaches exist before this paper, and each has a specific, concrete failure mode:

1. Metaheuristic scheduling (genetic algorithms, tabu search) solves the static version of this problem — plan the whole schedule once, in advance — very precisely. But it’s an iterative optimizer: replanning after every disturbance means re-running an expensive search, which doesn’t scale to a shopfloor that changes by the minute.
2. Heuristic dispatching rules (FIFO, shortest processing time, least-busy-machine) are instant — no computation, just a lookup — which is why real multi-agent manufacturing systems use them today. But a single fixed rule is a hammer: SPT is great when jobs are short and different, terrible when it starves a machine of long jobs it should be running. No one rule is right across all shopfloor conditions, and swapping rules requires an engineer to notice the mismatch and change code.
3. Deep reinforcement learning replaces the rule with a learned policy that can, in principle, read the whole state and pick well. But DRL for a shopfloor needs (a) a simulator of that specific shopfloor to train against, (b) a training run before it can be deployed, and (c) because multi-agent DRL on a shopfloor is a Partially Observable Markov Decision Process (each agent only sees its own local slice of the floor), training is unstable. Transfer learning helps reuse across shopfloors somewhat, but you still can’t drop a DRL scheduler onto a brand-new shopfloor and have it work on day one — and its accuracy degrades as the number of machines/resources grows because the state-action space explodes.

The paper’s framing: the shopfloor doesn’t need a faster search or a pre-trained policy — it needs a decision-maker with judgment that can be deployed with zero training and zero simulator, the same day it’s plugged in. LLMs, prompted rather than trained, are the candidate.

What’s New (Core Contribution)

• LLM-as-negotiator, not LLM-as-chatbot-glue. Before: multi-agent manufacturing systems negotiate machine selection with a single, hard-coded heuristic rule baked into the agent’s decision logic. Now: the decision logic is a system prompt. The rule is text, so changing the optimization objective or adding a new constraint is an edit to a markdown document, not a code change or a retrain.
• A five-module agent architecture that cleanly separates “talk” from “think” from “act.” Before: prior LLM-agent-for-manufacturing work (robotics control, RT-H, LLM-Planner) puts an LLM in the loop for a single robot’s task planning. Now: this paper defines a reusable per-machine agent template — Machine Server Module (MSM), Bid Inviter Module (BIM), Bidder Module (BM), Thinking Module (TM), Decision Module (DM) — where negotiation (BIM/BM), reasoning (TM), and decision extraction (DM) are three distinct LLM-adjacent responsibilities, each independently swappable.
• Splitting “reason” (TM) from “decide” (DM) for reliability. Before: one LLM call is asked to both analyze the tradeoffs and emit a machine-selectable, parseable answer — and doing both in one shot is exactly where LLMs get unreliable (they wander, hedge, or bury the answer in prose). Now: one LLM call (TM) is allowed to reason at length with Chain-of-Thought; a second, narrowly-scoped LLM call (DM) does nothing but extract the final integer from that reasoning. This is a deliberate reliability trick, not a performance one — and it’s the kind of pattern you’ve probably reinvented yourself in agent pipelines without naming it.
• Grounding the LLM in the heuristics it’s replacing, not asking it to invent scheduling knowledge from scratch. Before: nothing — DRL learns its own policy from reward, metaheuristics compute their own solution. Now: the TM’s prompt includes the literal outputs of classic dispatching rules (SPT, WINQ) as “Knowledge” alongside the raw bidding data, so the LLM’s job is closer to “arbitrate between these expert opinions given context” than “invent scheduling theory.” The paper’s own ablation (Hunyuan with vs. without these reference answers) shows this is doing most of the work — more on that in Results.
• Deployed and measured on a real physical shopfloor, not a simulator. The system runs against actual Siemens/FANUC CNC controllers via vendor SDKs, actual AGVs, and actual RFID-tracked parts, with 49,437 real LLM API invocations logged. This is unusually concrete for an LLM-agent-in-manufacturing paper — most of the neighboring literature (see Built on Prior Work) is simulation-only.

How It Works (Technically)

The agent, per machine. Every physical resource on the floor (a lathe, a mill, an AGV, the warehouse) gets one software agent living on an Industrial PC (IPC) next to the machine. That agent is not a monolith — it’s five modules split across three layers:

Architecture & data flow

flowchart TD
  subgraph Physical["Physical resource layer"]
    MSM["Machine Server Module (MSM)<br/>PLC signals, sensors, vendor SDK"]
  end
  subgraph Negotiation["Negotiation layer"]
    BIM["Bid Inviter Module (BIM)<br/>runs the auction"]
    BM["Bidder Module (BM)<br/>one per other machine"]
  end
  subgraph Decision["Decision Engine layer"]
    TM["Thinking Module (TM)<br/>LLM: reason over the bids"]
    DM["Decision Module (DM)<br/>LLM: extract the final number"]
  end
  LLMAPI[("External LLM APIs<br/>(GPT / Claude / GLM / Hunyuan / Gemini ...)")]

  MSM -- "1. decision time\n(event trigger)" --> BIM
  BIM -- "2-3. invite bidders" --> BM
  BM -- "4-5. bidding document\n(state, buffer, utilization...)" --> BIM
  BIM -- "6-7. question document" --> TM
  TM <-- "reasoning call" --> LLMAPI
  TM -- "8-9. suggestion (analysis + pick)" --> DM
  DM <-- "extraction call" --> LLMAPI
  DM -- "10-11. decision (machine #)" --> BIM
  BIM -- "12. decision trigger" --> MSM

Step through one negotiation round: BIM invites bidders, each BM reports its machine's real-time state, the question document goes to TM/DM, and a winner is picked. Click "Step" to advance; this mirrors Figure 2/3 of the paper.

Trace one real negotiation (the paper’s own worked example, Figures 3–5).

1. Event trigger. Machine 0’s MSM notices its current operation just finished and the workpiece needs more processing. It fires its BIM.

2. Invite bidders. BIM checks which other machines can do the next required operation (a robot can’t do CNC turning, so it’s filtered out before the auction even starts) and sends each an invitation.

3. Bidding documents come back. Each BM asks its own MSM for real, current numbers and writes a small natural-language document:

   “Machine: 3: The state of my machine is <busy>, and I still need <4> time steps to finish this order. The length of my buffer is <4>. My history utilization is <0.45>. My average completion rate of operation is <0.5>…”

   Every value in angle brackets is fetched live from the MSM; the sentence template is fixed. This is the paper’s whole approach to giving an LLM structured shopfloor telemetry without a custom parser — it’s just a fill-in-the-blank sentence.

4. BIM assembles the question document — shopfloor-wide numbers (average utilization, variance of utilization) + the job’s remaining operations + every bidding document it received — and hands it to TM.

5. TM reasons (Chain-of-Thought). TM’s system prompt is a markdown document with five fixed sections: Character (“You’re an AI-powered Operation Research Scheduler…”), Objective (“Reduce the makespan…”), Knowledge (the literal text output of the SPT and WINQ heuristic rules, computed conventionally and injected as extra context — not just described in the abstract, but their concrete recommendation for this exact decision), Answers (format: “an integer corresponding to the bidding document number”), and Constraints (“only accept an index that appeared in the bidding documents”). The prompt appends “Let’s think step by step” (Chain-of-Thought) so the model reasons through tradeoffs in prose before committing, e.g.:

   “Based on the SMPT rule, the job should be sent to Machine 2 because it has the shortest processing time… However, considering load balancing… I would choose Machine 1 to balance workload in anticipation of future jobs. Machine: 1”

6. DM extracts the answer. TM’s paragraph above is not directly usable — a downstream system can’t regex “Machine: 1” reliably out of open-ended prose it hasn’t seen the shape of. DM’s entire system prompt is: “You’ll get a paragraph from another model thinking about how to choose and its answer. Extract the machine’s selection number and get it back to me. If only a number is provided, you can only answer this number.” This is a second, narrower LLM call whose only job is formatting/extraction — cheap insurance against TM’s free-form output breaking a machine parser.

7. Decision → dispatch. DM’s number goes to BIM, BIM tells the winning machine’s MSM, and the workpiece physically moves.

Reliability plumbing (worth calling out because it’s the unglamorous 20% that makes this deployable):

• Multi-LLM failover. The Decision Engine layer treats LLM APIs like any other flaky network dependency: if one fails or times out, the system retries against a different LLM provider after a delay. Of 49,437 total invocations across the physical-shopfloor experiments, only 11 errored (0.03%), and the paper says most were transient network failures the system auto-retried past.
• Ambiguity → human escalation. If DM can’t extract a clean, in-range answer, the system doesn’t guess — it requests human input and logs the failure case for later prompt tuning. This is a pragmatic fallback that a lot of “fully autonomous agent” papers skip mentioning.
• MSM as a guard rail, not just a driver. MSM re-validates the decision it receives before acting on it and can re-request a corrected output — a cheap, deterministic check that catches the LLM assigning a physically infeasible machine.

Demystifying the “math”

There’s no learned model or loss function here — the only real “computation” worth translating is the two metrics the paper reports:

• Makespan — the wall-clock time from the first workpiece starting to the last workpiece finishing. It’s the paper’s single headline metric: lower is a shopfloor that got through the same work faster. It implicitly captures rework too, because a failed operation gets re-queued and extends the finish time of whatever depends on it.
• Sample standard deviation of makespan across 5 repeated runs — the paper’s stability metric. A method can have a good average makespan but be unreliable run-to-run (see Random in the results); the paper treats low variance as almost as important as low mean, because a shopfloor manager needs to trust the number, not just hope for it.
• P90/P95/P99 latency — for the decision-response-time table, “P95 = 2.59s” means 95% of the 100 sampled requests to that LLM API came back in ≤2.59 seconds. This is a standard tail-latency read: the maximum (12.62s for the reasoning model GLM-Z1-Flash) tells you the worst case a shopfloor might have to tolerate mid-negotiation, which matters because the whole floor is effectively paused waiting on that one decision.

There’s no equation for “how the LLM picks a machine” — that’s the point. The optimization logic that used to be a formula (e.g., argmin(processing_time) for SPT) is now a paragraph of natural language the model is asked to weigh against the injected heuristic answers.

The algorithm, simplified

# One negotiation round, from event trigger to dispatch.
# llm(system_prompt, user_prompt) -> str   is the only "model call" primitive.

def negotiate(machine, shopfloor, heuristic_rules):
    # 1. Who CAN do the next step? (capability filter, before any LLM is involved)
    candidates = [m for m in shopfloor.machines if m.can_process(machine.next_op)]

    # 2-5. Invite bids: each candidate reports its own real-time state as a
    # natural-language "bidding document" (values come straight from its MSM).
    bids = []
    for m in candidates:
        state = m.msm.read_state()  # busy/idle, buffer length, history utilization, ...
        bids.append(format_bidding_document(machine_id=m.id, **state))

    # 6. Fold in domain knowledge the model doesn't have to invent:
    # run the classic heuristic rules and hand their literal answers over too.
    reference_answers = {
        "SPT": heuristic_rules.shortest_processing_time(candidates, machine),
        "WINQ": heuristic_rules.least_workload(candidates),
    }
    question_document = build_question_document(
        shopfloor_stats=shopfloor.utilization_stats(),
        job_info=machine.remaining_ops(),
        bids=bids,
        knowledge=reference_answers,          # this is the ablation's "with answer" condition
    )

    # 7-9. TM: reason at length (Chain-of-Thought), don't force a clean format yet.
    tm_system_prompt = TM_TEMPLATE.format(
        character="AI-powered Operation Research Scheduler",
        objective="Reduce the makespan as much as possible.",
        knowledge=reference_answers,
        answer_format="an integer index from the bidding documents",
    )
    suggestion = llm(tm_system_prompt, question_document + "\nLet's think step by step.")

    # 10. DM: a SEPARATE, narrow call whose only job is extraction, not judgment.
    dm_system_prompt = ("Extract the machine's selection number from this paragraph. "
                         "If only a number is provided, answer only that number.")
    decision = llm(dm_system_prompt, suggestion)

    # 11-12. Validate before acting: MSM re-checks feasibility, escalates on ambiguity.
    if not is_valid_index(decision, candidates):
        return escalate_to_human(question_document, suggestion, decision)
    return candidates[int(decision)]

The two-call split (TM then DM) is the core trick worth remembering: let one call think messily, force a second, narrowly-scoped call to clean it up. It generalizes to any agent pipeline where you need both open-ended reasoning and a strict output contract.

Built on Prior Work

Results & Evidence

Setup. A real intelligent-manufacturing lab in Wuxi, China: a raw-material warehouse (treated as a zero-processing-time “machine” and the entry point for all workpieces), AGVs, lathes, milling machines, an engraving machine, and a robot, each wired to its own IPC-based agent via vendor SDKs (Siemens/FANUC CNC). Five order batches (150 workpieces at the largest, including a deliberately injected “urgent order” to test disturbance handling) were run five times each per method to get a mean ± standard deviation.

Headline numbers (Table 4, makespan in seconds, mean ± sample stdev, combined with FIFO/FILO/SPT for picking which waiting workpiece to process):

Table 4's actual makespan numbers (FIFO column), mean with error bars at ±1 sample stdev. Notice Hunyuan's tight bar next to Random's wide one — low variance is as much the story here as low mean.

What holds up:

• LLM–Hunyuan wins or ties-for-best in every column, and its variance is among the lowest — it’s both fast and consistent, which the paper argues matters as much as the mean (Random has a competitive mean in one column but the worst variance of any method, meaning you can’t trust any single run of it).
• A reasoning-capable model (GLM-Z1-Flash) clearly beats a same-family non-reasoning model (GLM-4-Flash), confirming the Chain-of-Thought design choice earns its keep.
• Reasoning capability saturates fast. GLM-Z1-Flash’s response time is roughly 5x Hunyuan’s (Table 3: P95 of 12.62s vs. ~1.2s) for a makespan result that’s statistically indistinguishable from Hunyuan’s. The paper’s read: “once basic reasoning proficiency is achieved, performance variations become statistically insignificant” — i.e. don’t pay for a slower “deep thinking” model once a cheaper model already clears the bar.
• Error rate across the whole physical deployment was 0.03% (11 of 49,437 calls), mostly transient network errors auto-retried — a real operational reliability number, not a simulated one.

The single most important number in the paper, and the one most likely to get lost if you only skim the headline table:

• Hunyuan without the injected heuristic reference answers scores 990–1021s — worse than every heuristic baseline including Random. The entire win of “LLM–Hunyuan” over WINQ (which is already competitive) depends on handing the LLM the heuristics’ own outputs as context. Read charitably, this paper demonstrates an LLM is a good arbitrator/ensembler over existing heuristics, not that an LLM can independently out-schedule a well-tuned rule from a cold start. That’s a materially different (and more modest, but still useful) claim than “LLMs beat heuristics.”

What the evidence does not establish:

• No DRL baseline was actually run. The entire motivation section argues against DRL’s training/simulator cost, but Table 4 never puts a trained DRL scheduler on the same physical shopfloor for a head-to-head number — the comparison set is entirely heuristic rules plus LLM variants. The claim “better than DRL” is argued qualitatively (deployment cost), not shown empirically.
• One shopfloor, one lab. All physical results come from a single testbed with a specific, small mix of machine types (5-8 machines). Scalability claims (“DRL degrades as machines grow”) are asserted from the literature review, not measured for this system at larger scale.
• The heuristic-injection dependency is under-examined. The paper reports the ablation as a positive (“proves the value of reference answers”) without probing how brittle the LLM becomes on scenarios the injected heuristics handle poorly — which is exactly when you’d want the LLM to add value beyond the heuristics.
• Cost is never discussed. Two LLM calls (TM + DM) per negotiation, potentially several times per workpiece per operation, at production LLM API pricing, across a real factory’s decision volume — the paper reports latency but not $-per-decision or aggregate API spend, which matters a lot for a services pitch.

How You’d Use It

This maps almost directly onto orchestration patterns you already run, just applied to a scheduling/dispatch problem instead of a chat or research task:

• The TM/DM split is a reusable reliability pattern for your harness, not manufacturing-specific. Anywhere you need an agent to both reason and commit to a strictly-parseable action (a routing decision, a tool selection, a triage category), separate “reason freely with CoT” from “extract the committed answer” into two calls with two different, narrow system prompts. It’s cheap (one extra small call) and meaningfully reduces parse failures versus asking one call to do both.
• “Inject the incumbent system’s output as context” is a fast way to de-risk replacing a heuristic with an LLM. If you already run a rules engine, dispatcher, or scoring model somewhere in your own stack and want to make it smarter with an LLM, don’t rip the old system out — feed its output into the LLM’s prompt as grounding knowledge, the way this paper feeds SPT/WINQ answers into TM. The ablation here is the argument for why: an ungrounded LLM did worse than the rules it was meant to improve on.
• Bidding-document-as-structured-telemetry is a lightweight integration pattern for your automations. Rather than building a custom schema/parser for every resource type, each one just fills in a fixed natural-language template with live values. This is a fast path to wiring heterogeneous legacy systems (PLCs, SCADA points, whatever telemetry or status feed exists) into an LLM decision loop without a data-engineering project first.
• This generalizes to any scheduling/dispatch automation you already run, not just manufacturing. The concrete pattern is: real-time resource-assignment decisions (which machine, which worker, which vehicle, which queue) under changing conditions, where you currently rely on a brittle fixed rule and can’t justify a DRL training project. Job-shop scheduling, fleet/AGV routing, ticket routing, and warehouse pick-task assignment are all structurally the same problem: bidders describe their state, an LLM arbitrates against existing heuristics.
• Multi-provider failover for LLM-in-the-loop operations is worth building once and reusing. The paper’s “if one LLM API fails, retry against a different provider after a delay” pattern is exactly the kind of infrastructure worth building as shared plumbing in your harness, used by every agent project rather than rebuilt each time.

Build Your Own (Minimal Recipe)

You can prototype the whole thing against a simulated shopfloor (or a small physical demo cell) in a few days.

Components, in build order:

1. A shopfloor state model. Each “machine” is an object with: capability list (what operations it can do), current status (idle/busy), buffer/queue, and whatever telemetry you have. For a toy version this can just be a Python dict updated by a discrete-event simulation loop.
2. The bidding-document template. One f-string per machine that fills in its live state into the exact fixed-format sentence structure the paper uses. Resist the urge to make this a JSON blob for the LLM — natural-language sentences read more reliably by the LLM and are the paper’s actual finding.
3. The heuristic reference layer. Implement SPT and WINQ (both are one-liners: min(candidates, key=lambda m: m.remaining_time) and min(candidates, key=lambda m: len(m.buffer))). This is the part that made the difference in the paper’s ablation — don’t skip it to “let the LLM figure it out.”
4. TM + DM as two LLM calls with two system prompts, per the pseudocode above. Use any capable, fast (non-”deep-thinking”) model first — the paper’s own result says the extra latency of a reasoning model didn’t pay for itself.
5. The negotiation loop / event trigger. A simple discrete-event scheduler: when a machine finishes an operation and the workpiece has remaining operations, run one round of {invite bidders → build question doc → TM → DM → dispatch}. This is the run loop; nothing here needs to be fancy.
6. Validation + escalation. Reject an out-of-range or malformed DM answer, retry once, then fall back to a heuristic rule (don’t build the “call a human” path first — a heuristic fallback is a fine MVP substitute).

The 1–2 genuinely hard parts:

• Getting the reference-answer injection right. The paper’s win margin over “no reference answers” is enormous (583s vs. 990s+). Getting this wrong — feeding the LLM raw data without also feeding it the heuristics’ conclusions — is the single most likely way a toy version underperforms the very rules it’s meant to replace.
• Latency budgeting under load. In a real deployment, a negotiation round involves two sequential LLM calls (TM then DM) per decision, and decisions happen every time an operation finishes anywhere on the floor. At scale (many machines, short cycle times) this compounds into real wait time; the paper’s own latency table shows this can range from ~1s to ~13s per call depending on model choice — pick your model with the shopfloor’s actual decision cadence in mind, not just accuracy.

Reach for: any tool-calling-capable LLM API (the paper explicitly tested OpenAI, Claude, GLM, Hunyuan, Gemini, Qwen for prompt-output consistency), a discrete-event simulation library (simpy is the standard Python choice) to build the toy shopfloor before wiring real machines, and a retry/failover wrapper (LiteLLM or a hand-rolled multi-provider client) for the reliability pattern.

How to Improve It

1. Test whether the LLM adds value beyond the heuristics it’s grounded in, specifically on cases where the heuristics are known to fail. The ablation proves dependency on reference answers; it doesn’t show the LLM correctly overriding a bad heuristic recommendation in a documented scenario. Construct adversarial cases (e.g., a scenario engineered so SPT and WINQ actively disagree with the objective) and measure whether TM’s reasoning actually resolves them well.
2. Add a real DRL baseline on the same physical shopfloor. The paper’s central competitive claim is against DRL, but the experiments never include one. A same-hardware, same-orders comparison against even a modest DQN/PPO scheduler would make the “no training needed, comparable or better” claim empirical rather than argued.
3. Report cost per decision, not just latency. Two LLM calls per negotiation round, at real API pricing, across a shopfloor’s decision volume, is a straightforward number to compute and directly answers “is this cheaper than an engineer maintaining a heuristic, or than training a DRL model once.”
4. Push scale. Run the same system on a shopfloor with 3-5x the machines and measure whether negotiation latency (more bidders → longer bidding documents → longer question documents → slower/more expensive LLM calls) or decision quality degrades — this is exactly the axis the paper claims DRL fails on, and it’s untested here for the LLM approach too.
5. Explore batching or caching the negotiation. If many machines finish operations near-simultaneously, you’re currently running independent LLM negotiations serially/in parallel with no shared context — a single LLM call reasoning over several simultaneous decisions (a small combinatorial batch) might produce better global makespan than greedy one-at-a-time bidding, at lower total latency/cost.

Glossary

• FJSP (Flexible Job-shop Scheduling Problem) — the general problem of deciding which machine does which operation, and in what order, when several machines can each do several different operations.
• Makespan — the total time from the first job starting to the last job finishing; the paper’s primary performance metric (lower is better).
• Metaheuristic algorithm — a general-purpose optimization search (genetic algorithms, tabu search) used to find a good, not necessarily perfect, schedule; precise but slow to re-run.
• DRL (Deep Reinforcement Learning) — a trained neural policy that picks actions (here, machine assignments) to maximize a reward signal; needs a simulator and a training phase before deployment.
• POMDP (Partially Observable Markov Decision Process) — a decision problem where the agent doesn’t see the full state, only its own local view; makes multi-agent DRL training less stable because each agent is guessing about what other agents see.
• Heuristic dispatching rule — a fixed, hand-coded rule for picking a machine or job (e.g., “shortest processing time first”); fast but rigid.
• SPT / SMPT — Shortest (Machine) Processing Time: pick the machine/job with the smallest processing time for the pending operation.
• WINQ (Work In Queue) — pick the machine with the least work already waiting in its buffer, to balance load.
• FIFO / FILO — First In First Out / First In Last Out: rules for choosing which waiting workpiece to process next, independent of which machine handles it.
• Agent — in this paper, the software wrapper (its five modules) attached to one physical machine, responsible for that machine’s participation in negotiation and decision-making.
• MSM (Machine Server Module) — the module that talks directly to the physical machine (PLC/sensors/vendor SDK) and detects when a new decision is needed.
• BIM (Bid Inviter Module) — the module that runs one round of the bidding auction: invites other machines, collects their bids, builds the question document.
• BM (Bidder Module) — the module, on every other agent, that responds to an invitation with a natural-language bidding document describing its machine’s state.
• TM (Thinking Module) — the LLM call that reasons over the full auction (via Chain-of-Thought) and proposes a choice with justification.
• DM (Decision Module) — the second, narrower LLM call that extracts a clean, machine-usable answer from TM’s reasoning.
• Bidding document — the fixed-template, natural-language message one machine sends describing its real-time state (busy/idle, buffer length, utilization, etc.).
• Question document — the document BIM assembles from all bidding documents plus shopfloor-wide stats and job info; this is what actually gets sent to TM.
• Chain of Thought (CoT) — prompting a model to “think step by step” before answering, which tends to produce more reliable reasoning on multi-factor decisions.
• Reference answer / knowledge injection — feeding the literal output of a classic heuristic rule into the LLM’s prompt as extra context, rather than making the LLM compute that reasoning from scratch.
• Decision latency — the time from sending a request to an LLM API to receiving its response; measured here in P90/P95/P99 percentiles across 100 sampled requests.
• IPC (Industrial Personal Computer) — the on-floor computer running each machine’s agent software, next to the physical equipment.
• PLC (Programmable Logic Controller) — the industrial controller that runs a machine’s low-level automation logic and exposes signals the MSM reads.