Key takeaways
- A manufacturing multi-agent system should separate specialist roles, orchestration, evidence retrieval, policy enforcement, execution, and human approval rather than create one unrestricted factory chatbot.
- ISA-95 boundaries, OPC UA semantics and security, and native MES, CMMS, QMS, and ERP workflows provide the integration context that agents must respect.
- Autonomy should be tiered from observe and recommend to bounded draft or transaction actions; open-ended LLM control of PLCs, DCSs, or safety systems is not a default deployment pattern.
- A safe pilot starts read-only, measures evidence quality and policy compliance, preserves manual fallback, and expands only after site-specific evaluation.
Multi-agent AI is a coordination pattern, not a licence for autonomous control
Manufacturing teams already coordinate through people and systems with distinct responsibilities. A production planner reconciles demand and capacity. A maintenance coordinator works from asset condition and work-order history. A quality engineer investigates deviations. An operator decides what is safe and practical at the line. The information they need is distributed across ERP, MES, historians, CMMS/EAM, QMS, engineering records, and control systems.
A multi-agent AI system applies the same separation of responsibilities to software. Instead of one general assistant attempting to interpret every signal and take every action, a set of specialized agents gathers evidence, applies a bounded task capability, and hands its result to an orchestrator or workflow. The orchestrator manages the sequence, but it should not become an ungoverned super-user.
The value is not that software “runs the factory.” The value is that a governed system can connect a production exception to its evidence, route it to the right role, prepare a reviewable recommendation, and preserve the decision trail. In industrial settings, the central design question is therefore not *How autonomous can the agents be?* It is Which decisions may be automated at which layer, using what evidence, with what approval and fallback?
ISA-95 remains a useful frame for answering that question. The standard describes the interface between manufacturing operations and control functions and enterprise business functions. It identifies Level 3 as manufacturing operations management and Level 4 as business planning and logistics; its core purpose is robust, safe, and cost-effective information exchange across those boundaries. [1] An agent architecture should respect those boundaries rather than bypass them.
What makes a system “multi-agent” in a factory context?
A factory multi-agent system has specialized roles, constrained tools, a coordination mechanism, and explicit escalation paths. It does not need to be based on a large language model, and it should not treat every task as a free-form conversation. Some roles may be deterministic rules, optimization services, anomaly detectors, retrieval systems, or workflow engines. A language-capable agent is most useful where people need to ask questions, inspect evidence, summarize cases, or translate a policy into a structured work item.
| Role | Receives | Produces | Boundary that keeps it safe |
|---|---|---|---|
| Signal agent | Historian events, MES states, alarms, quality results | Normalized event with timestamp, asset/product context, confidence | Read-only access; never changes a setpoint or acknowledgement state |
| Context agent | Event plus approved source references | Relevant work order, batch record, SOP, prior case, revision status | Returns cited evidence; distinguishes current from stale or draft content |
| Planning agent | Evidence, operating constraints, available resources | Ranked options, required approvals, proposed owner and due time | Cannot create a binding schedule or release a batch on its own |
| Policy and safety guard | Proposed action, user identity, site/asset policy | Permit, deny, or escalate decision with reason | Enforces allowlists, separation of duty, and operating envelopes |
| Execution agent | Approved, structured instruction | API call or draft work order/change request | Uses a narrowly scoped service identity and idempotent transactions |
| Supervisor/orchestrator | Task state and outputs from the specialist roles | Next step, handoff, retry, timeout, or operator escalation | Has no direct path to PLC, DCS, SIS, or safety-instrumented functions |
| Human operator or engineer | Evidence, recommendation, risks, and proposed action | Approval, rejection, correction, or plant action | Retains authority for safety, control, quality release, and accountable decisions |
This separation prevents a common failure mode: a generic model receives an alarm, retrieves a plausible procedure, and treats a fluent narrative as authority to act. A safer design makes the information path and the action path different systems.
The architecture: two planes and one hard boundary
The most practical pattern separates a decision-support plane from the control plane.
The decision-support plane can read approved operational data through brokers, APIs, historian replicas, MES interfaces, CMMS records, QMS records, and governed document retrieval. It is where agents correlate evidence, generate a structured recommendation, create a draft, or route a case. The control plane remains the deterministic environment of PLCs, DCSs, safety systems, machine controls, and established supervisory functions.
Design rule: An AI agent may observe and recommend across the plant. It must not receive an implicit right to command the plant merely because it can read plant data.
NIST defines operational technology as programmable systems and devices that interact with the physical environment or manage devices that do. Its OT security guidance emphasizes the performance, reliability, and safety requirements that distinguish these environments. [4] This is why “connect the model directly to the factory network” is not an architecture. It is an uncontrolled coupling of a probabilistic system to a physical process.
A production-grade design normally contains the following layers.
| Layer | Responsibility | Key implementation question |
|---|---|---|
| Authoritative systems | MES, ERP, historian, CMMS/EAM, QMS, PLM, SCADA/DCS/PLC | Which system owns each fact and its lifecycle state? |
| Integration and context | Read-only connectors, event broker, semantic model, asset/product identity mapping | Can every event be tied to the right asset, order, batch, revision, and time window? |
| Specialist agents | Retrieval, anomaly explanation, constraint checking, scheduling proposal, work-order drafting | What tool and data scope does each role need—and no more? |
| Orchestration and policy | Task routing, tool allowlists, approval gates, timeout, escalation, audit | Which actions are advisory, pre-approved, approval-required, or prohibited? |
| Workflow execution | Draft creation and approved API transactions | Does the target system enforce identity, validation, and its native approval workflow? |
| OT and safety boundary | Deterministic control, safety logic, emergency procedures | Can the plant remain safe and operable if every agent is unavailable? |
OPC UA can be an important interoperability layer, but it does not remove the need for policy. Its security model addresses industrial deployment from enterprise management to direct process control and specifies objectives including authentication, authorization, confidentiality, integrity, auditability, and availability. [2] Its Companion Specifications provide standardized domain information models, which helps agents interpret machine and process data consistently rather than relying on ambiguous tag names. [3] The practical implication is that agents should consume a governed, semantically meaningful interface—not scrape screens, share passwords, or infer equipment identity from unstructured text.
Where multi-agent systems create useful coordination
The best initial use cases have a recurring handoff problem, a definable evidence set, and a low-risk write path. They are not “fully autonomous factory” projects.
1. Production exception coordination
When a line or cell falls behind plan, a signal agent can combine MES state, production counts, downtime classification, current order, changeover status, and material availability. A context agent retrieves the approved response procedure and any active quality hold. A planning agent then prepares alternatives: recover with an approved overtime window, resequence an eligible order, call maintenance, or escalate material risk. The coordinator routes a reviewable recommendation to the responsible planner or supervisor.
The agent should not modify an executable schedule merely because it found a capacity gap. A production schedule has commercial, material, labor, quality, and safety consequences. The valuable automation is evidence collection and structured escalation, with the scheduling system retaining its own authorization and approval rules.
2. Maintenance triage and work-order preparation
A condition-monitoring signal can trigger a maintenance workflow when a rule or established analytics threshold is met. The context agent assembles equipment history, recent alarms, open work orders, known failure modes, spare-parts availability, and approved maintenance instructions. The planning agent can propose inspection steps and required craft skills. An execution agent can create a *draft* CMMS work order when the policy guard permits it, while a maintenance planner reviews priority and scope.
This is a meaningful coordination improvement without claiming that the agent has diagnosed a machine or made a safety decision. Siemens’ May 2025 announcement describes an industrial-agent architecture in which an orchestrator deploys specialized agents across the value chain and users decide which tasks to delegate. Siemens also describes “up to 50%” productivity as an aspiration, not an independent benchmark or a universal manufacturing outcome. [7]
3. Quality-deviation investigation support
For a deviation, agents can assemble the lot or batch record, process conditions, inspection results, calibration status, material genealogy, change history, and comparable cases. An investigator receives a timeline with links to source systems and an explicit separation between observed facts, plausible hypotheses, and missing evidence. The system can draft an investigation package, but it must not close an NCR, approve a disposition, release product, or assert root cause without the organization’s quality workflow.
4. Shift handover and operational continuity
An agent can compile events from the outgoing shift into a structured handover: equipment condition, work-in-progress, active permits, quality holds, open actions, abnormalities, and named owners. A second agent can check that mandatory handover fields are complete and link each statement to its source. The incoming supervisor remains responsible for accepting the handover and determining the next operational action.
Autonomy should be tiered, explicit, and reversible
The term “autonomous” obscures more than it clarifies. A practical program assigns every agent capability to an autonomy tier.
| Tier | Example | Allowed agent behavior | Required control |
|---|---|---|---|
| 0 — Observe | Summarize downtime events | Read, classify, and cite data | Read-only identity, source references, logging |
| 1 — Recommend | Propose likely owners for a deviation | Generate options and rationale | Human review before action; uncertainty shown |
| 2 — Prepare | Draft a CMMS work order | Populate a draft in the target system | Native workflow retains approval and edit rights |
| 3 — Execute bounded transaction | Send an approved notification or create a pre-authorized low-risk ticket | Perform an allowlisted API action | Policy check, idempotency, audit trail, rollback/fallback |
| 4 — Closed-loop control | Change a process setpoint or safety state | Not a default multi-agent capability | Separate engineered control and safety case; not delegated to a general AI agent |
Treat Tier 4 as a different engineering domain. A plant may use advanced control, optimization, and deterministic automation with appropriate design assurance, but an LLM-style agent should not be given a direct, open-ended ability to alter a live process. If a proposed agentic workflow cannot fail safely, it is not ready for automation.
NIST’s AI RMF describes AI systems as operating with varying levels of autonomy and organizes risk-management activities into Govern, Map, Measure, and Manage. It identifies valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair systems as characteristics of trustworthy AI. [5] For an industrial multi-agent system, that translates into assigned owners, bounded use cases, measurable acceptance criteria, evidence retention, and a response plan when the agents disagree, time out, or retrieve insufficient information.
A coordination protocol is more important than an agent count
Adding agents without a protocol simply distributes confusion. Each handoff should carry structured information rather than an unbounded transcript.
A useful task envelope includes the task identifier, affected plant/site/asset/product/batch, event time range, requester identity, permitted tools, source references, confidence or evidence gaps, proposed action, approval state, expiry, and audit correlation ID. The orchestration layer should record who or what initiated the task, which sources were read, which policy allowed or denied the action, and the result returned by the target system.
This is also the point to prevent hidden prompt injection and tool misuse. Untrusted plant notes, emails, supplier documents, and web content can be evidence—but they must not become executable instructions for an agent. Tool access should come from a policy-controlled registry, not from text appearing in a document. A retrieval agent should quote and link source material; it should not let the source redefine its permissions.
The NIST Generative AI Profile identifies risks unique to or exacerbated by generative AI and provides suggested actions for governing, mapping, measuring, and managing them. It highlights governance, content provenance, pre-deployment testing, and incident disclosure as primary considerations. [6] In a factory setting, that supports a simple principle: the agent’s confidence is not evidence; traceable source material and verified workflow state are evidence.
Security and safety controls that cannot be optional
A multi-agent design connects data, identities, and workflows that are normally separated. Its security model must be designed before the first pilot.
| Control | Why it matters | Practical implementation |
|---|---|---|
| Network segmentation | Agent services must not create a broad route from enterprise IT to critical OT | Keep agent services outside the control zone; use approved gateways, brokers, DMZ patterns, and site-specific OT architecture |
| Least-privilege identities | An agent should not inherit the operator’s or administrator’s access | Give each agent a service identity with narrow read/write scopes and short-lived credentials where possible |
| Tool allowlists | General tool access converts a language interface into an uncontrolled automation surface | Register specific APIs, parameters, asset scopes, rate limits, and transaction types |
| Human approval and separation of duty | Some actions require independent accountability | Require appropriate approval for quality release, schedule commitments, work-order priority, engineering change, and control actions |
| Evidence and audit logs | Investigators need to reconstruct what happened | Log input references, agent and prompt version, model/tool version, policy outcome, user identity, target-system response, and timestamps |
| Fallback operation | An agent outage or wrong recommendation must not become a production outage | Preserve manual and native-system workflows; define timeouts, safe failure modes, and escalation owners |
NIST SP 800-82r3 advises organizations to secure OT while accounting for its unique performance, reliability, and safety requirements. [4] The specific topology and control selection must be designed with the plant’s OT, engineering, safety, and cybersecurity owners; it should not be copied wholesale from a generic IT deployment.
How to pilot without creating a black-box control system
Start with one decision, one site or line, and one accountable owner. Choose a workflow where manual coordination is visible and where wrong output can be caught before it affects a physical process.
Step 1: Define the decision and the “no-go” boundaries
Document the trigger, users, authoritative sources, allowable agent tools, prohibited actions, approvals, fallback, and acceptance criteria. State plainly what the pilot will not do: no setpoint changes, no safety interlock actions, no uncontrolled write-back, no quality release, and no uncontrolled ERP or MES commitments.
Step 2: Build a source and identity map
Map each fact to the system that owns it. Define how the system identifies assets, materials, lots, orders, and document revisions across integrations. Reproduce or enforce source-system permissions in the retrieval layer. An answer should show the document, record, timestamp, and lifecycle state behind every material recommendation.
Step 3: Test against representative cases before live use
Create a test set from historical, de-identified cases: normal operation, ambiguous alarms, missing data, conflicting records, stale procedures, permission failures, and policy-denied actions. Measure whether the correct evidence was retrieved, whether the recommendation was useful, whether prohibited tools remained unavailable, and whether the system escalated appropriately when evidence was weak.
Step 4: Launch read-only, then draft-only
Begin with observation and recommendation. Progress to creating drafts in the native target system only after the evaluation shows that citations, permissions, and routing are dependable. A draft is not a decision. Keep the target system’s approval workflow as the source of record.
Step 5: Operate it as a changing industrial system
Monitor data freshness, connector health, access failures, tool denials, timeouts, action completion, user corrections, and model/index/prompt changes. Re-run evaluation after a source schema change, procedure revision, model update, or expansion to a new plant. Assign an owner for the business workflow, the technical platform, the source data, and the risk controls.
The measures that matter
A persuasive demonstration is not sufficient for plant deployment. Measure the system against the workflow it is intended to improve.
| Dimension | Example measure | Failure signal |
|---|---|---|
| Evidence quality | Citation completeness; correct source/revision; retrieval recall on test cases | Recommendation relies on stale, unsupported, or inaccessible content |
| Workflow quality | Correct routing; time from trigger to prepared review package; human rework | Action goes to the wrong role or lacks required context |
| Safety and policy | Denied-action accuracy; approval compliance; prohibited-tool attempts | Agent proposes or attempts a forbidden control or quality action |
| Operational resilience | Timeout recovery; manual fallback success; connector freshness | Failure of a service blocks the existing work process |
| Human usability | Reviewer acceptance, correction rate, explanation usefulness | Engineers cannot determine why the agent made the recommendation |
Do not report a percentage improvement until the baseline, population, time period, and acceptance method are clear. Vendor announcements and pilot claims may be useful signals of technology direction, but they are not substitutes for site-specific measurement.
The realistic outcome
The most valuable multi-agent system in manufacturing is usually not a dramatic autonomous factory. It is a governed coordination layer that turns scattered signals into a reviewable, properly routed, policy-checked piece of work.
It respects ISA-95 operating boundaries, uses interoperable industrial context, keeps OT security and deterministic control intact, separates evidence from action, and makes the human decision owner visible. When those disciplines are in place, specialized agents can reduce the coordination burden around maintenance, quality, planning, and operations without asking the factory to trust a black box.
NeoBram helps industrial teams design these systems around their source-of-truth data, operating workflows, and security boundaries—starting with a bounded pilot that produces inspectable evidence before any automation is expanded.
