Supply Chain AI Shifts From Dashboards to Execution as Agentic Tools Reach Warehouses

The Analysis

The forecast round for 2026 puts agentic systems, physical systems and multipurpose robots at the centre of logistics capital, and the claims that came with it are specific enough to be worth arguing with. Suppliers are saying their software covers thirty thousand stock keeping units every day and turns out a replenishment report in eight seconds. One operation reports robots carrying roughly ten percent of the lines that move through its buildings. Around a hundred and thirty roles are said to be in the process of being replaced by software. Then the sentence that should have been the headline and usually is buried: most supply chain leaders are planning to spend more on this, and only a minority of warehouse and transport pilots fully hit what they set out to hit.

That last line is the one I would build a plan around, so let me model the whole category before we talk about any individual tool. Everything in this forecast is a queue problem wearing a new coat. A replenishment report is a job. A pick instruction is a job. A purchase order approval is a job. Each one spends most of its life waiting, and a small slice of it being worked on, and the total time an item spends in your system is wait plus work, in that order of magnitude. Software that attacks the work slice when the wait slice is nine tenths of the cycle is theatre, however impressive the demo. Before anything gets bought, measure how your own cycle splits, because that split decides what any of these tools can possibly be worth to you.

I also want to say plainly where I stand, because I get asked this a lot. I am not against any of it. Thirty thousand units reviewed daily, reports in seconds, robots on the floor, twenty four hour coverage of exceptions, all of that is genuinely valuable if it holds up on your building and your catalogue. My objection is to the order of operations. Most operations approve the budget, then go looking for a metric to justify it, then discover eighteen months later that nobody agreed what success was. The alternative is not slower, it is cheaper, and it starts with one question: what decision changes, and how will we know.

Start with the eight seconds, because it is the easiest claim in the set to take apart, and the one most likely to be quoted to you without context. Assume today a planner builds that replenishment report by hand, pulling demand, open orders, inbound and exceptions together, and assume that takes forty five minutes. Assume that once it exists, it sits in an approval loop and decisions actually get taken three working days later. Three working days at eight hours is one thousand four hundred and forty minutes. Add the report and the cycle is one thousand four hundred and eighty five minutes. Cut the report to eight seconds, which is zero point one three minutes, and you have saved roughly forty five minutes out of one thousand four hundred and eighty five. That is about three percent of the cycle.

Now run the same arithmetic against the other slack. Assume instead you leave the report alone at forty five minutes and you get the decision loop down to same day, say four hours. The cycle falls to about two hundred and forty minutes. That is roughly an eighty four percent reduction, or something like twenty eight times the benefit of the eight second version. Every input here is my assumption and you should replace each with your own stopwatch numbers, but the shape of the answer is not sensitive to them. Unless you are building that report thousands of times a day, the report is not your bottleneck. The queue behind it is. Any supplier leading with generation speed should be asked, politely and repeatedly, what they do about the approvals behind it.

There is a deeper point hiding in that arithmetic, and it is the one that decides whether this touches your balance sheet. Speed and frequency are different things. A report produced in eight seconds changes nothing about inventory if you still review once a week. What changes inventory is how often you review, because the review interval sits inside your safety stock calculation. So the honest way to price the eight seconds is to ask whether it lets you move from weekly to daily review, and then to work out what that does to your safety stock, and then to subtract what it costs you in inbound freight. Do that arithmetic before you sign, because in most networks I have looked at the freight side wins and the tool does not pay on inventory grounds at all.

Here is that calculation with every assumption stated. Take one item with a standard deviation of daily demand of eight units, assume a ninety five percent service level which gives you a z value of about one point six five, and assume supplier replenishment lead time of fourteen days. Safety stock scales with the square root of lead time plus review period. Weekly review means the square root of twenty one, which is four point five eight, giving roughly sixty units. Daily review means the square root of fifteen, which is three point eight seven, giving roughly fifty one units. You release about nine units of working capital per item.

Put a value on it. Assume the unit costs you forty dollars and carrying cost runs eighteen percent a year. Nine units is three hundred and sixty dollars of cash released once, and about sixty five dollars a year of carrying relief. Assume three thousand items out of that thirty thousand catalogue qualify for daily review at all, because the safety stock formula only behaves itself on independent, reasonably continuous demand, which excludes the slow and lumpy tail. Call the range sixty five dollars a year an item against three thousand items and you have roughly two hundred thousand dollars a year. Now assume going daily breaks your consolidation and adds five cents a unit on inbound, assume each of those items moves two thousand units a year, and you have a penalty of a hundred dollars an item, or three hundred thousand a year. Under those assumptions the eight second report loses on inventory, and the deciding factor was never the software.

Run it once more before you conclude anything, because sensitivity is the whole point of doing this out loud. Assume the same item is worth one hundred and twenty dollars instead of forty. Carrying relief becomes roughly two hundred dollars a year an item, now comfortably ahead of the hundred dollar freight penalty, and the change pays. Assume instead that your inbound already runs daily milk runs past your door, or that replenishment comes from your own regional hub rather than from suppliers, and the penalty falls toward zero while the relief stays where it was. Both scenarios are common. The result flips on assumptions you own, not on anything the supplier can tell you. So the practical instruction is dull: rank your catalogue by dollar weighted daily volatility, start with the top few hundred rather than all thirty thousand, and measure the released cash and the freight delta for ninety days before extending.

Next claim, thirty thousand stock keeping units covered daily. Coverage is a denominator, not an outcome, and this is where discussions go wrong most often. Assume the catalogue is in fact thirty thousand and assume the model flags three percent of it each day, which is nine hundred recommendations. Assume you have two replenishment planners, assume each has three genuinely usable hours after meetings and firefighting, and assume each recommendation takes twenty minutes to investigate and action. That is eighteen actions a day against nine hundred suggestions. You can action two percent of what you are given.

Two things then happen, and neither is visible in the supplier's slide. Either a backlog forms, which is an invisible second inventory of decisions nobody owns, or your planners stop reading in priority order and cherry pick whatever looks loudest that morning, which destroys the one thing a ranking model was supposed to give you. So I would write an output budget into the requirement. The system should not emit more recommendations per day than the team can actually absorb, with its best ranked items first, and if it believes there are nine hundred problems then it must tell you that, in one number, rather than quietly flooding a queue. Ask also for the dollar value captured per recommendation rather than the count, because fifty cheap suggestions and five expensive ones are not the same product.

And check the denominator before you trust the thirty thousand. Assume thirty thousand items are covered, then ask what share of those have verified weight, dimensions, barcode and pack hierarchy in your master data, because the model is only as real as that table. Assume twelve percent of yours is stale. On those items it is recommending against fiction, and no amount of model quality fixes it. I would treat master data completeness as a gating condition, not a nice to have, with a stated target like ninety eight percent of active units having verified dimensions before go live, and I would not start the clock until that is true.

Now the robots, at roughly ten percent of lines in the operation that reported it. Ten percent of average is not ten percent of your problem, because what costs you money is the peak. Assume peak to average demand ratio of two point two, which is ordinary for a distribution centre serving retail. A resource carrying ten percent of average lines is carrying under five percent of peak lines unless you have deliberately buffered it, and the peak is where overtime, missed carrier cut offs and service failures live. So the useful question is not how many lines it does but how much of your peak it absorbs, and I would set that as a reported metric from week one.

Build the labour ledger properly, with waste in it. Assume a building doing forty thousand lines a day. Ten percent is four thousand lines on machines. Assume your manual rate including walk and pack is one hundred and twenty lines an hour, which is thirty three hours of direct labour avoided in theory. Assume an intervention rate of three percent on automated lines, which I think is optimistic for mixed case handling, at four minutes each to clear. That is one hundred and twenty interventions a day and eight hours of recovery labour. Net recoverable is now about twenty five hours, not thirty three. Assume you can only convert sixty percent into real headcount change because shifts come in blocks and you cannot remove twenty five hours from a roster cleanly, and you have fifteen hours a day. Assume thirty dollars an hour fully loaded and two hundred and fifty operating days. Call it one hundred and fourteen thousand dollars a year.

I am not going to invent a robot price, because I do not have one and a fabricated one would poison the rest of this. Invert it again. Any all in annual cost below about one hundred and fourteen thousand dollars pays back inside a year on labour alone. If the real figure is several times that, and it usually is, then either you need far more than ten percent of lines to make the arithmetic close, or the justification has to come from somewhere other than headcount. The honest somewhere is the peak. Assume peak runs ten weeks a year, assume missed cut offs currently hit four tenths of one percent of orders during it, assume each late shipment costs you twenty two dollars in credits and reshipment.

At forty thousand lines a day that is a hundred and sixty orders daily and something like three and a half thousand dollars a day through the peak, or around seventy thousand dollars a season. All assumptions, all replaceable, but note the shape: the value sits in the weeks you are already bleeding, not in the months you are comfortable.

Then note what happens to the work that stays human. Automate the easy ninety percent of lines and the residual ten percent is the ugly one, the damaged, the unscannable, the awkward dimensions, handled by people who now need more judgement, not less. Cost per remaining labour hour goes up even as hours come down, and if your budget assumed a flat rate you will miss your own target. Track fully loaded cost per shipped line rather than picks per hour, including every minute spent clearing machine exceptions, because that single metric is the only one I trust to survive an argument with a finance director.

Physical systems need extra attention because they fail differently from software, and here I am going to be blunt about it. Software can be reverted. A robot cannot be rolled back to yesterday. Ask for availability defined in writing, with the exclusions stated, because availability excluding planned maintenance and excluding downtime attributed to environment excludes almost everything that actually goes wrong on a floor. Ask for mean time between failures and mean time to repair at the fiftieth and ninetieth percentile, measured on your site with your mix. Ask for spare part lead times and the count of your own technicians who can clear each fault class, because a single person who can fix a thing is a single point of failure with a holiday entitlement.

Multipurpose robots deserve one specific caveat. Flexibility is bought with complexity, and complexity is paid for in failure modes, spare parts variety, and training. A single purpose machine has one dependency chain, and its failure modes are known within six weeks. A robot that can pick, palletise and decant has three times the end effectors, three times the safety cases and, in my experience, a maintenance burden that grows faster than the capability does. That trade can still be right, particularly where volumes do not justify dedicated equipment, but price it as three sorts of risk, not one: failure rate, repair time, and how many people you can afford to keep trained.

Then the piece of the forecast people quote least and should quote most: most leaders plan to spend more, and only a minority of warehouse and transport pilots fully hit their targets. Here is my reading, and I will flag it as my reading rather than as something the report said. A pilot cannot miss a target it never wrote down. In my experience a large share of that minority were never measurable to begin with, because success was described as improved visibility or better decisions rather than a number with a date against it. Fixing that costs nothing and improves returns more than any technology choice in this forecast.

Write targets before you start, in one line each, structured as metric, threshold, date, owner, and what happens if it is missed. Cost per shipped line down eight percent by the end of the pilot. Ninetieth percentile order cycle time down fifteen percent. Automation availability above ninety two percent excluding agreed windows. Each one pre registered, meaning written and dated before any results exist, because a threshold set after you have seen the data is not a threshold, it is a rationalisation. Then size the portfolio against your own success rate. Assume yours is thirty percent, replace it with your actual history when you have it, assume a winner pays three times its cost and a loser writes off. Expected value per pilot is thin and positive if you are honest, and dramatically better if you can kill a loser at a quarter of its spend, which is why stage gates matter more than selection.

Concretely, I would cap any single pilot at fifteen percent of the annual budget for this category, run no more than four concurrently, and require each to clear two gates before the next tranche: first a technical gate on the metrics that actually define output above, second an operational gate where the floor supervisor and the finance owner both sign that the manual path is still available and that the measured metric moved. Anything that cannot clear a gate stops, and the writing off is not a failure of the project, it is the project working.

Evaluation design needs the same care. Do not put your fastest moving, easiest units on automation and compare them against slow, awkward human picked units, because you will conclude whatever you like. Allocate at the order level where you can, or alternate zones or shifts every two weeks, and match comparable stock keeping units by velocity and handling characteristics. Run for at least eight weeks so you cover a full return cycle and one demand peak, and keep every other change out of the window. In particular do not run a re slotting project, a new labelling process and a learning management rollout in the same eight weeks, because you will not be able to say which effect belonged to which, and the review will be an argument rather than a result.

Then the question that never gets asked until it is too late: when the thing is wrong, who catches it, how quickly, and with what authority. For physical automation the answer has to be a named floor supervisor per shift with authority to stop the line, a stated time to switch back to manual operations, and a manual layout that still exists rather than having been dismantled to make room. Practice it. Once a month during the pilot, pull the automation for two hours without warning beyond the two people running the test, and score whether orders still shipped on time and what it cost you per line. If the answer is that everyone coped because it was a quiet Tuesday, run it on a Thursday before a long weekend, which is when it will actually happen to you.

Write the stop lines down where people can see them. Fully loaded cost per shipped line above the manual baseline for two consecutive months. Availability below ninety percent for a month. Intervention rate above five percent of lines on a rolling four week basis. Any safety incident involving the equipment, at which point pause immediately rather than at month end. Each one has a named owner, an action, and a review date, and none of them requires permission from the people who sponsored the project in order to trigger, because the sponsor is precisely the person who will want to keep going.

On the commercial side I have no interest in whose name is on the invoice, and nothing here should be read as recommending anybody. What I care about is where the measurement obligation sits. Insist on acceptance testing performed on your units, your mix, your shift pattern, with pass levels written before the test. Pin software versions and require notice plus a re evaluation window when anything changes, because a silent model update invalidates everything you measured last quarter. Require the full event log, every recommendation, every intervention, every stop, exported in a format you own and at a frequency you choose. And settle the exit before the entry: what happens to the equipment at contract end, what it costs to de install, who owns the process knowledge you built into the configuration, and how long the manual mode has to survive after go live.

None of this is hostility. This category has earned its place in capital plans, and the specific numbers in the forecast, thirty thousand units a day, reports in seconds, machines carrying real line volume, describe capabilities that did not exist at any price ten years ago. But they were measured somewhere else, on somebody else's catalogue, against somebody else's baseline, in their building. Move the measurement onto your floor and a lot of the gloss comes off. What is left is usually still worth doing, and it is worth doing for reasons you can defend in a meeting where nobody is feeling generous. Quantify first, then optimise. Draw yourself a picture of the queue before somebody offers to make it faster, because if the queue is not your bottleneck, faster is not cheaper, it is just quicker.

↑ Back to the key points

— By Ravi Chandran