What Agentic AI Actually Looks Like in Supply Chain and Manufacturing Operations

Supply chain teams have the strongest business case for agents of any function I work with, and the most sceptical audience. Both for the same reason: they have been sold automation before.

Twenty years of ERP modules, planning systems, and RPA scripts have left most operations teams with a working system that handles the standard path and an enormous manual apparatus around the edges. Spreadsheets, email threads, phone calls, and a few people who know things nobody wrote down.

That apparatus is where the agent opportunity is. Not in replacing the ERP, which works. In the exception handling that grew up around it.

Start with the exception queue

Here is the general principle, and it applies well beyond supply chain: the best agent target is work that already sits outside the system of record.

If a task lives inside the ERP and follows a defined path, it is already automated or it is a workflow problem, and a workflow engine will do it more cheaply and more predictably than an agent. The work that has resisted automation is the work that requires reading something unstructured, making a judgment, and taking an action in one of several systems. That is precisely the shape agents fit.

In a manufacturing or distribution business, that queue is usually large and usually invisible in the systems reporting, because none of it is logged anywhere. Ask a planner how much of their week is spent on exceptions and you will get an answer between 40 and 70%.

The four that work

Supplier communication triage. This is the highest-return workflow I see, consistently. A procurement inbox receives order acknowledgements, delivery date changes, shortage notifications, price change notices, invoices, and queries, in inconsistent formats, in several languages, from suppliers of wildly varying sophistication. Some are structured EDI. Most are a PDF attached to an email written by a person.

Today a human reads each one, works out what it means, and updates the relevant system. An agent can classify the message, extract the fields, check them against the purchase order, and either update the system or escalate a discrepancy. The volume is high, the pattern is learnable, and the cost of an error is usually a flag rather than a disaster.

The thing that makes this work well is that the escalation path already exists. When the agent is unsure, it does what a junior buyer does: puts it in front of someone senior with the relevant context attached.

Delivery exception handling. A shipment is late, short, damaged, or misrouted. Resolving it means checking the ASN, the carrier's tracking, the receiving record and the original order, working out what actually happened, deciding whether to expedite, substitute, or accept, and then telling the affected parties.

That is a multi-step investigation across four systems with a judgment at the end, which is a good agent shape. It also has a clean measure of success: time to resolution, which most operations teams already track.

Document reconciliation across the three-way match. Purchase order, goods receipt, invoice. The standard case is automated. The failures land in a queue where somebody works out whether a quantity discrepancy is a short shipment, a partial delivery, a unit of measure mismatch, or a supplier error.

The reason this queue never empties is that resolving each case requires reading things: the delivery note, the email thread, the contract terms. Agents are good at exactly that, and the financial impact is direct, because unresolved matching failures are either payment delays or overpayments.

Inbound quality and compliance documentation. Certificates of analysis, material test reports, customs paperwork, safety data sheets. Checking that the received document says what it should, matches the specification, and has not expired is high-volume, tedious, and error-prone when done by a tired human at 4pm. It is also the kind of check where an agent's consistency is a genuine advantage over a person.

The two that disappoint

I want to be equally direct about where agents underperform, because pointing them at these is how supply chain teams lose faith in the whole category.

Planning and optimisation. Do not use an LLM agent to decide replenishment quantities, production sequencing, or network routing. These are constrained optimisation problems, they have been studied for sixty years, and a solver will beat a language model on quality, speed, and cost by a large margin. An agent that reasons its way to a reorder quantity is doing arithmetic badly and expensively.

Where an agent helps around planning is in the input and output layers: gathering the context that the planner needs, explaining why the solver produced a counterintuitive answer, and handling the exceptions the plan does not cover. That is a support role and it is a good one.

Demand forecasting. Same argument. Statistical and machine learning methods that have been refined for decades outperform a language model asked to predict a number. Agents can enrich a forecast with unstructured signals, a supplier's warning about capacity, a news item about a port, but the forecast itself should come from a forecasting method.

The rule I would give: if the problem has a well-defined objective function and a body of operations research behind it, use the tool built for it. Point the agent at the unstructured mess around the edges, which is where nobody has built a tool because the input has no schema.

The data quality objection

Every supply chain conversation reaches the same point: our data is not good enough for this.

The data is usually not good. Master data has duplicates and stale records. Lead times in the system bear a loose relationship to actual lead times. Supplier records have three spellings of the same company. Units of measure are inconsistent across sites.

Here is why I think the objection is weaker than it sounds. The humans doing this work today are operating with exactly the same bad data, and they cope, by cross-referencing, by knowing that supplier X always ships two days late regardless of what the system says, and by asking someone when it does not make sense.

An agent can do the first and third of those. It can cross-reference multiple sources rather than trusting one field, and it can escalate when things do not reconcile. What it cannot do is carry the undocumented knowledge in someone's head, which is an argument for capturing that knowledge as part of the project rather than an argument against the project.

The practical bar is not clean data. It is data good enough that a competent new joiner could do the job with access to the same systems. If a new hire could learn the process in a fortnight, an agent can be built for it. If a new hire would need two years of accumulated instinct, you have a knowledge capture problem to solve first.

What the business case usually looks like

The numbers that come out of these projects, in the businesses I have seen, cluster in a recognisable range.

Supplier communication triage in a business processing a few thousand supplier messages a month typically absorbs two to four full-time equivalents. Agents handle 70 to 85% of the volume without intervention after the first quarter, which is a real saving but the more valuable effect is usually speed: a delivery date change that used to be noticed on Thursday is noticed within the hour, which changes what you can do about it.

Three-way match exception resolution has a harder financial edge, because the queue has money in it. Unresolved discrepancies are payment delays, missed early-payment discounts, and occasionally overpayments that were never caught. Clearing the queue faster has a direct working capital effect that finance can measure.

The one I would not promise is headcount reduction. In most of these deployments the team stays roughly the same size and does more, or does the same volume with less overtime and fewer escalations at month end. Whether that shows up as a saving depends entirely on how your organisation counts, and I would rather set that expectation early than have it litigated at the end.

How to start

Pick one workflow, not a platform. Supplier communication triage is the usual right answer because the volume is high, the escalation path exists, and it touches two systems rather than seven.

Take a month of real inbox traffic, including the messages that caused problems, and build against that. Run in shadow mode alongside the team for a month before it acts on anything.

Instrument the escalation reasons from day one. That log becomes the most valuable artefact of the project, because it is a precise, ranked list of exactly which data gaps and process ambiguities cost you the most, which is the input to every improvement that follows.

And resist the temptation to extend into planning. It is where the impressive slide lives and it is where these projects go wrong.

We build this kind of operations automation and we are comfortable in the unglamorous parts: EDI, PDFs, mainframes, and vendor portals with no API. If you have an exception queue that nobody has been able to automate, that is the conversation we like having.