Manufacturing Analytics With AI Agents: Cost and Compliance

Key takeaways

• The decision comes before the dashboard. The supplier in this guide had a predictive maintenance model that worked, and the pilot still failed, because nobody had been given the job of acting on it.
• Agents write to systems of record, never to PLCs. A work order, a schedule change, or a lot hold is fine. A setpoint or a safety loop isn't, and it stays with the controls engineers.
• The cleanest data usually goes first. At the supplier, that's quality holds on one machining line. The transfer press looks like the bigger prize, but it goes second.
• Integration labor is most of the bill. The AWS line is usually the smallest, and the supplier could pay for a good part of its first phase by consolidating two historians into one.
• Compliance shapes the design. Because one of the supplier's lines does defense work and its sister plant is in Germany, DFARS, NIS2, the works council, and the EU AI Act all come into it, and they decide where data lives and what gets logged.

We've been building data platforms and AI systems on AWS since 2008, mostly for operations where downtime is expensive and auditors ask hard questions. We wrote this for the COO, CIO, CTO, or VP of Operations who has already watched one pilot stall and needs the next one to make it to production.

Most plants we walk into have more data than anyone there has time to look at. The MES can say which lot ran on which line last Tuesday, and the historians go back years. Even so, someone still decides whether to slow a line, pull a spindle, or hold a batch based on experience and a spreadsheet that showed up before the 7 a.m. meeting.

It isn't for lack of AI. Rockwell Automation's 2026 State of Smart Manufacturing report found that a third of operations are already AI-augmented. What's missing is the return. In McKinsey's 2026 State of AI survey, only 37% of respondents attributed at least some EBIT impact to their use of AI, about the same as the year before. In the plants where we've seen a return, someone rebuilt one workflow around one decision, rather than adding another layer of reporting.

As a running example, we'll use a made-up but typical Tier 2 automotive supplier. It has a stamping and machining plant in Ohio, with nine lines on three shifts, and a smaller sister plant outside Stuttgart. The PLCs came from three different vendors over the years, and the two sites ended up on different historians. Its bottleneck is a 1,200-ton transfer press, and an hour of unplanned downtime there costs about $22,000 in lost output and overtime. One machining line, Line 4, makes brackets for a defense prime, so some of its drawings are controlled unclassified information (CUI).

The supplier has already tried this once. In 2024 it paid for a predictive maintenance pilot on the press, and the model was fine: it caught bearing wear on the main drive a few times a week. But no one had been told that acting on those alerts was their job, and within a month maintenance had muted them. We'll come back to that pilot more than once.

Why Does Manufacturing Analytics Stall Between the Shop Floor and the Decision?

In our experience it's rarely the technology. Somebody scoped the program as a data project, so it ends once the data's been collected and charted. Nobody ever said who acts on a signal, how fast, or with what authority. That's where the supplier's press pilot died.

Here's how that pilot ran into all five of the failure points we see most often.

Just getting data off the press took a custom connector. The press spoke Profinet and the older CNCs spoke Modbus, and one machine used a vendor format you needed a license to even open. Even then, the vibration readings showed up bare. There was no asset ID, part number, order, or shift attached, so nobody could say what job the press had been running when the bearing got hot. The scrap report that might have explained it came out the next morning. When the alert finally showed up on a dashboard, no one had been cleared to act on it. And the agent that could have turned it into a work order was pencilled in for a separate project, a year after the ML one.

The fixes are mostly unglamorous. We'd start by putting an OPC UA or MQTT edge layer in front of every machine. That feeds one asset model, which people often call a unified namespace, and each sensor stream gets joined to its MES and ERP records as it lands. Operational signals would be streamed, while planning data stays in batch. Each signal would get a named owner and a written limit on what that person can do about it. And we'd build the foundation, the models, and the agents in one engagement rather than three.

The last of the five hurts the most. By the time the third project starts, the data's gone stale and the models have drifted. It also keeps pilots stuck on one line. At the supplier, Ohio's tag for main-drive vibration on the press is P12_MainMtr_Vib_X, and Stuttgart's tag for the same signal is PR3.Hauptantrieb.Schwingung. A model trained in Ohio can't read Stuttgart's data until someone maps both to a shared asset model, and in most plants, that job doesn't belong to anyone.

That's why we treat manufacturing analytics as an operations program and not as a reporting project. For the supplier, IT/OT convergence would pay off the day a bore-diameter drift on Line 4 turned into a lot hold within minutes. Another chart of yesterday's downtime wouldn't move OEE, first-pass yield, or scrap rate.

What Is the Agentic Decision Layer in Manufacturing Analytics?

It's the layer where somebody, or something, finally acts on the analytics. In our builds that's an AI agent. Say the quality agent sees a bore diameter drifting on Line 4. Before doing anything, it looks up the tolerance, which lots the parts came from, and what's due to ship this week. Then it either places a hold or recommends one, depending on how much authority it's been given. None of this touches the machines. The agent works between your analytics and your systems of record (MES, CMMS, ERP, QMS), and it writes down each step, so a supervisor or an auditor can see later why it did what it did.

Most plants already have dashboards and a few predictive models. Here's how the decision layer compares, using the supplier's press as the example:

The last row is where agent programs usually go wrong. Plant leaders get nervous when nobody can say exactly what an agent is allowed to do, and they're right to. So we pin that down before anyone writes a prompt, and one rule has no exceptions: agents write to systems of record, never directly to control systems. The supplier's maintenance agent could open a CMMS work order, and its quality agent could put a lot on hold in the QMS. Neither one would ever get near a setpoint on the press. The safety loops stay deterministic, and they stay with the controls engineers.

Holding that line is what lets the agents move fast without putting anyone at risk. We wrote about the same idea in our renewable grid operator case study: *"Decisions used to lag the grid. Now they run with it. The agent reasons under uncertainty; the system around it does not."*

Inside that boundary, we sort decisions with two questions. How easy is it to undo, and how far does the damage spread if it's wrong? Resequencing jobs on one of the supplier's lines within a shift is easy to undo and stays local, so an agent could just do it and tell the supervisor after. Rerouting an order to Stuttgart is easy to undo too, but it touches two plants, so it would need one click from a planner. Scrapping a lot of brackets can't be undone, which means the agent would only recommend it and the quality manager would decide. Releasing regulated product would stay with people, and changing the press's die settings, being a PLC setpoint, wouldn't be on the matrix at all.

We write it up as a decision rights matrix during scoping, and it becomes part of the acceptance criteria for AI agents in production. A first draft usually looks something like this:

Going from the top left of the matrix to the bottom right, the decisions get harder to undo and reach further, so the agent's authority shrinks. It moves up a level only after its logged decisions have matched what the supervisors would have done, week after week.

What Does a Manufacturing Analytics Architecture on AWS Look Like, From Sensor to Agent?

There are five stages between the PLC and the decision, and each has a sensible default on AWS. You can swap any of them for something you already run well. Here's what each would do at the supplier, and what we'd build it on:

If you already run Snowflake or Databricks for enterprise analytics, there's no reason to rip it out. The industrial data platform should feed it.

If you're working from an older AWS reference architecture, two things have changed. In October 2025, AWS put the SiteWise Edge data processing pack and SiteWise Monitor into maintenance mode, closed to new customers, so we'd collect at the edge through MQTT-enabled gateways and build dashboards somewhere else. And since Amazon Lookout for Equipment was discontinued on October 7, 2026, the supplier's press model would be trained and hosted on SageMaker AI. (QuickSight, meanwhile, is now called Amazon Quick Sight.)

Three design choices decide whether this still works at your fifth plant. The first is a unified namespace: one asset model that every system subscribes to, instead of 40 point-to-point integrations. It's what would let the supplier's maintenance agent ask which presses ran hot last week, across Ohio and Stuttgart, without anyone rewriting a query. The second is keeping historians for operators and putting the analytical copy in Iceberg on S3, so the models, the dashboards, and the agents all read the same data. The third is running agents inside workflows rather than letting them roam. We use AWS Step Functions because every step, input, and approval gets recorded as it happens, and that record is usually what gets an agent past the quality team.

The foundation is where most of the budget and most of the risk sit, and it's where agent-native delivery makes the biggest difference. At the supplier, automated discovery would map the tags, schemas, and lineage at both sites in a few days, work that would otherwise take weeks of analyst time. That's the core of our approach to data platform modernization on AWS. It also means the agents can start on real data in the same engagement, without waiting for a second project.

In the figure, data moves down the stack, and actions go back only to systems of record. The governance controls on the right apply at every stage, starting at the edge.

Which AI Agents in Manufacturing Pay Back First?

The ones that pay back first tend to have three things going for them. The data's already being collected and it's clean, somebody specific owns the decision, and the KPI has a baseline your CFO already believes. Without all three, projects tend to drift into research.

Here's how we'd rank the usual candidates for the supplier:

We'd start the supplier where its data is cleanest, not where the payoff looks biggest. Predictive maintenance on the press gets all the attention, but the quality agent would likely pay back sooner: a hold can be released, the quality manager clearly owns it, and a bad lot of brackets gets more expensive every hour nobody flags it.

Line 4 already measures every bracket on a CMM. Say a bore diameter starts drifting toward its tolerance limit on a Tuesday night shift. The agent would put the affected lots on hold, trace which ones had already shipped and to which customer, and leave a draft root cause analysis in the quality manager's queue before the shift ends. The press would come second, and this time its alerts would turn into draft work orders in the CMMS for the maintenance planner to approve. That approval step is what the 2024 pilot never had.

After that, it gets cheaper. With the foundation and the decision layer in place, the second and third use cases cost a fraction of the first. One manufacturer we worked with got its data foundation, ML, and agents delivered together and moved its supply chain from reactive to anticipating in one engagement instead of three.

 

How Do You Keep Manufacturing Analytics Secure and Compliant in the US and EU?

We'd design the decision layer as a regulated system from day one. Bolting controls on after the pilot works is how agent programs end up shelved at the security review, and plant leaders have good reason to be careful.

The attack data explains the caution. IBM's 2026 X-Force report has manufacturing as the most-targeted sector for the fifth year in a row, at 27.7% of all incidents. Over at Dragos, which tracks OT, the count for 2025 was 3,300 industrial organizations hit by ransomware, and more than two-thirds of them were manufacturers. That doesn't mean the floor should stay offline. Connected with care, a plant can end up safer than before, because for once someone can see which systems talk to which.

The supplier would have to answer to at least six of the frameworks below, and its auditors and customers would each ask about them in their own way. Here's the map we design against, with the question you're likely to get and what we'd show:

For the supplier's US side, that means Line 4's drawings stay in AWS GovCloud (US), since DFARS 252.204-7012 only allows covered defense information in cloud that meets the FedRAMP Moderate baseline. That clause still stands, even with CMMC Phase 2 paused since July 2026. In Stuttgart, NIS2 covers the plant as a maker of vehicle parts, so its incident plan needs the 24-hour early warning. And because the shift handover agent would read operator notes, the works council there gets a say before it goes live.

The EU dates land differently for the supplier than for its press builder, which has the most to do. The Machinery Regulation applies from January 20, 2027, and since the Digital Omnibus on AI, Regulation (EU) 2026/1744, came into force this year, AI in a machine's safety functions falls under the AI Act from August 2, 2028, by way of that regulation. The supplier's own agents aren't safety components, so the high-risk rules, which start on December 2, 2027, for most other uses, probably don't reach them, though we'd write down why. The Cyber Resilience Act mostly lands on its equipment vendors, whose reporting duties started on September 11, 2026. And any press the supplier buys from now on should come with its data accessible by design, which the Data Act has required for new connected products since September 12, 2026.

Five controls go into every build by default. Here's how they'd look on the supplier's quality agent. Data would leave Line 4's control network through a one-way data diode or a DMZ broker, so nothing in the cloud could open a path back down to Purdue Levels 0 to 2. The agent would get its own identity, an IAM role with a short list of tools (read CMM results, place a QMS hold, draft a report), rather than a shared service account. Every decision it made would be recorded, with its inputs, the context it retrieved, a summary of its reasoning, the action, and who approved it, through AWS Step Functions and AWS CloudTrail. Stuttgart's data would stay in an EU Region and Line 4's drawings in GovCloud. And the agent's authority would only go up after its logged decisions had matched the quality manager's over a sample both sides agreed on beforehand.

None of this is legal advice, so check the scope with your counsel. In our experience, though, auditors and regulators relax a lot once every decision can be traced back to its source data.

What Does Manufacturing Analytics Cost, and How Do You Fund It?

Mostly integration labor and change management. The AWS bill for a plant like the supplier's is usually the smallest number in the budget. Where the money really goes is mapping tags, reconciling schemas, and proving the new system agrees with the old one.

Siemens has tried to put a price on what all this protects against. In its True Cost of Downtime 2024 report, it estimated that the world's 500 largest companies lose about $1.4 trillion a year to unplanned stoppages, roughly 11% of their revenue. For a large automotive plant, it put one hour at $2.3 million. We put the supplier's press at $22,000 an hour, so a single bad night, eight hours down, is about $176,000.

These are the drivers we price against:

How do you fund it without a new budget line? Usually the money's already there, tied up in things that don't return much: historian and BI licenses coming up for renewal, an on-prem warehouse nobody adds to anymore, middleware that needs paid hours to keep running, and analysts rebuilding the same weekly report. The supplier spends about $380,000 a year on its two historians and an aging reporting server, and both historian contracts come up for renewal within 18 months. If it kept one historian for operators and moved analytics onto the open data foundation, a good share of that would come free. That's how most plants end up funding AI from their existing budget, and it turns the decision layer from an R&D request into a capital allocation decision.

The commercial model matters as much as the architecture:

We contract on the third model. Our delivery commitment is blunt about the ship date in the statement of work: *"A single date, not a range and not a target quarter revisited at each steering committee."* The fee locks after scoping, and when a delay is ours, we pay for the extra work.

How Should You Roll Out Manufacturing Analytics Without Stopping the Line?

For the supplier, we'd start with Line 4, one decision, and one KPI: the bore-diameter hold and scrap rate. Nothing else gets touched until that works. Each phase ends with someone signing off, and the riskiest assumption, which here is whether the CMM data can be trusted at all, gets tested before anything is built at scale.

Phase 4, the parallel run, is what makes this safe in a plant that never stops. For a few weeks the agent only watches. Whatever it would have done gets logged next to what the supervisors actually did, and it gets more authority only once the two keep lining up. At the supplier, the quality agent would propose holds on Line 4 while the quality manager made the actual calls, and they'd go through every mismatch together on Friday afternoons.

It's the same five-phase sequence behind how we ship modernization to production, which has a median of 12 weeks to production across our engagements. About 60 to 70% of the engagement work runs on Aedeon, the agent platform we deliver with, which on a job like the supplier's means discovery, mapping, and test generation. The judgment calls (the architecture, who gets to decide what, and the cutover) stay with our forward-deployed engineers.

Is your plant ready? Seven quick checks:

• If you could speed up one decision tomorrow, which would it be, and whose is it?
• Do you know what that KPI looks like today, in downtime hours, scrap rate, or OEE?
• Can you get at one line's PLC or historian data over OPC UA, MQTT, or a gateway you already own?
• Have your OT and IT teams agreed on a network path from the floor to the cloud?
• Do you know which rules apply to you: Part 11, DFARS, NIS2, the EU AI Act?
• Is there a license or system you'd retire if this works?
• Will a plant leader back the parallel run, not just the kickoff?

If you can say yes to five or more, you're ready for a scoped engagement. If not, phase 1 can close the gaps. The supplier would have scored five. Its IT and OT teams still hadn't agreed on a network path, and nobody had asked the works council anything.

Build, buy, or partner?