All writing
Playbook2026.08

Where AI actually pays in manufacturing

Real-world AI use cases in manufacturing, ranked by time-to-value — not the robot-arm fantasy, but the paperwork around the plant: PO chasing, downtime investigations, quality reporting, supplier exposure, and the tribal knowledge walking out the door. What each one looks like today, what an agent changes, and what it needs to connect to.


When people picture AI in manufacturing, they picture the floor: robot arms, vision systems, machines that fix themselves. That future is coming — we work on it — but it is mostly not where the money is today. The money is in the paperwork around the plant: the hours your best people spend moving information between systems that don't talk, assembling answers by hand that the data already contains.

This is the first in a series on real-world AI use cases by industry — what's actually working, ranked by time-to-value, with the failure modes named. Not the demos. The jobs.

Where the hours actually go

Walk a mid-size plant and the pattern repeats. The buyer lives in the ERP, the inbox, and a spreadsheet, reconciling all three by hand. The maintenance lead investigates every breakdown from scratch because the last investigation lives in a retired technician's head. The quality engineer spends the end of every month assembling the same customer report from four systems. None of this is the work. It's the overhead around the work — and it's exactly the shape of task that current AI agents do well: read several systems, cross-reference, draft the output, flag the exceptions.

What follows is ranked by time-to-value: how fast a real plant, with the systems it actually has, sees the payoff.

1. Chasing open orders

Today: A buyer with 150 open POs checks status by cross-referencing the ERP against shipping confirmations and supplier emails — then writes the follow-ups. It's hours a day, it's interrupt-driven, and a missed late order becomes a line-down event.

With an agent: Every morning, the agent sweeps open POs, matches them against confirmations and the inbox, produces the at-risk list, and drafts the follow-up emails for review. The buyer starts the day approving instead of assembling.

What it needs: ERP read access and the mailbox. That's why it's first — nearly every plant has both reachable today, and the value shows up in the first week.

2. Supplier intelligence

Today: A supplier announces an 8% price increase. Someone spends an afternoon working out the exposure — spend history from the ERP, alternates from old quotes buried in email — and the answer arrives too late to negotiate well.

With an agent: The same question answered in minutes, from the same sources: total exposure from PO history, every past quote from competing suppliers surfaced and compared. Ask it in plain language; get the answer with the receipts attached.

What it needs: The same two systems as use case 1 — which is why these two usually ship together.

3. Downtime investigations that compound

Today: A machine goes down and the investigation starts from zero: equipment history in the CMMS, sensor trends in the historian, shift notes on paper, the last root-cause analysis in someone's memory. Under time pressure, teams treat symptoms and the failure returns.

With an agent: Ask what happened, and it assembles the history, the trends, the notes, and every prior occurrence of the same failure mode into one cited write-up — including the uncomfortable one: the corrective action from last time that was supposed to prevent exactly this. Every investigation is remembered, so the next one starts from all of them.

What it needs: CMMS access at minimum; historian access makes it sharper. Time-to-value is a little longer than the procurement pair, but this is the use case that compounds — the system gets smarter with every failure, instead of your knowledge retiring with your techs.

4. The recurring report

Today: The weekly customer quality report, the monthly OTIF review, the morning production summary — each one assembled by a skilled person doing unskilled work: exporting, pasting, formatting, every single period.

With an agent: The report builds itself on schedule from the source systems — Cpk trends, non-conformances, CAPA status, delivery performance — and a human reviews and sends. The engineer gets their month-end back.

What it needs: Read access to wherever the numbers live, including spreadsheets. Unglamorous, high-frequency, and often the fastest win of all because the output already has a defined format someone is paying for.

5. The document pile

Today: Certs, packing slips, invoices, supplier scorecards — matched and keyed into systems by hand, at entry-level wages and skilled-labor error rates.

With an agent: Batch in, structured data out — extracted, classified, validated against the PO, exceptions flagged for a human. This can even run with no integration at all: documents go in, a completed spreadsheet comes back, which makes it one of the safest first deployments in regulated or integration-averse environments.

What it needs: Almost nothing. That's the point.

6. Tribal knowledge, captured

Today: The answer to "why do we run this job on machine 3 at reduced feed?" exists only in the head of the person who set it up in 2019. Every retirement is a data loss event.

With an agent: The knowledge that surfaces during normal work — in investigations, in questions asked and answered, in shift handoffs — is retained, indexed, and citable, so the plant's operating memory accrues to the plant instead of to individuals.

What it needs: Honestly: time, and one of the use cases above running first. Knowledge capture fails as a standalone project — nobody documents for documentation's sake — and succeeds as a byproduct of an agent that's already in the daily flow of work.

How to pick your first

Three tests, in order. Does the job burn real hours weekly — measured, not guessed? Is the data it needs reachable today — email, spreadsheets, and an ERP export count; a historian you haven't connected yet does not? And is there one number that will move — hours returned, expedite fees avoided, report cycle time — that you can measure before and after?

If a use case passes all three, a pilot should show its result in weeks. If it needs a year of digitization first, it's not your first use case — start with what you actually have and let the footprint grow with trust.

What doesn't work yet

Honesty about the other side of the ledger. Predictive maintenance without sensor history is a slide, not a project — if the data doesn't exist yet, start collecting it, but spend your pilot budget elsewhere. Fully autonomous action in week one is a mistake even when the technology can do it: every use case above starts with the agent drafting and a human approving, and earns autonomy per task as accuracy proves out. And a plant-wide transformation program as the opening move mostly produces three agents doing one job — pick one workflow, one number, one owner, and expand from what works.

The plants getting this right aren't the most digitized ones. They're the ones that started where their data already was, put a number on one job, and let the wins stack. That's the pattern this whole series will keep returning to — industry by industry.