The expertise that corrects your planning system has never been written down. By Will Dutton
Manufacturing has had an answer to volatility for the better part of two decades, and it was a rational one. Cheaper global supply was bought with stock. US Census data shows manufacturing inventory cover rising from roughly 35 days at its 2005 trough to nearer 45 days now, a considerable commitment of working capital to the business of absorbing uncertainty.
What the same period did not deliver was productivity. BLS figures put US manufacturing productivity growth at approximately 0.5 percent since late 2019 against around 2.1 percent for the wider economy, so the sector has been improving at roughly a quarter of the pace of the economy around it while carrying materially more stock than it once did. That is the most important fact in the present debate about AI in manufacturing, because it establishes, before any technology is discussed, that the constraint was never a shortage of buffer. Extra stock protects a business inside a network whose lead times it can plan around. It does very little when the network itself is being rebuilt underneath it.
The systems were built for one configuration
So, what happens to the systems running planning? They were built on the opposite assumption, which was not a mistake at the time. ERP and planning platforms were designed to hold one agreed version of the truth and to make change deliberate, traceable and owned, and every auditor, customer and finance director still requires exactly that. The practical consequence is that these systems remain rigid, in that they are configured around one network and changing them is a project rather than an adjustment, and they remain largely untrusted, because the people using them cannot see the logic behind a recommendation and therefore override it, frequently for good reasons.
That second failure is not a change-management problem to be trained away. A planner who overrides a recommendation they cannot interrogate is behaving sensibly rather than obstructively, and every one of those overrides is a piece of real business judgment the system did not hold. It is lost for a mechanical reason rather than a cultural one: the judgment exists as a sentence, and until recently nothing in the stack could act on a sentence. Business logic had to arrive as code or configuration, which meant a developer, a release and a delay, so the planner adjusted the number by hand and moved on.
That is the constraint that has now lifted, and it is where the technology earns its place.
What agents do that planning systems cannot
Two kinds of thing need to reach the plan, and neither sits in a data warehouse. The first arrives from outside, and most of it is simply text: the supplier email confirming a three-week slip, the scanned certificate of analysis, the carrier notification, the contract clause nobody has read since signature. An agent reads it, works out which product and which location it bears on, and turns it into something the plan can use, which means a change to a demand or supply driver with a confidence attached and the source still visible behind it. That is the work planners have always done by hand, at whatever hour the email arrived.
The second is more valuable, and it governs what happens next. It is what a planning team already knows and has never told the system. Raise safety stock on frozen lines ahead of a promotion everybody knows is coming, rather than waiting for the forecast to catch up. Trim the buffer on short shelf-life dairy, because wastage there costs more than a stock-out. Lower the minimum on a line once a supplier’s lead time has genuinely improved. Each of those is a sentence, and a planner can now write it into the system in plain English, where it becomes the instruction the agents work to, rather than a note about how the system ought to behave. People write and amend it; agents act on it.
Agents working to rules your team has written
The loop that follows is where the value sits. The agent takes the signal it has read, checks it against the rules the team has written, calls the forecast and the optimizer to work out what the options actually are, and then either acts or does not. Where the answer falls inside the written rules, it redraws the plan and drafts the replenishment or the order for approval, naming the rule it relied on so the planner can see the reasoning rather than infer it. Where it falls outside, it escalates, with the trade-off already evaluated and the scenarios attached, so the person receiving it is deciding rather than starting an investigation. And when that person decides something the rules did not anticipate, the sentence they write becomes part of the instruction set, which is how an override stops being a loss and becomes an input.
One written rule, applied everywhere
Writing a rule down once has a second effect that is easy to miss. It stops being one planner’s practice and becomes the team’s, applied identically on every line and in every region by every agent that touches the decision, whether the person who first worked it out is at their desk or not. That is the scaling mechanism, and it is a different proposition from training people, because the knowledge no longer degrades when someone moves role or leaves. It also travels sideways, since the same written rule about defending price in a particular region can govern a quote as well as a replenishment decision, which stops planning and commercial teams maintaining separate and quietly contradictory versions of the same commercial logic. And because every rule carries an owner, a version and a date, a change to how the business decides is visible as a decision somebody made, rather than an adjustment buried in a configuration file and discovered 18 months later by whoever inherits it.
The mathematics matters more, not less
Once a planner stops overriding the system, the mathematics is no longer being quietly corrected by a person before anything happens, which raises the premium on getting it right rather than lowering it. An agent does not compute the answer, it assembles the question and hands it to the engine that can, then applies the written preferences to choose among options that are already feasible. No quantity of context will make an infeasible plan feasible or a poor forecast accurate, and a well-governed rule applied to a weak forecast produces the wrong answer more consistently, and with better documentation.
Planning is also not one question but several, each needing a different kind of mathematics: what will be demanded and with what uncertainty, what to hold and where and in what form, and what is actually feasible against real capacity and materials. Language models supply none of that. They are strong on reach and on context, and weak on precisely what planning needs most, being unable to offer calibrated probabilities, plans guaranteed to be feasible, consistency between runs, or any dependable sense of when they are wrong. The workable architecture is therefore layered rather than unified: specialist forecasting, optimization and simulation for mathematical depth, agents for reach and context, and orchestration to carry an approved decision out to the systems, suppliers and teams that have to act on it.
What is worth measuring
These are capital decisions wearing operational clothing, since forecast error surfaces as service, realized price feeds return on sales and stock is working capital. Which is why the number of agents deployed will be a poor measure of progress. The better questions are how quickly a structural shift in demand becomes a changed plan, how much of that happens without waiting in a queue, and how often a planner still overrides the system, and when they do, whether anyone can see which rule the agent relied on. The question for a manufacturing leader is not whether the mathematics is good enough, it is how much of what the business already knows has been written down, and how quickly any of it can be changed when the network moves again.
Will Dutton
www.uipath.com
Will Dutton is Supply Chain Solutions Director at UiPath, a leader in business orchestration and automation. It is trusted by organizations worldwide to transform enterprise complexity into intelligent, secure operations where AI agents reason, robots act, and people lead. Built for the modern enterprise and the world’s most regulated industries, UiPath integrates automation, orchestration, AI, and testing into governed, scalable workflows – unlocking innovation at the speed of business while delivering the controls and compliance enterprise leaders’ demand.
