AI Agents for Manufacturing Plant Operationsin 2026

Most articles about AI in manufacturing start with capability. This one starts with a line drawn on a wall chart in every plant engineering office in the world, because that line is what actually decides whether an agent ships.

The reference model is ISA-95, published internationally as IEC 62264, the standard for integrating enterprise and control systems. It defines a hierarchy commonly rendered as Levels 0 through 4, a set of operations models covering production, maintenance, quality and inventory, and the B2MML XML schemas used for exchange between ERP and manufacturing operations. The boundary it draws is simple to state and consequential to cross: ERP at Level 4 governs planning, master data and financial accountability, while MES at Level 3 governs real-time execution, sequencing and traceability.

Everything an outsider finds confusing about manufacturing software follows from that split. There is no single system of record in a plant. There are several, they are owned by different functions, they disagree with each other in normal operation, and reconciling them is a job title rather than a bug. The order lives in ERP. What was actually made, on which machine, from which lot, by whom, lives in MES. The process signals live in a historian. The non-conformance and the corrective action live in the quality system. The asset and the work order live in the maintenance system. An agent designed against the assumption that the plant is one database has already made the mistake that ends the project — usually in month three, when someone asks why the agent's production count does not match finance.

The ISA-95 levels as they behave in a discrete plant, and the write posture at each — Frenchy Digital, August 2026.

Read that table from the bottom up and the shape of the whole problem appears. The richest data in the plant is at the bottom, and the write path narrows as you descend, until at Level 1 it closes entirely. That is not an accident of legacy architecture. It is a deliberately engineered liability boundary, and in some plants it has been engineered in hardware.

The transport standards at and below the boundary are worth knowing by name, because vendors will use them as shorthand for capability they may not have. OPC UA, standardised as IEC 62541, is the vendor-neutral industrial interoperability stack; its companion specification for the ISA-95 Common Object Model, OPC 10030, represents ISA-95 equipment, personnel, material and physical-asset objects natively in OPC UA. Note the date on that companion specification: Release 1.00 is dated November 2013. Anyone presenting OPC UA plus ISA-95 as a 2026 convergence is describing something that has existed for over a decade.

MQTT with Eclipse Sparkplug is the other common pattern — an open specification for MQTT-based industrial interoperability that defines birth and death certificates and Protobuf payloads, and is commonly paired with the Unified Namespace approach. And MTConnect is the semantic vocabulary for machine tools and robotics. We will come back to MTConnect, because its design contains the single cleanest argument in this article.

One caution about all three. Standards give you a shared vocabulary and a shared transport. Neither gives you a shared instance model of your specific plant — which machine is which, which tag means what, how this cell's naming convention relates to that one's. The mapping work is the project. It is also the part that no vendor demo shows you, and the part that a plant with three acquisitions in its history will find is measured in months.

Ask the four questions this cluster asks of every industry, and manufacturing answers them differently at each level. Who owns the authoritative copy. Who is permitted to change it. What the contract or API actually permits. And what breaks it.

At Level 4 the answer is commercial. Modern ERP platforms publish APIs, so the enterprise layer is genuinely a documented-API problem — and this is where the most under-discussed cost in the whole category sits.

The other Level 4 constraint is a support clock. Reported dates for SAP ECC 6.0 put mainstream maintenance for enhancement packages 0 through 5 as having ended on 31 December 2025 with no extended maintenance offered, enhancement packages 6 through 8 ending on 31 December 2027, and optional extended maintenance running to 31 December 2030 for the final three enhancement packages — covering security patches, basic support and some legal updates, but not new features or full legal adjustment. Those dates are consistent across the consultancy sources we found and we could not confirm them from SAP's own maintenance-strategy page, so treat them as a prompt to check rather than as gospel. The point stands either way: do not build an agent dependency on a platform whose support clock you have not personally verified.

At Level 3 the answer is vendor-dependent and, honestly, opaque. We did not verify the API surface, write endpoints, rate limits or pricing of any specific MES, SCADA, historian or CMMS product in this research pass, and we are not going to describe one from memory. That absence is itself the finding. In a category where every vendor site says "open" and "integrated," the specific, checkable question — which writes exist at my licence tier, at what rate limit, with what audit trail — is answerable only by the vendor, in writing, and it should be a deliverable of discovery rather than an assumption behind an estimate.

At Level 2 and below the answer is architectural, and it is where the most common misconception in this field lives. IEC 62443 structures OT security as zones — groupings of assets sharing security requirements — connected by conduits, which are defined and controlled communication paths between zones. IEC 62443-3-2 specifies a risk-based process for partitioning a system into zones and conduits and assigning target security levels. Conduits must be enforceable, and enforcement is commonly a firewall and a segmented DMZ. In some deployments an operator enforces a particular conduit with a data diode, which enforces one-way communication at the physical layer.

Which means the honest architecture question is not "can we get through the conduit." It is "what has this operator chosen to enforce, and what did they choose it for." Find that out in week one from the person who owns the OT risk assessment, not in week nine from a firewall log.

This is the section people skip to, so let us make the argument in a form that does not depend on any unverified claim.

The reason an agent should not write setpoints is not that the network will not carry the packet. In most plants it will. The reason is that a setpoint change is a change to a validated process — and every regulated industry that has confronted this question has answered it the same way: safety-critical change is a filing, not a deploy.

Four independent lines of evidence for the same boundary — Frenchy Digital, August 2026.

Take the rail analogue first, because it is the most stark. Under 49 CFR Part 236, Subpart I, before a railroad can make certain changes to an FRA-certified positive train control system or its approved safety plan, the host railroad must submit and obtain FRA approval of a Request for Amendment under Section 236.1021, and the enumerated triggers include modification of a safety-critical element. FRA publishes a Federal Register notice inviting public comment when the request seeks approval of a material modification of a signal or train control system, and may approve, approve with conditions, or deny at its sole discretion. This is live practice, not history: requests for amendment were noticed through 2026 for Amtrak, PATH, MBTA and the Belt Railway Company of Chicago, including one seeking approval of a software update associated with placing a new interlocking into service.

A software change to a safety-critical element is a federal filing with a public comment docket. That is the outer bound of what "autonomous agent modifies the system" can mean in a regulated control environment, and it is the cleanest available parallel to the plant setpoint question.

The medical-device analogue is now in force and is the freshest date-sensitive fact in this article. FDA's Quality Management System Regulation amends 21 CFR Part 820 to incorporate ISO 13485:2016 by reference and took effect on 2 February 2026, at which point FDA began using the updated Inspection of Medical Device Manufacturers Compliance Program 7382.850 and retired the previous inspection programs. FDA does not issue ISO 13485 certificates of conformance from its inspections and does not require them. Process change in that world runs through an inspected quality system, and the record produced is evidence.

And then the industry's own machine-data standard settles the argument without any regulator at all. MTConnect is structured around an Agent — a naming collision that has become genuinely confusing in 2026 — that publishes device data to clients over HTTP. The protocol defines probe, current, sample and asset requests. Those are retrieval verbs. There is no write verb in the standard. It is a read-only data-publishing protocol by design.

So the design rule writes itself. The correct agent reads the plant and writes a proposal into a system that has a human approval step and an audit trail — a work order, a deviation, a change request. Never a tag.

A note on what we are deliberately not claiming, because the temptation to over-argue this point is strong and the over-argument is easy to falsify. We did not verify the text of IEC 61511 or IEC 61508, and we make no claim that a functional-safety standard prohibits automated setpoint writes. We did not verify OSHA lockout/tagout applicability to software-initiated setpoint changes. We did not verify the machine-safety standard numbers that circulate in this discussion, and we did not find any incident statistic about AI or automation causing an industrial safety event that survived sourcing. The argument above needs none of that material, which is exactly why we made it that way.

The pillar article in this cluster defines the integration ladder: documented public API, then certified partner program, then EDI or batch file, then screen scraping and RPA, then no path at all. Each rung down means less vendor cooperation, more fragility and more contractual exposure. You are on exactly one rung per system, whatever your architecture diagram says.

The integration ladder mapped onto a discrete manufacturing estate — Frenchy Digital, August 2026.

Three observations about this table that are specific to plants.

First, rung three deserves more respect than it gets. Batch and file exchange is decades old, boring and extremely durable, and for an agent it is often the safestwrite path precisely because it is batch: the file is the checkpoint. Real-time API writes do not get reconciliation for free, and you have to build it. A nightly B2MML exchange with a reconciliation report is a less impressive architecture diagram and a considerably better night's sleep.

Second, rung four deserves an honest treatment rather than a dismissal or an endorsement. RPA driving an MES or quality terminal is frequently the only available path, and it is structurally fragile because you are consuming a presentation layer the vendor is free to change without notice or versioning. Any UI change, any A/B test, any MFA rollout breaks it. And the modern agentic framing does not fix that. On its own agentic-automation page, UiPath describes the division of labour as "Agents reason within governed workflows… Robots act on systems of record." That is a vendor describing its own product, and it is worth reading closely: the robots still do the writing. The brittle screen-driving layer does not disappear; it gets a planner on top of it. What changes is that failures become non-deterministic. A scripted bot fails loudly and identically every time. An agent may improvise around a changed screen and write something wrong.

There is also a pricing fact worth stating about that rung, because it is the sort of thing that quietly wrecks a business case. On its published pricing page, UiPath lists a Basic tier as starting at $25 per month, capped in seats and unattended robots, and lists Standard and Enterprise as contact-sales. You cannot price an RPA-to-agent migration from public information, and that is itself a material fact about the rung. The per-robot annual figures that circulate on third-party pricing-aggregator blogs have no disclosed methodology; they are unverifiable, and we will not print them.

Third, rung five is a real and common answer at the control layer, and saying so plainly is more useful than pretending otherwise. When the honest answer is that there is no write path, the options are to change vendors, to put a human in the loop for the write step and let the agent do everything up to it, or to wait for a regulatory forcing function. The middle option is the important one: an agent that drafts and a human who commits is a legitimate architecture, not a failure.

On the regulatory forcing function — it is not hypothetical in manufacturing this year. Under the EU Data Act, core obligations have applied since 12 September 2025, and from 12 September 2026 connected products must be designed with accessible data pathways, with switching charges prohibited outright from 12 January 2027. That is law creating a documented data path where a vendor offered none. Rungs can move up the ladder by regulation rather than by vendor goodwill, and if you build connected products sold into the EU, that date is roughly four weeks from now.

A documented API with no write path is a rung five in disguise. Check the write surface before you architect, not after.

— Frenchy Digital, integration principle

One more thing the ladder framing usefully kills. The Model Context Protocol does not change your rung. MCP standardises how a tool is described and called; it does not decide whether this agent may issue this write, and no system of record gains a write path because MCP exists. It is a wrapper around whatever rung you were already on. It also carries a real change cadence: the current specification is 2026-07-28, published on 28 July 2026, and the headline change was architectural — MCP moved from a bidirectional stateful protocol to a request/response stateless one, roughly eight months after the previous stable specification. Building on it means accepting that cadence.

Outsiders read quality as paperwork. In a plant it is an inspected record under regulations that changed recently, with reporting clocks measured in hours and days. That combination — structured, deadline-driven document assembly from internal records, with a human making the actual judgement — is the highest-value legitimate territory for an agent in this entire industry.

The quality, traceability and reporting obligations that bound an agent in a discrete plant, current as of 17 August 2026 — Frenchy Digital.

The CPSC obligation is the most agent-relevant compliance fact in this section, and it is worth stating carefully. Section 15(b) of the Consumer Product Safety Act requires manufacturers, importers, distributors and retailers to notify the Commission immediately on information reasonably supporting a conclusion that a product fails a mandatory standard or a relied-upon voluntary standard, contains a defect that could create a substantial product hazard, or creates an unreasonable risk of serious injury or death. The reporting expectation is within 24 hours of obtaining reportable information. A firm may conduct a reasonably expeditious investigation first, which CPSC guidance indicates should not exceed 10 days unless a longer period is demonstrably reasonable. Injury need not have occurred.

Read that as a specification for an agent and the boundary is drawn for you. A 24-hour clock with a bounded 10-day investigation window defines exactly what an agent may and may not do with a signal from the field: it may accelerate detection and assemble the evidence package; it may not decide. The judgement about whether information reasonably supports a conclusion is a statutory judgement made by a named accountable person, and no architecture makes an agent the right holder of it.

The vehicle regime has the same shape at a slightly slower tempo. Under 49 CFR Part 573, copies of defect reports must reach NHTSA's Recall Management Division not later than five days after they are first sent to manufacturers, distributors, dealers or purchasers, with quarterly reports under Section 573.7, and there is monthly reporting of manufacturer communications about defective equipment plus five-day reporting of foreign safety recalls after a determination. Part 579 Subpart C sets out Early Warning Reporting: quarterly reporting of production information, incidents involving death or injury, and aggregate data on property damage claims, consumer complaints, warranty claims and field reports, with the quarterly obligation attaching to manufacturers of light vehicles, motorcycles or trailers producing 500 or more units per year. We did not verify the precise trigger language or the full Early Warning Reporting data element list, so do not let anyone build a module that enumerates them from memory.

Two date corrections belong here because an article written from a pre-2026 memory would get both wrong. The FSMA Section 204 Food Traceability Rule compliance date is 20 July 2028, not January 2026: FDA announced an intent to extend by 30 months in March 2025, published the extension in the Federal Register in August 2025, and in November 2025 Congress made it binding by directing FDA not to enforce before that date. And the Quality Management System Regulation is in force as of 2 February 2026, which changes what an inspection looks like for any device manufacturer. One sourcing caveat on that second item: our direct fetch of FDA's QMSR page failed, so we are relying on a search summary of FDA's own pages rather than a page we read end to end. Confirm it against the FDA page before you put it in a validation plan.

Finally, the newest obligation, and the one closest to the calendar. Cyber Resilience Act reporting obligations apply from 11 September 2026. Manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents through the CRA Single Reporting Platform to ENISA: an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available, or one month for severe incidents. Article 14 obligations apply to products placed on the market before 11 December 2027 — which means legacy connected products already sold are in scope. If you build connected industrial equipment for the European market, that is the fact to put in front of your board this quarter, and an agent that drafts the 24-hour early warning from incident data is a genuinely good use of the technology.

If you want one recommendation from this article that survives every constraint above, it is this: the maintenance system is the best available write target for an agent in a plant, because a work order is a proposal with an approval step and an audit trail rather than a live control action.

Everything agents are good at maps onto work-order intake. Free-text descriptions written at 3am by a technician in a hurry. Duplicate reports of the same fault from three shifts. History buried in a system nobody searches because the search is bad. Parts and asset context that exists but is three clicks away. An agent that normalises the description, clusters likely duplicates, pulls the last six occurrences on that asset, proposes a priority and a trade assignment from history, and hands the planner a complete draft is doing work that is currently done badly or not at all.

Everything agents should not be trusted with sits on the other side of the planner's accept, edit or reject decision. Scheduling against a running line, issuing a permit to work, releasing labour, and any judgement about whether a machine is safe to open are decisions with named accountable people and permit systems behind them. The agent may recommend a slot. It does not release work.

The failure mode is also cheap, which matters more than it sounds. A bad draft work order costs a planner thirty seconds. A bad setpoint costs something you do not want to be explaining. When you are choosing a first workflow, pick the one where being wrong is boring.

There is a second-order benefit to starting here that plant managers tend to see faster than IT does. Work-order data quality improves the moment something is reading it consistently. Agents are unforgiving readers of inconsistent free text, and the first month of a work-order agent usually produces a short list of form and taxonomy fixes that would have paid for themselves without any model at all. Take those wins; they are the substrate everything later depends on.

Readers ask for a top-ten table of plant software scored for agent readiness. We are going to give you the ten platforms and refuse the score, and the refusal is the useful part.

Ten platforms a discrete plant is likely to be running, assessed on verifiability rather than capability — Frenchy Digital, checked 17 August 2026.

Other real products in the same categories, named for completeness and with the same caveat: Canary and InfluxDB as historians, and AVEVA/Wonderware InTouch on the SCADA side. Their existence is not in doubt; we verified none of their API surfaces and neither should you assert one.

One structural difference in that table is worth pulling out, because it is a genuine integration cost that most software buyers have never considered. Licensing models differ in shape, not just in price. Inductive Automation publishes an unlimited-tag, unlimited-client, per-server model for Ignition on its own site — and a vendor describing its own licensing model is acceptable evidence of that model. Other historians in this category license by tag. If your data source is licensed per tag, an agent that wants more signals makes the data source more expensive, and the agent's appetite for context has a cost curve. If it is per server, it does not.

We deliberately did not put a dollar figure on either side of that comparison. The clearest comparison we found was published by a competing historian vendor, and a vendor's table of a competitor's pricing is not evidence of that competitor's pricing. The structural observation lands without a number, and a number we could not verify would only have made it look more authoritative than it is.

Every deployment argument in a plant eventually reduces to a version of this table. Write it before you build, get it signed by the people whose names are on the process, and put it in the contract.

Human-in-the-loop boundaries for an agent in discrete manufacturing operations — Frenchy Digital, August 2026.

Three principles hold the table together. The first is that the control must be structural rather than instructional. "The agent is told not to write setpoints" is not a control; a credential with no write scope into the OT zone is. The OWASP GenAI guidance for Excessive Agency says the same thing in different words: least privilege, confirmation for high-impact actions, tool-usage logging.

The second is that a review step you do not measure is a review step that will quietly stop existing. Log the time between presentation and decision as a distribution and look at the fast tail specifically. A workflow with a healthy median and a large sub-two-second population is a workflow where the human checkpoint has become a click, and that is worse than no checkpoint at all because it launders an unreviewed output as a reviewed one.

The third is identity. An agent needs its own identity, not a shared service account and not a human's credentials. Microsoft has articulated the reasoning about as well as anyone in its Entra Agent ID documentation: application identities carry the expectation of long-term stability, known ownership and managed lifecycle, whereas an agent might exist for minutes during a specific task, or might be created and destroyed thousands of times per day. Microsoft draws the distinction that matters for a plant explicitly — autonomous access, where the agent acts on rights given directly to its own identity, versus delegated access, where it acts on behalf of a human user who controls which rights are delegated. Note also the commercial shape: Microsoft states the identity is available to all Entra customers while extending Entra security features to agents requires a further product. The identity is free; the controls are the upsell.

And be honest about what identity does not yet solve. There is no deployed standard that carries "acting for this named person, scoped, revocable" across trust domains end to end. The leading IETF attempt, the Identity Assertion JWT Authorization Grant, is at revision -04 dated May 2026 with an IESG state of "I-D Exists" — it is not an RFC. Agent-specific OAuth extensions exist as individual drafts, not working-group items. Anyone describing cross-vendor agent delegation as solved is describing drafts.

A plant agent reads untrusted content constantly. Supplier PDFs. Customer complaints. Contractor certificates. Scanned travellers and inspection sheets. Emails from a distributor about a field failure. Every one of those is an input written by someone outside your control, and prompt injection is not solved.

The clearest available framing is Simon Willison's lethal trifecta: access to your private data, exposure to untrusted content, and the ability to externally communicate in a way that could be used to steal data. On whether it is fixable, he writes that "we still don't know how to 100% reliably prevent this from happening." On detection-based vendor defences, he notes that they almost always carry confident claims of capturing 95 percent of attacks or similar — and that "in web application security 95% is very much a failing grade."

The integration version of the trifecta, for this cluster, is an agent that holds a write credential into a system of record, reads untrusted content, and can act without a human seeing it first. Remove any one leg and the blast radius collapses. That is the whole practical discipline, and it is architectural rather than detective.

The rubric for reading a vendor security section — adapted for this cluster from the blast-radius framing.

The OWASP GenAI LLM Top 10 for 2026, published 4 August 2026, places Prompt Injection at LLM01, Excessive Agency at LLM03 and Improper Output Handling at LLM10. For an agent with tool access to production systems, LLM03 and LLM10 are the priority pair. One caution worth repeating because it is the easiest mistake to make in a security section: those are the 2026 numbers. The 2025 list numbered Excessive Agency and Improper Output Handling differently, and in the 2026 list those older slots hold entirely different risks. Mixing the two editions is the single most catchable error available to a security-literate reader.

The MCP specification's own security document is worth reading for the same reason. It contains genuine normative requirements — servers must not accept tokens that were not explicitly issued for them; proxy servers must implement per-client consent before forwarding to a third-party authorization server; redirect URI validation must be exact string matching rather than pattern matching or wildcards; servers must not treat possession of a state handle as authentication. Its scope-minimization section names the risks directly: expanded blast radius from a stolen broad token, privilege chaining, and audit noise where a single omnibus scope masks user intent per operation. Wildcard and omnibus scopes are named anti-patterns.

Which brings us to the least glamorous and most consequential engineering in a plant integration: making sure a retry does not become a duplicate record. There is no standard to lean on here. The IETF draft for an Idempotency-Key header is at revision -07, dated 15 October 2025, with an IESG state of Expired. It is not an RFC. The de-facto convention is Stripe's, which works by saving the resulting status code and body of the first request made for any given key, so that subsequent requests with the same key return the same result — including 500 errors — and which errors if incoming parameters do not match the original request.

• Derive the key from business intent, not from the attempt: Key on the business fact — work order plus operation plus quantity, or lot plus inspection plus result — rather than a fresh UUID per retry, which defeats the mechanism entirely. This is the single most common implementation error and it is invisible until the month-end reconciliation.
• Persist the key before the call, not after: A key that exists only in the agent's context window is lost on a crash, and a crash mid-write is exactly the scenario the key was supposed to cover.
• Respect the retention window: Stripe documents that keys may be pruned after at least 24 hours and that a new request is generated if a key is reused after pruning. Your own dedupe table must outlive whatever window the downstream system enforces, or a delayed retry writes twice.
• Never let the model choose the key: Non-determinism in key generation is indistinguishable from having no idempotency at all. Generate it in code, from the business record.
• Reconcile rather than trust: Agents write over unreliable networks and may be interrupted mid-plan. Read back and compare against the system of record on a schedule. Treat the system of record as truth and the agent's belief as a hypothesis.
• Prefer reversible writes: A draft work order beats a released one. A proposed disposition beats a closed non-conformance. Reversibility is the cheapest blast-radius control available and it composes with everything above.
• Take the free checkpoint where batch offers one: Batch and file-based rungs get reconciliation for free because the file is the checkpoint. Real-time API writes do not, and you have to build it deliberately.

Plant integrations rarely fail loudly. They degrade, and the degradation is usually invisible until someone acts on a wrong number. Build the detection signal for each of these before you build the agent.

The ten failure modes we scope for in a discrete manufacturing agent build — Frenchy Digital, August 2026.

Two of these deserve a longer look because they are the ones teams consistently under-plan.

Version pinningis the failure mode with the best available illustration from an adjacent industry. In freight rail, one Class I carrier upgraded its EDI requirements from one version to the next across every relevant transaction set, effective on a stated date, and announced it on a customer web page rather than pushing it to a changelog endpoint. That is exactly the class of change that silently breaks an agent whose parser was written against last year's implementation guide. Manufacturing has the same pattern in a different costume: standards move, vendor schemas move, and the announcement lives somewhere a human has to go and read. Contract tests against recorded responses, run in CI, are the only defence that works while people are on holiday.

Contract renewal and acquisition is the failure mode nobody puts in an architecture review. Partner program terms are unilateral and renewable, and your access is contingent on a contract the vendor drafted. The clearest published example of what that means in practice comes from outside manufacturing: Yardi states on its own site that participation in its Interfaces Program requires an annual license fee per interface, that the fee varies per interface type and in some cases is based on a per-transactional model, and — for its Standard Interface Partnership specifically — that a company must be two years old and have at least three active Voyager clients to qualify. That is a published, honest picture of what a partner program is: a recurring per-interface fee and a prior-traction gate on the sanctioned track. Model any partner-program integration as per-interface, recurring, forever, and keep a rung-three fallback documented so a renewal conversation is not an outage.

This is the part of the article that is actually a plan. Seven phases, an owner per phase, an entry and exit criterion per phase, and — the part most methodologies omit — what to do when a phase fails.

A sequenced 24-week path from boundary map to a second workflow — Frenchy Digital, August 2026.

The ordering is deliberate and the first two phases are the ones people want to skip. Phase 0 exists because the boundary map is the artifact that tells you whether the project is a software project or a change-control project, and those have different sponsors, different budgets and different timelines. Getting OT security into the room in week one is not bureaucratic caution; it is how you avoid discovering in week nine that the conduit you designed around is one an operator deliberately enforces in one direction.

Phase 1 exists because the write path is where the schedule actually goes. Scope every plant engagement by asking, in writing, what the write path is for each target system, before anyone estimates the model work. A project that assumes a write API exists and discovers it does not is a project that doubles. And when the answer comes back "read-only at your tier," that is not a failed phase — it is a resolved unknown that reshapes the architecture into draft-and-commit, which was probably the right shape anyway.

Phase 3 is the shadow run, and it is the cheapest insurance in the plan. The agent produces output that nobody acts on while humans do the work exactly as before, and the drafts are compared afterwards. The disagreement cases are more informative than the agreements, because they usually reveal that the source data is inconsistent rather than that the model is weak — and inconsistent source data is a form redesign, not a model problem.

Each of these is a specific, checkable failure rather than a general caution, and most of them are detectable from the first deck.

The Frenchy Digital red-flag list for manufacturing AI buyers, August 2026.

The statistics deserve their own table, because in this industry the headline numbers are unusually bad and unusually persistent. Here is what we chased, what we found, and what we will not print.

Manufacturing statistics we refuse to publish, and the reasons — Frenchy Digital, checked August 2026.

There is a general rule underneath all four rows and it is worth stating out loud once. In heavy industry the credible numbers come from federal statistical programs and regulatory dockets — the Federal Register, the agencies' own reporting requirements, published rule text — and they are freely available. The uncredible numbers come from vendors quantifying the problem they sell the fix for. When both are available on the same topic, the choice to cite the vendor is a choice.

In a category where the headline statistics do not survive sourcing, the vendor who tells you what they cannot prove is more trustworthy than the vendor whose deck has a number for everything.

— Frenchy Digital buyer's principle

These are the bands Frenchy Digital uses to scope plant operations engagements in 2026. They assume the boundary map and the write-path assessment are in scope from the start, because that is where the schedule risk lives in manufacturing and discovering it late is what makes a project expensive.

Frenchy Digital cost bands for manufacturing and heavy-industry AI engagements, 2026.

Senior-led delivery runs $150 to $225 per hour, and ongoing retainers run $2,500 to $9,500 per month covering model and dependency upgrades, evaluation expansion, incident response, and a quarterly technical review. Every engagement carries a 30-day post-launch warranty, and you receive a written scope with a fixed-price phased proposal within 5 business days of the discovery call. Book at calendly.com/frenchydigital/discovery-call or call +1 (424) 272-5601.

Two budgeting notes specific to plants. The first is that the integration substrate is largely a fixed cost, paid once and reused by everything after. The first agent pays for the historian connection, the identity model, the review queue, the logging and the reconciliation job. The fourth agent inherits all of it. Sites that sequence their automation get materially better economics than sites that run four disconnected pilots in parallel.

The second is that there are running costs in a plant that do not appear in any software quote: the ERP licensing consequence of documents created by automated systems, and the historian licensing consequence of an agent that wants more tags. Neither is large at pilot scale and both scale with success. Model them in the business case at the volume you expect in year two, not the volume you will see in month two.

This article has argued that the evidence base in this category is uneven and that naming an untraceable number is more useful than repeating it. That standard applies to our own work, so here is the honest list of what we could not establish.

• No specific MES, SCADA, historian or CMMS API surface was verified: We did not confirm the write endpoints, rate limits, audit guarantees or pricing of any named product in this pass. Every product mentioned in this article is named as an example of its category, never as a described integration target. Get the answer from your vendor in writing.
• SAP's own statements on digital access and maintenance dates were not reachable: SAP's site did not render for our research pass, so the digital-access mechanics and the ECC maintenance dates come from licensing consultancies, some of which sell services predicated on that framing. The concepts are well established; the specifics need confirming against your own contract and SAP's own page.
• Functional-safety and machine-safety standard text was not verified: We did not read IEC 61511, IEC 61508, ISO 13849, IEC 62061, ISO 10218 or ANSI B11, and we make no claim about what any of them requires. We also did not verify whether OSHA lockout/tagout provisions reach software-initiated setpoint changes. The setpoint argument in this article is deliberately written so it needs none of that material.
• No incident statistic about AI causing an industrial safety event survived sourcing: We looked. We found nothing with a named source, a method and a date. We would rather say that than reach for an anecdote.
• No independent measurement of agent integration success or failure rates exists: There is no methodologically-disclosed study of how often these projects succeed, and there is no independent benchmark for agent integration into plant software. Every accuracy and ROI figure in this market is vendor-published. Build your business case on a baseline you measured, because there is nothing to borrow.
• EU Machinery Regulation and AI Act interactions were not researched: We did not verify how the EU Machinery Regulation or AI Act annexes bear on machinery with AI-driven components, and the AI Act timeline has moved since our model's training data was assembled. We will not write about them from memory, and neither should your vendor.
• Prompt injection is unsolved, including in what we build: Any agent reading supplier documents, customer complaints or contractor certificates is exposed. We reduce blast radius through capability scoping, deny-by-default arguments, no-write-credential-with-untrusted-content sessions, and human approval on the write step. We do not claim to eliminate the risk, and nobody who does should be believed.
• Document and log quality sets the ceiling: An agent that reads shift logs is bounded by how well shift logs are written. Sites with inconsistent free-text entry get less value than sites with structured capture, and no model fixes an input problem. Sometimes the highest-value output of a discovery engagement is a form redesign.
• We are a software firm, not a process safety engineering practice: Ground rules for validated processes, functional safety assessment, machine safety and regulatory disposition belong to qualified professionals. Our systems feed their judgement; they do not substitute for it, and any vendor who offers to substitute for it is selling you a liability.

None of this argues against building. It argues for building the measurement alongside the system, choosing one workflow with a real baseline and a named owner, and being honest inside your own organisation about which claims in this category have evidence behind them and which do not. In manufacturing that honesty pays a second dividend, because the people who run your plant will spot an unsourced number faster than your board will — and once they have, the whole programme is on the wrong footing.