Agentic AI is not the same AI that your organization may already use for predictive analytics or anomaly detection. Predictive tools receive a defined input, such as sensor readings or a batch record, and produce a defined output, such as an anomaly score or failure probability. An agentic AI system, referred to as the “agent” throughout this article, receives a goal, breaks it into steps, queries multiple systems and evaluates the results of each step before recommending or initiating the next action. For example, after an equipment failure, an agent may check maintenance history, verify spare parts availability, assess schedule impact and draft a work order package for human approval. Unlike a fixed rule-based expert system that follows predefined if/then logic, an agentic system can revise its plan when intermediate results change the situation, such as when a spare part is not available, a similar failure has occurred before or the current order is a higher priority.
Consider a familiar scenario: an unplanned equipment failure mid-run. A conventional monitoring system raises an alarm. An agent might query the maintenance history, check parts inventory, assess the downstream schedule impact and begin drafting a work order, all before a supervisor opens the notification. If the underlying data is reliable and well structured, that sequence of data lookups and recommended actions compresses response time. If it is inconsistent or incomplete, the same sequence produces a plausible-looking but incorrect result, such as recommending a repair path based on an outdated inventory record that is not actually executable, which may take longer to catch than a simple missed alarm.
This article is not an argument against agentic AI in manufacturing. It is an argument that many organizations are starting at the wrong end. They jump to asking “what can the AI do?” while bypassing two foundational prerequisites: first, what specific business outcome are we trying to improve, by how much and in which exact process? And second, what must our data environment support to make that specific outcome reliable? In early deployments, the struggle is rarely model capability; it is the realization that the data environment was never designed to serve the precision required by the business goal.
Defining agentic AI in industrial terms
This article proposes three operational tiers. Each carries a distinct risk profile, and the required data maturity rises with each tier.
[run-in-head] Advisory mode. The agent analyzes data and surfaces recommendations. There is no write access to operational systems. This is the appropriate starting posture for most deployments today.
- Human-in-the-loop mode. The agent proposes an action and routes it for human approval before execution. In this context, “human-in-the-loop” means a human approves each consequential operational action before it executes—it is not a reference to model training processes.
- Bounded autonomous mode. The agent acts without human approval before each action, but only inside a tightly constrained scope. Constraints such as scope, parameters, time limits and rollback triggers must be explicitly engineered.
Each tier requires a more mature data infrastructure than the tier preceding it. Human-in-the-loop workflows require stronger cross-system consistency, controlled write-back permissions, maintained approval records and defined rollback paths. Bounded autonomous applications require the highest confidence in data context, timeliness and access permissions. Organizations that pursue bounded autonomy before demonstrating that advisory-mode recommendations are consistently accurate, explainable, reviewed by operators and reliably useful are likely building on an unstable foundation. The autonomy tier should be determined by the reversibility of the proposed operational action, the safety consequence of an error and the regulatory traceability requirement — not by the perceived sophistication of the task.
Each tier in Figure 1 shows its autonomy level and data maturity requirement: Tier 1 (Advisory) requires a baseline data foundation; Tier 2 (Human-in-the-loop) requires cross-system consistency; and Tier 3 (Bounded autonomous) requires mature data infrastructure and governance.
Figure 1: Three operational tiers of agentic AI deployment in manufacturing.
Practical near-term use cases
A single unplanned equipment failure can create several different information needs simultaneously. Operators need alarm prioritization. Engineers need a root-cause timeline. Maintenance planners need a prepared work package. Quality teams may need deviation context. Schedulers need to understand the impact on the downstream schedule. These are different use cases, but they share the same dependency: the agent must be able to trust the data it retrieves.
- Alarm triage: In alarm triage, an agent reviews the alarm history, current process conditions, equipment state and prior process or quality deviation records. It ranks alarms by contextual severity and explains the reason for each ranking. The agent does not suppress alarms or hide them from the operator—all alarms remain visible. The agent only helps the operator decide what deserves attention first.
- Data required: The agent gathers the alarm history, real-time process values, equipment states and prior process or quality deviation records.
- Human touchpoint: The agent ranks alarms and explains the ranking; the operator decides which alarm to investigate and what response action to take.
- Root-cause investigation support: After an equipment failure or quality issue, engineers often spend more time collecting data than analyzing it: pulling historian trends, locating batch records and correlating timestamps across disconnected systems before any real diagnosis begins. An agent addresses this by querying the historian, production records and quality system simultaneously, assembling the results into a structured timeline with anomalies already flagged. The engineer receives a pre-built picture of the incident and can focus immediately on interpretation and corrective action.
- Data required: The agent assembles data from the historian time-series, production records, quality system entries and timestamped event logs.
- Human touchpoint: The engineer owns the final root-cause determination and corrective action decision. [run-in-head] Maintenance coordination. The gap between a condition monitoring alert and an executed work order is one of the most persistent inefficiencies in asset-intensive manufacturing. An agent operating in human-in-the-loop mode closes that gap by drafting the work order, retrieving the equipment history, checking parts availability and routing the completed package to the appropriate planner for approval. The alert becomes a prepared maintenance package rather than a notification waiting for manual follow-up.
- Data required: The agent creates a package containing condition monitoring outputs, asset master data, the maintenance history and parts inventory data.
- Human touchpoint: A planner or supervisor releases the work order; the agent does not release or execute the maintenance work order autonomously.
- Quality deviation handling: When a batch falls outside specification, the quality team must act quickly, but gathering the relevant specification, prior deviation history and production record from disconnected systems takes time that the quality team can rarely afford. An agent retrieves the specification, deviation history and production record from each system and assembles a structured disposition recommendation for the quality engineer to review. The agent prepares the evidence package and recommendation, but the quality engineer approves the final disposition.
- Data required: The agent retrieves quality management records, specification data, production history and prior non-conformance records and prepares a recommendation.
- Human touchpoint: The quality engineer approves the final disposition, particularly in regulated environments. [run-in-head] Schedule exception management. Unplanned downtime rarely affects just one work order. It cascades across the schedule, starving downstream operations and putting delivery commitments at risk. An agent identifies affected orders, compares resequencing options and shows the likely impact on throughput and lead time. The scheduler receives a structured starting point with options already modeled, while retaining full authority over which option to execute.
- Data required: The agent reviews the production schedule, equipment availability, order priority and downstream constraint data and recommends options.
- Human touchpoint: The scheduler approves all rescheduling actions.
Each use case shares a common dependency structure. If an agent’s recommended resolution fails, it is not due to the agent’s capabilities; rather, it is a result of inadequate data: missing context, inconsistent identifiers, unreliable timestamps, or inaccessible systems.
The minimum data foundation
Contextualized data, not just collected data. Raw time-series data is not sufficient. The agent needs to know that a given tag represents the inlet temperature of a specific heat exchanger, that its normal range is defined and that it is associated with a product family and shift pattern. This is the work of semantic modeling. A semantic model connects raw tags and records to their real-world meaning: asset, unit, product, batch, operating state, normal range and business context. Established frameworks such as ISA-95 (functional hierarchy from enterprise to field device), the CESMII Smart Manufacturing Profile (semantic data modeling for manufacturing) and ISO 15926 (plant lifecycle data integration) provide reference architectures, though the underlying data hygiene work must precede any framework adoption.
Consistent asset hierarchy and naming conventions. If the same pump appears under different identifiers across the historian, maintenance system and production records, an agent will either miss connections or produce incorrect linkages. ISA-95 functional hierarchy definitions, or a plant-specific equivalent applied consistently, are a prerequisite.
Reliable, timestamped and complete data. Agentic reasoning across a timeline is only trustworthy if the underlying event log is accurate and complete. In the equipment failure use case, an agent assembling a root-cause timeline from an incomplete historian record produces a confident-looking but incomplete picture — and the engineer reviewing it may not know what is missing.
Structured, authenticated interfaces. Agents require stable, authenticated access paths to each connected system, a far stronger foundation than file-based exchanges or manual data pulls. Two deployment topologies require specific evaluation: plants with air-gapped operational technology (OT) networks may require an on-premises agent or edge gateway in an OT DMZ (demilitarized zone), while cloud-hosted agents may be unsuitable for latency-sensitive production areas, such as a packaging line, robotic cell, coating station or machine section.
Identity, access governance and explainability. Every agent transaction must be attributed to a defined system identity, logged and auditable. Agents should operate under least-privilege authorization principles consistent with ISA/IEC 62443-style defense-in-depth, segmentation, least-privilege and auditability guidance. In regulated manufacturing environments (pharmaceuticals, food and beverage, and aerospace), the agent’s reasoning chain must be explainable, not merely logged. Traceability shows what the agent did. Explainability requires that a reviewer can also understand why those steps were appropriate, given the specific decision context — a meaningfully higher bar for most current LLM-based systems.
Figure 2: Data infrastructure prerequisites mapped against the five manufacturing use cases described in this article. Organizations should complete the Stage 1 readiness audit before selecting a pilot use case.
Where agentic AI should not act without safeguards
The use cases discussed here are bounded, support-oriented and reviewed by humans before consequential action is taken. However, human review alone is an insufficient safeguard for high-speed industrial processes. Therefore, the agent must be constrained by deterministic, safe operating envelopes — enforced by logic controllers or safety-instrumented systems — that the agent cannot override, regardless of its internal reasoning.
Adjacent areas such as process set-point changes, product disposition and production-order execution carry fundamentally different risk profiles. These must not be delegated to an agent without explicit safeguards, validated human signatures and rollback mechanisms in place.
Cybersecurity requires attention across two immediate threat vectors: falsified input data fed to the agent, and adversarial content embedded in data the agent retrieves. An agent with write access to operational systems is a meaningful attack surface — falsified process data fed to the agent can induce a chain of plausible-looking but incorrect actions before anyone detects the manipulation.
Agents that retrieve plant documents or external data are also vulnerable to prompt injection — adversarial content embedded in retrieved data that redirects agent behavior without triggering conventional security controls, a documented threat class for LLM-based systems requiring both input validation and behavioral monitoring.
Least-privilege access should be reviewed regularly, just like other access-control policies. It should not be set once at deployment and left unchanged. Agent performance should also be monitored over time because models calibrated on historical data can degrade as processes, materials, equipment or operating practices change.
A realistic adoption roadmap
Stage 1: Business alignment and data infrastructure audit. First, identify the specific process and measurable outcome to improve. Then assess whether the foundation prerequisites are in place across five dimensions: data contextualization coverage, asset hierarchy and naming consistency, event log completeness and timestamp reliability, interface availability and authentication, and identity, access, and explainability readiness. This is a data hygiene project, not an AI project, and it is the work most organizations underestimate.
Stage 2: Advisory-mode pilots. Define the success metrics. Select one or two use cases and deploy them in advisory mode only. Measure the recommendation accuracy and operator adoption rate; both matter for sustainable deployment. In this stage, the human validates the agent’s reasoning, and the agent learns from expert feedback to refine its alignment with operational reality.
Stage 3: Governance, cybersecurity and safety guardrails. Baseline governance should be defined before any pilot begins. It should include the agent’s scope, access rights, logging, human review and escalation paths, defined procedures specifying who is notified and what action is expected when the agent encounters a decision outside its authorized scope. As pilots run, these controls should be refined using actual performance data, operator feedback and cybersecurity review, including ISA/IEC 62443-aligned, least-privilege access and prompt injection controls.
Stage 4: Controlled autonomy expansion. Only after advisory-mode pilots have produced measurable results and governance infrastructure is in place, consider expanding to human-in-the-loop or bounded autonomous modes. Each expansion requires an explicit authorization decision. Continuously involve operators and engineers to review performance against the initial business key performance indicators (KPIs), treating the agent as a teammate rather than a replacement.
Technology deployment without parallel change management rarely sustains. Operators who distrust AI recommendations work around them; those who over-trust stop applying independent judgment. Structured introduction, including clear communication of the agent’s scope and feedback mechanisms for incorrect recommendations, is as important as technical deployment. For smaller operations without dedicated integration resources, start with a single data source, a single use case and advisory-only mode. The principles provided here apply at any scale; the scope should match data maturity, not ambition.
The questions worth asking before making any agentic AI investment are not simply “What can this do?” but “What outcome are we trying to improve? What does our data environment currently support?” and “What must we address before we ask a system to reason autonomously across it?” Data infrastructure work determines whether agentic AI delivers measurable business value or merely adds complexity, and it is work that the organization, not the technology vendor, must own and lead. If the data architecture is not fundamentally anchored to the specific business process you aim to improve, the agent will never possess the reliable foundation required to move from experimentation to autonomous value.
