AI agents in manufacturing: decide before the schedule changes

A substitute component can be in stock and still be the wrong part to use. Availability answers one question; engineering suitability and quality release answer others.

That distinction gives AI agents in manufacturing a useful, bounded job. They can assemble the evidence for a decision without inheriting authority to change the production plan.

Consider a hypothetical component delay. Purchasing has a supplier notice, planning has scheduled work, and service has customer commitments. Each record tells part of the story.

The useful connection is between those facts and the people authorized to act on them. A faster recommendation helps only when you can tell what supports it.

TLDR

• Verify the component, revision, and affected work before preparing a production-change proposal.
• Keep engineering suitability, quality release, scheduling authority, and customer communication as distinct decisions.
• Start with reviewed information access and a narrow recommendation workflow, not assumed machine-control permissions.

What are AI agents in manufacturing?

AI agents in manufacturing are software systems that use information and tools to assist with manufacturing work. Their configured tasks may include gathering records, identifying an exception, preparing a recommendation, or performing an authorized operation. What they can actually do depends on their integrations, access rights, operating rules, and task boundaries.

The category includes different kinds of work. A production recommendation, a service update, and equipment control don’t have the same consequences or approval requirements.

This example focuses on manufacturing exception management: preparing a decision when the expected process no longer matches the available evidence. It does not assume autonomous control of equipment.

A late part creates three different decisions

A supplier’s delay notice should trigger a review of sourcing, production impact, and customer commitments. It should not automatically rewrite all three.

First, purchasing must establish what the notice actually means. A revised shipment estimate may concern one purchase order, one part revision, or a partial quantity.

Next, planning must determine which work depends on that material. A part number appearing in a production record does not, by itself, establish the current impact.

Finally, the service or account owner needs to check whether a customer commitment changes. An internal planning estimate is not automatically an approved delivery promise.

An agent can prepare these connections where its permitted tools and data support them. Your operating design must still say which person accepts each conclusion.

Confirm the component, revision, and affected work

Keep the first question narrow: which material is late, and where is that material required?

Match the supplier reference against an approved purchasing record. Check the part identifier, quantity, revision where applicable, notice time, and whether a later update supersedes it.

Then establish the relationship to scheduled work. The relevant planning record may sit in an enterprise resource planning system, a manufacturing execution system, or another approved view.

ERP coordinates business resources and transactions, while MES tracks production execution. Infor’s MES overview describes its execution role and relationship with ERP, but your installation determines the actual source.

An agent should preserve an uncertain match rather than turn it into an affected-production claim. A missing revision or ambiguous identifier is evidence for a hold, not a reason to guess.

Separate production impact from customer commitments

You may have enough evidence to identify an affected production order before you know the customer consequence. Keep those conclusions separate in the proposal.

For example, planning might have unused capacity elsewhere, while the customer order has a different promised date. Neither fact should be inferred from the supplier’s delay alone.

This is where AI knowledge management supports the workflow: people need permitted relationships between records, not just a collection of search results.

The same principle appears in existing industry coverage. IBM’s manufacturing explainer discusses a delayed-component scenario and coordinated scheduling responses.

The decision still needs evidence specific to your operation. An industry example does not establish that your systems contain the necessary relationships or expose an approved interface.

Which record can support the proposed change?

Use an owner-approved source for each decision, and preserve the version or timestamp that supports the proposal. Do not nominate one system as universal truth.

A purchasing record may establish what was ordered. Engineering records may establish applicability. Quality records may show whether the available material is released for the intended use.

Product lifecycle management, or PLM, can hold engineering information and changes. It is not necessarily where a supplier’s delay notification originates.

Your source map should reflect the actual installation. Copying a generic ERP–MES–PLM diagram can conceal the very ambiguity you want the agent to expose.

Build the exception’s source-and-owner map

Start with a table that a plant reviewer can challenge. The sources and controls below are illustrative, not a mandatory manufacturing architecture.

Every row requires approved access and appropriate handling, including rows that only read information.

In short: each record supports a particular decision; connecting records does not transfer the owners’ authority.

Define the map’s boundaries before automating it. For instance, can the agent retrieve the underlying quality record, or only an approved status view?

Both can be valid designs. They provide different evidence, so the proposal must say which one it used.

Missing or conflicting evidence changes the route

A recent retrieval does not make an old source current. Record the source’s effective time separately from the time your agent obtained it.

Suppose purchasing shows an alternate part as available, but the engineering view still references the original revision. That disagreement should change the recommendation.

The agent can identify the conflicting records and route the question. It should not silently choose the more convenient record or merge incompatible values into one confident answer.

General agent data readiness practices help with identity, access, and freshness. Keep this manufacturing review focused on the consequence: which owner must resolve the disputed part or release status?

A substitute part needs more than an availability check

A substitution proposal needs evidence of applicability and release, not just stock. Your engineering and quality owners determine the necessary checks under the organization’s procedures.

In the hypothetical case, an alternate component is available. Its engineering applicability remains uncertain, and a quality record may restrict its use.

That is enough to prepare a review packet. It is not enough to authorize substitution.

Engineering suitability and quality release are different checks

Engineering may need to establish whether the candidate fits the intended design and approved revision. Quality may need to establish whether the material meets release conditions.

One decision doesn’t imply the other. An applicable component can still be under a quality hold, and released material may still be inappropriate for the requested configuration.

Manufacturing AI agents should keep these findings separate in the proposal. Show which requirement each source supports and which question remains open.

A reviewer should not have to reverse-engineer the recommendation from a fluent paragraph. Give them the proposed part, relevant references, unresolved assumptions, and the decision being requested.

In their manufacturing roadmap, Patricia Henderson and coauthors describe engineers and planners reviewing proposed instructions and schedules. These are illustrative capabilities, not measured outcomes from this hypothetical workflow.

The useful lesson is the placement of the decision. The agent prepares work for the responsible role rather than treating a generated proposal as released instructions.

Compare substitution, resequencing, and a hold on the proposal

Give the reviewer alternatives with different evidence needs. Do not force every exception toward an automatic substitution.

In short: an unresolved proposal can be a useful result when it prevents an unsupported commitment.

Holding the recommendation does not mean stopping a production line. State exactly what is paused: the agent’s proposed change, not an unrelated physical process.

Approval should attach to a specific proposal. Record the source versions, intended operation, reviewer, and conditions that require another check.

If the component revision changes after approval, the old approval may no longer apply. Return the affected decision to its owner instead of treating approval as a permanent permission.

That is a practical boundary for agentic AI manufacturing workflows: preserve the relationship between evidence, decision, and authorized execution.

Keep the pilot outside machine control

Start this pilot with a reviewed information path and a recommendation task. Equipment-control changes remain outside its scope.

That is a deliberate boundary, not a claim that no agent can ever interact with equipment. Broader authority would need a separate engineering and safety assessment.

The NIST Guide to OT Security, Revision 3, published in 2023, addresses operational technology’s performance, reliability, and safety requirements. It remains the current final edition, though NIST has opened an initial public draft of Revision 4 for comment. Treat it as foundational guidance, not an agent-specific approval rule.

Operational technology monitors or controls physical processes. Its constraints make the IT/OT boundary a design question, not just another integration checkbox.

Read access still needs a reviewed path

Decide which records and fields the agent may read, through which interface, at what rate, and for what purpose. Name the owner of that access path.

A read-only operation can expose restricted information. It can also cross a sensitive network boundary or create load that the system owner needs to assess.

NIST’s OT guidance warns that active discovery can add network traffic and affect devices, unlike passive monitoring. That warning does not prove every read-only API call disrupts a plant.

It does establish why you should assess the actual path rather than assume that “no writes” means “no operating risk.”

Use approved business or planning views where available and suitable. Do not give an agent unrestricted plant-system credentials because a demonstration needs another data source.

Specify retention and disclosure rules too. A permitted internal quality record does not automatically belong in a customer-facing update.

For test containment, follow the agent sandboxing design. A favorable evaluation score is evidence about a run, not a boundary on what the next run could access.

Recheck the proposal before a permitted action

A later pilot phase might allow a bounded business-system update. Define that operation separately from the read-and-recommend phase.

Confirm the current identity, resource permission, proposal, and required approval at execution. Human review does not supply a technical privilege that the acting identity lacks.

Also define what completion looks like. A planning record might update successfully while a notification fails. Retrying every step could repeat an effect that already occurred.

Inspect the actual state before retrying. Assign an owner for reconciliation and another for customer communication where responsibilities differ.

Stopping further agent activity does not undo an earlier update. Recovery needs its own supported operation and appropriate authorization.

Test the decision packet before widening access

A useful pilot must show what happens when the evidence is wrong, missing, or outside scope. Test those conditions before adding more systems.

Use a wrong component revision, an outdated schedule, an unauthorized record, and a conflicting quality status. Include a proposal whose source changes after approval.

Record whether access was attempted, denied, or completed. A blocked request demonstrates something different from a disclosure, even when both reveal a problem in agent behavior.

Measure the packet’s evidence completeness, unsupported commitments, reviewer effort, and unresolved exceptions. Define the measurement window and denominator before comparing versions.

Do not promise a universal improvement. A workflow that reliably prepares evidence for a human may be the right endpoint.

Deloitte’s roadmap recommends focused trials that examine operational value, employee adoption, and compatibility with existing processes. Technical feasibility alone does not settle the operating decision.

Your build-versus-buy decision should account for who maintains these sources, tests, and controls. The connection is only part of the work you are accepting.

The review should establish what the proposed workflow may read, recommend, and change. Keep these questions tied to its actual operating boundary.

Choose one exception that your plant and business teams already need to resolve. Map the evidence, the disputed decision, and the owner who can approve it.

AI agents in manufacturing earn a wider role when that decision becomes easier to inspect. Connecting every machine can wait.