AI Agents vs Rule-Based Workflow Automation in Digitized Manufacturing Plants

TL;DR

• Use deterministic rules when you can state every condition, authorized action, owner, and escalation path in advance.

• Consider an agent when recurring exceptions require evidence from several systems and the agent can propose a bounded response. A machine outage that disrupts a schedule may fit, provided the data has enough context and a planner approves the change.

• Keep decisions with an authorized person when an action carries regulatory consequences or changes physical control. An agent may assemble held-lot evidence, but quality staff decide whether to release the lot.

• Use the selection matrix to screen candidate loops, then test an agent in shadow and assisted modes before granting narrow, reversible authority. This is an editorial engineering framework, not a standards requirement.

When should a plant use rules, an AI agent, or human approval?

Most connected plants already use rules to route alerts, update records, and escalate exceptions. For each operational loop, ask whether you can exhaustively state its conditions, authorized actions, and escalation path, then keep those rules current. When those conditions are explicit and stable, keep the existing workflow. If recurring exceptions require someone to interpret changing evidence across systems, an agent may help prepare a response.

An MES quantity mismatch with an approved tolerance is a good candidate for a rule. The MES can detect the discrepancy, notify the assigned owner, and escalate it if nobody resolves it within the agreed time. A machine outage presents a different problem when the response depends on current work in progress, delivery commitments, and staffing. An agent could assemble that evidence and propose a revised schedule, while a planner retains approval before any change enters the system of record.

Exception frequency alone does not decide who should act. Before giving an agent a role, check whether ERP and MES records describe the same order, equipment, and event accurately enough to support a decision. Missing or stale context may call for data repair rather than a new decision maker. Consequence also sets the boundary. An agent might gather evidence for a held lot, but an authorized quality owner should decide whether to release it.

When deterministic rules are the right tool

A deterministic rule fits a plant loop when you can state the triggering event, threshold, authorized action, and escalation path in advance. For example, if an MES completed quantity differs from the ERP posted receipt beyond an approved tolerance after the posting window closes, a rule can alert the designated inventory owner. If the mismatch remains unresolved, the same workflow can escalate it. The rule needs no judgment about what caused the discrepancy to perform those steps.

Keep that workflow in the existing systems when the MES and ERP records identify the discrepancy, the owner, and its status. The alert can retain the compared quantities, timestamps, and rule version so the owner can reconstruct why it fired. If a required posting has not arrived, the rule should wait or report missing data rather than treat an incomplete comparison as a confirmed mismatch.

An overview of the ISA 95 update discusses information exchanged between enterprise and manufacturing control functions. That distinction helps you keep record reconciliation in ERP and MES workflows, while SCADA alarms and equipment control remain in their established paths. An agent adds little when the conditions and permitted response are already explicit.

When can an AI agent improve a plant workflow?

An agent can help with recurring exceptions whose responses require changing, cross system evidence, provided you can define the proposals it is allowed to make. A machine outage illustrates the boundary. A rule can alert the planner when a machine stops. An agent could instead compare affected work in process, order due dates, alternate machine qualifications, and available staffing, then draft a revised schedule within those constraints. How AI scheduling builds a traceable recommendation examines those scheduling inputs in more detail.

The proposal depends on evidence that refers to the same orders, equipment, and time period across systems. An outage event from SCADA cannot support a useful schedule change if MES work-in-process records are stale or ERP identifies an alternate machine that is not qualified for the product. Shared identifiers and mappings must connect the SCADA event to the affected MES operation and ERP order. If the plant cannot reconcile those inputs or show when they were last updated, you should fix the data before granting the agent more authority. Frequent exceptions do not remove that requirement.

For the outage loop, you can give the agent read access to the relevant records and require it to record the evidence, constraints, and proposed changes for review. The proposal should exclude held lots and unqualified equipment, while a named planner approves any write to the ERP or MES schedule. Separate read and write permissions keep a useful recommendation from becoming an unauthorized change. Direct equipment commands stay outside this loop.

When the decision must stay with a person

A person should retain authority over held-lot disposition, even when an agent can assemble the evidence. A quality decision-maker may need to weigh test results, production history, and applicable release requirements before accepting or rejecting the lot. The agent can flag missing records and assemble a disposition proposal, but an authorized quality owner must approve the decision and control any change to the lot’s release status in the MES. Release can be difficult to reverse once material moves downstream, and the authorized quality owner remains accountable for the decision.

Direct PLC commands and safety-interlock changes belong under established OT control authority. An agent may identify a recurring equipment fault or draft a proposed control change for review. It should not write set points, bypass interlocks, or issue actuator commands. Control engineers must evaluate and approve any change through the plant’s existing procedures.

The permission to propose a plan does not grant permission to carry it out. You can give an agent read access to relevant records while reserving MES write access for an authorized person and keeping physical control outside the agent’s scope.

How do rules, agents, and human decisions compare?

Choose a mode by testing whether you can specify the loop’s conditions and authorized action, verify its evidence, and assign ownership of the outcome.

A machine outage can justify an agent drafting a revised schedule if ERP orders and MES work in process refer to the same jobs and current state. If those records use mismatched identifiers or lag the outage, the agent may produce a plausible schedule against the wrong constraints. You should reconcile the records before expanding the agent’s scope, and planner approval should remain separate from permission to write the schedule into the system of record.

A practical matrix for choosing the first loop to automate

Exclude safety controls, direct equipment changes, and product release decisions before comparing candidates for a first automation pilot. For each remaining loop, name the accountable owner, the system of record, the actions automation may take, and where unresolved cases go. A candidate without clear ownership cannot advance just because its exceptions occur frequently. The manufacturing AI agent pilot guide covers how to baseline and test a selected loop after this screening step.

Next, test whether the records contain enough shared context to support a decision. ERP demand, MES work in progress, and shop floor events must refer to the correct equipment, product, lot, process step, and time window. Map those identifiers across systems and check their timestamps before treating the records as evidence for a proposal. If records conflict or arrive too late, repair the data path before asking an agent to propose an action.

A pilot also needs accessible source evidence and an audit log that captures record versions, the proposed action, approval, and any final write. Restrict access to the candidate loop, and test how you will stop it and reverse or compensate for an incorrect write. The ratings below are illustrative and plant specific. Use them to compare candidates within your plant, not as externally validated benchmarks.

Compare exception counts against observations in your plant, not a universal threshold. A loop with frequent exceptions but incomplete evidence is a candidate for data repair or human review, not greater agent authority.

How should a plant test shadow, assisted, and bounded autonomy?

Shadow mode tests an agent without letting it change the plant’s workflow. For each machine outage in a predeclared sample, you can compare the agent’s proposed schedule with the planner’s recorded decision. Reviewers should check whether each proposal used current ERP demand, MES work in progress, and the right equipment constraints. They should also count missed exceptions, unsupported proposals, and the time each recommendation took. Agreement with the planner alone is insufficient if both decisions relied on stale data.

Assisted mode tests whether the recommendations hold up when a person must act on them. The agent proposes a revised sequence, but the planner approves, changes, or rejects it before any write to the system of record. The audit log should preserve the input records, proposal, approval, final write, and reasons for overrides. You can then compare proposed versus approved decisions, review downstream outcomes, and measure whether the handoff saves time without increasing corrections.

Bounded autonomy grants permission for a specific action, not a general right to make plant decisions. For example, an agent might reorder a maintenance review queue within approved limits, provided the queue does not itself authorize work or change equipment status. Before granting that permission, the plant needs a named owner, a narrow and reversible scope, tested recovery, monitoring, and a control that immediately revokes write access. Missing or stale evidence should stop the automated action and return the loop to its human owner. Leadership can withdraw permission for one loop without changing the authority granted to others.

Set advancement criteria for each loop before testing begins, using its observed error consequences and evidence requirements rather than a universal percentage. Treat shadow, assisted, and bounded autonomy as plant implementation stages rather than a schedule prescribed by NIST’s voluntary AI Risk Management Framework.

When does industrial ontology help an agent interpret plant data?

An agent needs shared operational context before it can use records from ERP, MES, and shop floor events in one decision. For example, a machine outage affects an order only if the agent can connect the affected equipment to the product and process step for that order. An industrial ontology gives those relationships consistent meanings across systems. The ISA-95 shop-floor decision example traces an ERP order, MES operation, and SCADA event through that contextualization step.

Shared mappings make the order, operation, and outage interpretable together, but they do not establish that the underlying records are current or complete. Humble consumes contextualized data as a decision layer. It does not build or replace the ontology, and missing or conflicting mappings should keep a proposed action out of the approval path.

Where Humble fits as the governed decision layer

Humble is positioned as a decision intelligence layer above existing ERP, MES, SCADA, and integration infrastructure, with those systems retaining their record and control responsibilities. For a machine outage, Humble could prepare a schedule proposal from available production events and planning constraints, subject to validating those inputs for the selected loop. The proposal should show the affected orders and the evidence behind the recommendation before a planner approves any change to the system of record. SCADA retains equipment control.

For a scheduling loop, Humble’s account of traceable AI scheduling recommendations offers a starting point for specifying the evidence a planner should review. A shadow test would then compare proposals with recorded planner decisions. In assisted mode, a planner reviews each proposal, and you track approvals, overrides, and decision time. Plant leadership should grant bounded autonomy only for narrow, reversible actions with a named owner, sufficient evidence, an audit record, tested recovery, and a way to withdraw permission. Held lot disposition and direct safety controls remain outside that authority.

Check whether Humble fits your plant loop

Choose one loop you are considering automating, such as rescheduling after a machine outage. Identify the evidence it needs, who approves a proposed change, and whether you can reverse the action. Then take the Humble fit test to assess whether that loop is a practical starting point.

Discuss a candidate loop with Humble

Bring a candidate loop to a call with Humble. On the call, review which ERP, MES, and shop floor records support the proposed action, who must approve it, and what the decision record must capture. You can use that review to decide whether the loop should remain assisted or qualify for bounded autonomy.

Stay Current on Manufacturing Decision Intelligence

For more on selecting operational loops and setting decision rights in connected plants, subscribe to the Humble newsletter.

FAQ

How can you tell whether a plant loop is ready for an agent?

An agent is a candidate when recurring exceptions require judgment across systems, the relevant records share reliable context, and you can define its permitted actions and a named decision owner.

What evidence does an agent need before acting?

An agent needs current source records, the constraints that apply to the decision, and a traceable link between that evidence and its proposed action. Missing or conflicting records should stop the action and trigger review.

Why does high exception volume not justify autonomy?

Frequent exceptions may expose stale data or mismatched records rather than a need for autonomous decisions. You should fix those inputs before allowing an agent to act on them.

What changes when a loop moves from assisted to bounded autonomy?

In assisted mode, a person approves each proposed action. In bounded autonomy, an agent may take narrowly defined, reversible actions without individual approval, while a named owner retains oversight and can revoke that permission.