AI agents for manufacturing operations: How they work and where they fit on the plant floor

Most manufacturing plants already have ways to detect problems. A sensor drifts out of range, an alarm fires, a deviation lands on a dashboard. What happens next is usually manual. Someone has to notice, open the right system, decide what to do, and enter the hold, work order, or schedule change by hand. That delay between detection and action is where downtime, scrap, and missed shipments accumulate.
AI agents for manufacturing operations are built to compress that delay. This article covers what AI agents for manufacturing operations are, why they're showing up on the plant floor now, the workflows they run, the architecture behind them, and the requirements for reliable deployment.
Key takeaways
- AI agents for manufacturing operations can read live plant data, decide on a scoped response, and write the hold, work order, or schedule change into a connected system without a person stitching the steps together.
- AI agents work above the control layer, querying batch records, quality specs, maintenance history, and inventory in the same decision, then picking from a configured set of responses.
- Reliability depends on three layers: a governed data layer with consistent definitions, an action layer with least-privilege permissions enforced outside the prompt, and an audit layer with record-level logging.
What are AI agents for manufacturing operations?
AI agents for manufacturing operations are software agents that perceive live operational data, reason over it, and take scoped actions in plant systems. The autonomy is instructed: a builder sets the agent's goal, the data it may read, and the actions it may run, and the agent carries that goal forward on its own.
The scope crosses systems. A quality agent might read sensor data from a programmable logic controller (PLC), cross-reference specifications in the manufacturing execution system (MES), write a corrective action to the enterprise resource planning (ERP) system, and notify the supply chain system about alternative materials, all inside one workflow.
A basic threshold alarm on a PLC is a much narrower instrument. Under ISA-18.2, basic alarm logic is a setpoint plus on-delay, off-delay, or deadband, with no additional logic attached. It fires when one sensor value crosses a fixed threshold. The standard explicitly assigns detection and response to a human operator. More sophisticated alarm management schemes exist, but they still operate within the control layer and hand the response to a person.
3 differences between AI agents for manufacturing operations and basic threshold alarms
- Scope of data. A basic threshold alarm evaluates one signal against one threshold. An AI agent, by contrast, queries batch records, quality specifications, maintenance history, and inventory positions in the same read, and correlates them before deciding.
- Response logic. A threshold alarm has one output: fire or don't fire. An AI agent picks from a configured set of responses (holding a batch, opening a work order, adjusting a schedule, or escalating to an engineer) based on what the combined data shows.
- Adaptation to context. Every trip of a threshold alarm plays out the same way. An AI agent evaluates what the previous step returned and adjusts the next step, handling conditions the original ruleset didn't anticipate.
The two instruments do different jobs. Threshold alarms stay at the control layer where safety-critical logic belongs. AI agents work across the business systems the control layer doesn't reach.
2 main reasons AI agents are showing up on the manufacturing floor
Most plants already run two categories of systems that flag problems: exception reports and rule-based automation. Both stop short of closing the loop, and AI agents finish the work each leaves unfinished.
1. Exception reports stop at detection
A dashboard or exception report tells someone a deviation happened. It doesn't place the hold, open the work order, or adjust the schedule. That work waits on a person to see the alert, open the right system, and make the change.
On a busy shift with hundreds of alarms, the wait itself becomes the failure mode, because operator capacity to respond to sustained alarm volumes is finite and floods obscure the alerts that matter.
An AI agent runs the full path from detection to a written action in a connected system, so the response doesn't depend on someone being available to see the report.
2. Rule-based automation can't reason across data sources
A fixed rule responds only to the condition its author predicted. A time-interval maintenance rule triggers a service alert on schedule whether or not the machine needs service, because it can't check condition data, parts inventory, or the production schedule before acting.
A single-variable threshold misses multivariate signatures, because a process can sit inside spec on every individual sensor channel while temperature, pressure, and vibration together signal an impending failure.
An AI agent queries across those sources in the same decision, so its action reflects the system's full state rather than one channel.
3 primary use cases for AI agents in manufacturing operations
The clearest test of an AI agent is whether it completes a multi-step workflow from a sensed condition to a written action end to end. Three workflows meet that bar today.
1. Quality holds and deviation response
A run of containers starts showing a faint surface mark. A legacy system flags each unit and piles up rejects until someone notices. An AI agent links the mark to a small rise in line speed after a changeover, places a hold on the affected batch in the MES, tells the operator what to adjust, and writes the reasoning back for later review.
Advanced manufacturing sites have documented versions of this quality-hold workflow. Pharma sees strong economics because deviation investigations require significant analyst time and documentation, though the size of the improvement varies by site and by the maturity of the underlying data. In most public case studies, a human still reviews the disposition before releasing a batch.
2. Predictive maintenance work orders
A vibration sensor flags an anomaly on a bearing. An AI agent pulls the asset's maintenance history, checks parts availability in the ERP, finds the lowest-impact window in the production schedule, and opens a work order in the computerized maintenance management system (CMMS) with a technician brief. Without that last step, the prediction lives on a dashboard as one more alert competing for a technician's attention. Closing the loop turns predictions into tracked maintenance actions and avoided downtime.
3. Schedule and inventory adjustments
Scheduling agents build live operational constraints (dock capacity, carrier limits, and current inventory positions) into planning logic at the start, so they check feasibility before making commitments. For example, inventory agents can adjust reorder points and transfer plans across large SKU catalogs and distribution centers as demand and supply shift.
How AI agents work in manufacturing operations
An AI agent for manufacturing sits above the control layer, reads signals that have already landed in the warehouse, and writes decisions back into systems already wired to the plant. The workflow runs in four steps.
The signal moves from the sensor into the warehouse
A sensor or PLC generates the raw signal at the lower levels of the ISA-95 stack. An edge gateway at the boundary between operational technology and IT reads industrial protocols such as OPC UA and Modbus, then publishes contextualized data northbound over MQTT. In a secure design, the edge device initiates the connection outbound, so inbound traffic never reaches the control network. The data then streams into a cloud data warehouse through a streaming or staged medallion architecture.
The agent reads the signal alongside related context
Inside the warehouse, a temperature deviation stops being an isolated number. It sits next to the batch record, the quality specification, the asset's maintenance history, and the product's inventory position. A vibration spike ties to a specific production batch and a specific maintenance schedule. The agent queries this combination live and reasons over it: is the deviation within tolerance for this product, has this asset drifted this way before, is there material on hand to rerun the batch if a hold sticks?
The agent decides on a scoped action
The agent chooses from the set of actions the builder allowed (hold, work order, schedule change, notification, or escalation) and picks the one that fits the data it just read. If the action's impact is high, the agent stops and asks a person to approve before writing.
The agent writes the action into a connected plant system
The write goes into a system already connected to the floor: a work order in the CMMS, a hold status or schedule adjustment in the MES, a purchase requisition in the ERP. A person or an existing plant system carries out the physical step. Safety-critical control logic stays in the PLC.
3 core requirements for AI agents to work reliably in manufacturing operations
Most agent projects fail because of weaknesses in data integration, permissions, and operational infrastructure. Industry surveys point to data quality, integration, and skills gaps as the most commonly cited reasons manufacturing AI deployments fail to reach production. The three requirements below separate an agent that runs in a demo from one that runs on a plant.
A data layer that gives the agent scoped access to live production data
An agent that reasons over stale or fragmented data will reach the wrong conclusion at speed. Reliable deployment requires a governed warehouse where production signals, quality records, maintenance history, and inventory positions share consistent definitions, so the agent's read of a batch means the same thing across every table it touches. Enforce row-level and column-level security at the warehouse rather than reimplementing it in the agent layer, so the agent inherits the same access controls a human user would.
An action layer that enforces least-privilege permissions
Treat agents as first-class identities with scoped permissions and an explicit allowlist of actions, enforced at the infrastructure layer rather than in the prompt. Staged autonomy is the practical rollout: start read-only, add human approval before writes, then grant conditional autonomy only where the impact of a wrong action is low and reversible. Human-in-the-loop, where the agent recommends and a person approves, remains the default for actions that are hard to reverse, such as releasing a held batch or canceling a production run.
An audit layer that captures every action at the record level
Regulated manufacturing can't use an agent whose writes can't be traced. FDA 21 CFR Part 11 requires secure, computer-generated, time-stamped audit trails for any action that creates, modifies, or deletes an electronic record, stored so changes never obscure prior data.
The EU AI Act's Article 12, in force August 2026, extends the same principle to high-risk AI systems, requiring automatic event logging so actions can be traced back. In practice, that means record-level logging of every write. Each entry preserves the pre-change value, the post-change value, the user or agent identity, and the timestamp.
How Sigma supports AI agents for manufacturing operations
Sigma is the runtime for AI Apps and agents on governed warehouse data. It sits between the cloud data warehouse (CDW) and the AI tools that use that data, turning those artifacts into applications and agents that inherit the company's existing governance. For manufacturing, Sigma brings the data, action, and audit layers into a governed surface that plants can combine with the controls already enforced in their CDW, MES, ERP, and CMMS systems.
Sigma Agents built on live warehouse data
A Sigma Agent is a customized agentic workflow configured within a workbook context. A builder configures three things:
- Instructions: a plain-English prompt that defines the agent's role and behavior.
- Data access: the tables and columns the agent can read, inherited from the workbook's existing security model and warehouse row-level security.
- Actions: the Sigma Actions the agent can run, including writeback to Input Tables, notifications, REST API calls to external systems, webhook triggers, and stored procedure execution.
Because Sigma runs live queries against the warehouse, an agent correlates operational technology signals with MES and ERP data in the warehouse the plant's analytics already run on. Sigma supports Databricks, Snowflake, BigQuery, Amazon Redshift, and other cloud data warehouses, so the agent uses whichever warehouse the plant already stores its production data in.
Sigma Agents also support three interaction modes: conversational, human-in-the-loop, and autonomous (including on a schedule). That range maps directly to the staged autonomy rollout manufacturing deployments need.
Sigma Actions as the scoped, permissioned action set
The actions an agent can take are the same Sigma Actions a builder configures in a workbook, and they're governed the same way. Sigma Agents inherit five layers of control:
- Warehouse governance from the cloud data warehouse.
- Sigma data model governance.
- Roles and permissions defined in Sigma. The agent inherits the running user's permissions.
- Workbook-level grants. No workbook access means no agent access.
- In-agent scoping. The builder defines what data the agent can see and which tables it can write to.
For a quality-hold or work-order workflow, that means the builder can allow an agent to write a hold row and open a work order request while blocking it from touching production schedules or vendor master data. The permissions can't be overridden from inside the prompt.
Input Tables for record-level writeback and audit
Input Tables provide native writeback, letting users edit data in the workbook UI and INSERT or UPDATE records directly in the warehouse. When a Sigma Agent is configured to write through Input Tables, it captures changes in an audit trail that records the original value, new value, user or agent identity, and timestamp.
When a Sigma Agent is configured to use REST API calls, webhook triggers, or stored procedure execution instead, the write lands in the destination system (MES, ERP, or CMMS) under that system's own controls, and the audit record follows that system's logging model.
Build AI agents for manufacturing operations with Sigma
Detection is the easy part of manufacturing operations. The value shows up when the hold, work order, or schedule change gets written into the connected system end to end. Warehouse governance, Sigma roles, workbook grants, and agent-level scoping stack together, so IT keeps visibility and control while plant teams get speed.
Try Sigma free or get a demo to see how a Sigma Agent can go from a sensor deviation to a work order on your own warehouse data.


