JD Logistics applies AI agents across 1,000+ supply-chain scenarios

The Analysis

At WAIC 2026, JD Logistics put three numbers on the board. Its Super Brain 2.0 large model and its Wolf robot fleet now power AI agents across more than 1,000 supply-chain scenarios. It says it can compute optimal routing for billions of parcels inside three minutes. And it repeated a five-year plan to buy 3 million robots, 1 million unmanned vehicles and 100,000 drones. Three numbers, one sentence, and they are not the same kind of number.

That is the whole difficulty with an announcement like this one. A scenario count, a solve-time claim and a procurement target look like three points on a single exponential curve, and they are not. Each one has a different denominator, it is measuring a different thing, and each can be perfectly true while the thing you actually care about stays exactly where it was. My job here is to take them apart, so that the next time a supplier quotes one of them at you, you know which question to ask.

So model it in three pieces. The scenario count is a denominator problem. The three-minute claim is a solver problem. The procurement plan is a ramp and depreciation problem, and the ramp is the only part of it you can check with arithmetic today.

Start with the count, because it is the softest number and the one most likely to be repeated at you. More than 1,000 supply-chain scenarios. A scenario is not a defined unit. It can mean a distinct model with its own objective and its own training data, or it can mean one model deployed across a thousand warehouses and lanes, or it can mean a thousand workflow steps inside one product. All three are honest uses of the word, and they describe wildly different capabilities. Counting a thousand scenarios where one routing engine has been deployed to a thousand sites is like counting the tills in a supermarket chain and calling it a thousand checkout systems. It is not wrong. It just is not the thing the number implies.

The test I would apply, and the one that gets past the marketing, is coverage rather than count. Take your own parcel volume for one month. What share of it ran, end to end, on an automated decision path with no human touch at any step? That is a number you can compute and a number a supplier can be asked to commit to. A company can truthfully say 1,000 scenarios and still have most of its volume sitting in manual exceptions, if each of those thousand scenarios is a thin slice of the whole. Count is about the breadth of deployment. Coverage is about the depth that changes your cost, and depth is the only part you pay for.

Put a number on that coverage test so it stops being abstract. Assume a parcel passes through twelve decision points on its journey: address check, node assignment, consolidation, sortation routing, wave planning, vehicle assignment, route sequencing, exception handling, delivery scheduling, and the rest. Assume you move one million parcels a year. That is twelve million decisions a year. A claim of 1,000 automated scenarios is meaningful to you only if you can map those scenarios onto those twelve million decisions and then say what share is now automatic. If the thousand scenarios cover the ten percent of decisions that were already rule-based, you have gained almost nothing. If they cover the ninety percent that used to need a person, you have changed your cost structure. Same claim, opposite outcome, and the only way to tell them apart is to count decisions on your own volume rather than scenarios on their slide.

Ask a second question with the same energy: how many distinct models are under management, and how many distinct objective functions? One objective function reused everywhere is a small number of very mature models, which is good engineering. A hundred objective functions is a hundred optimization problems, and each of them can be wrong in its own way, and each of them has to be maintained, tested and retrained. The countable proxy for a claim like this one is not the scenario count. It is the number of distinct models, the number of distinct objectives, and the human-in-the-loop exception rate per thousand parcels. If a supplier cannot produce those three numbers, the scenario count is decoration, and you should treat it as decoration in your evaluation rather than as a capability.

Now the three minutes. This is a solver claim, and a solver claim is only meaningful when you know three things: the problem size, the constraint set and the cadence. Problem size is not the parcel count. Parcels are variables, and what drives solve time is the constraint matrix. Billions of parcels inside three minutes could be a single network-wide re-plan, or it could be three minutes per sub-problem while the network-wide plan is assembled over hours. Those are very different products. Ask which one it is, and ask it in writing.

The constraint set is the next cut. How many constraints per parcel: time windows, vehicle capacity, shift rules, cold-chain rules, dock appointments, mode restrictions? A model with four constraints per parcel and a model with forty constraints per parcel can both answer in three minutes and are not comparable at all. Constraints, not parcels, are what make routing hard, and a claim that does not state its constraint count is a claim you cannot size. Then the cadence. Does the three minutes run continuously as a rolling re-plan, or once a night as a batch? A nightly batch optimizes tomorrow's plan and is worth planning money. A rolling re-plan every few minutes optimizes resilience and is worth a lot more, and it costs a lot more in compute. Three minutes answers a question nobody asked unless you also say how often it runs and what a run costs.

There is a way to test a solver claim that does not involve reading it, and I would spend that money before I spent money on the equipment. Hand the supplier the same network twice, a clean day and a broken day. On the broken day, inject a disruption at whatever cadence they claim, and watch three things: how long until the plan re-stabilises, how much the re-plan moves parcels that were already fine, and what happens to the delivery windows you care about. A solver that recovers in three minutes but shoos half the network around to do it is not resilient, it is noisy. A solver that holds most of the plan steady and fixes the broken part is worth more than one that re-solves everything, even if it is slower. Plan stability, measured as the share of parcels whose routing does not change between two consecutive re-plans, is a number almost nobody asks for and almost everybody needs.

Here is the part the release does not say and cannot, because saying it would weaken the sentence. Optimal is undefined without an objective function. Routing is optimal for whoever wrote the objective. If the objective is the operator's network cost, then the route minimizes the operator's line-haul kilometres and hub touches, and that route can be perfectly optimal and still hand you a delivery window you did not want. The number you experience as a shipper is not solve time. It is the variance of the delivery window, and the share of parcels that arrive inside the promise. A three-minute global re-plan that quietly trades your delivery-window adherence for the operator's line-haul savings is a worse product for you than a slower plan that respects your windows. So the question is not how fast it solves. The question is what it is minimising, and whose cost sits inside the objective.

And the queue point, because it always comes back to the queue. A solver shortens decision latency. Decision latency is the bottleneck only when the physical network has slack. If the binding constraint in a facility is dock doors, or labour on the pick line, or the sortation ceiling, then a routing plan that arrives in three minutes instead of three hours does not move one extra parcel, because the parcels are not waiting on the plan. They are waiting on the door. You optimised a variable that was not the constraint, and the plan is beautiful and the dock is still jammed. I have seen this exact pattern: a team got its re-plan from hours down to minutes and shipped the same number of units for a full quarter, because the wall was on the floor, not in the solver.

Now the procurement plan, and this is where the arithmetic is actually checkable today. Three million robots, one million unmanned vehicles, one hundred thousand drones, over five years. Divide. Three million robots over five years is 600,000 a year, which is about 1,644 a day. One million unmanned vehicles over five years is 200,000 a year, about 548 a day. One hundred thousand drones over five years is 20,000 a year, about 55 a day. The ratio of the three is thirty to ten to one. So the checkable proposition is not the total. It is the commissioning rate: about 1,644 robots and 548 unmanned vehicles a day, every day, for five years.

Ask what has to be true for that rate to happen and you will find that the robots are the easy part. Every one of those units needs a floor to stand on, a charger, power at the wall, a maintenance regime, spare parts, and software that keeps three million units from fighting each other over the same aisle. The binding constraint on a five-year ramp with that slope is almost never the supply of the machines. It is site retrofit, meaning the civil work, the electrical capacity, and the standardisation of the picking faces and the tote sizes so that a robot can actually do the job, plus the maintenance labour, which is trained people, and trained people do not scale at 1,644 a day. Buying the tills does not open the store.

Then the depreciation cadence, which is the number that will eventually show up in your rate card. Assume straight-line depreciation over five years, which is my assumption and not a disclosed fact. If the units are bought evenly across the five years, then by year five the operator is carrying the full fleet's depreciation, and year-five depreciation is roughly five times year-one depreciation, even though only a fraction of the fleet earned revenue in year one. That is a real cost curve, and it lands on somebody. Either the operator's margin absorbs it, or the per-unit price you pay carries it, and in most contracts it is the second one.

Assume a unit of warehouse automation costs 20,000 dollars and depreciates over five years, so 4,000 dollars a year, and assume it handles 200,000 parcels a year. That is two cents per parcel of depreciation. If manual handling of those parcels costs fifteen cents, the gain is thirteen cents, at full utilisation. At half utilisation, depreciation per parcel doubles to four cents and the gain narrows to eleven. Automation pays when utilisation is high and sustained, and the depreciation clock does not care whether the volume showed up.

One more way to check the depreciation story, because it is the line that reaches your invoice. Do not argue about the capital number. Argue about the annualised cost of one unit against the fully loaded cost of the task it replaces. Assume the unit costs 20,000 dollars, depreciates over five years, and carries 3,000 dollars a year of maintenance, power and software licence on top, so about 7,000 dollars a year all in. Assume the task it replaces costs 45,000 dollars a year in loaded labour, being wages plus benefits plus the supervision and error rate that go with a tired human at hour nine.

The unit looks like a four-to-one win, and that is exactly the number that gets into the proposal. Now apply utilisation. At full utilisation the win holds. At a third of the utilisation, the unit's effective cost per unit of work triples and the win is gone, and the maintenance bill does not care, because a robot that works two shifts a day and a robot that works one cost almost the same to keep. Ask for the utilisation assumption in writing. It is the single number that decides whether the four-to-one survives.

For anyone on the importing and exporting side, the useful question is not how many robots the operator buys. It is which of the three segments gets automated first, and what that does to the price you pay. The logic of where automation lands is boring and reliable: it goes where sites are fixed, volume is dense, and tasks repeat. That is in-warehouse first, meaning picking, sortation and putaway. Trunk line-haul on fixed corridors comes second, because the corridor is fixed and the volume can be scheduled. Last mile comes last and narrowest, because drones carry little, fly under the tightest rules, and only make sense over dense demand. So the first thing to move inside your account is the per-piece work in a fulfilment centre: sortation peak capacity and pick cost, and the routing logic that decides which parcel goes to which chute.

And here is the thing almost nobody writes down when they read a procurement plan like this one. When a 3PL automates sortation, its unit handling cost falls. The fee you pay does not fall by itself. The gain is shared only if your contract contains a mechanism that shares it: a unit-cost line, indexed, with the automation gain defined. Without that clause, the operator keeps the productivity gain and you keep the old rate card, and you can feel very good about the relationship the whole time. Worse, the line that gets repriced is not the line that fell.

It is the exception. Right now, manual intervention on an odd parcel is bundled into the handling fee and priced at hand, and nobody notices. Once the automated line is the default, every manual touch becomes an exception, and exceptions get their own line item and their own premium. Used carefully, that is fair. Used without a cap, your invoice can rise while the operator's cost falls, and both numbers can be true at the same time.

Peak is the other trap, and it is the one that decides your year. An automated sorter has a hard ceiling and a hard floor. Below the floor it is expensive idle steel. Above the ceiling it cannot help, and peak season always sits above the ceiling, which is why operators still hire a manual surge in the two months they need it and bill it at a premium. So when you model the year, do not model the average. Model your peak-to-average ratio, because that ratio decides how much of the automation you actually pay for and how much of it you merely rent for two months. A facility with a flat year and a facility with a three-to-one peak pay completely different unit costs for the same equipment, and the equipment does not know the difference.

Timing, then. The announcement is a five-year plan, but the parts that touch you arrive on a contract clock, which is quarters. A fulfilment centre that gets an automated sort line in the next two quarters changes the variable cost of your account at the next rate review, not next week. The depreciation curve is slower than that and shows up across renewals over years. And the scenario count, honestly, may never show up in your account at all, because a scenario is an internal unit that never crosses the boundary into your invoice. What crosses the boundary is your unit price and your exception charges, and those are the two lines I would put at the top of the page.

So size it the way you would size any automation project, with every assumption marked. Pick one lane or one facility. Measure today's cost per parcel, inclusive of manual intervention. Estimate the automated cost per parcel, inclusive of the operator's new depreciation and your new exception charges. The difference times your annual volume is the gain. Divide the operator's capital by that gain to get a payback in months, and then do the whole thing again at half your peak volume, because that is the case that kills these projects. What flips the conclusion is not the technology. It is your volume density and how standard your parcels are. If your volume is thin, spiky or full of non-standard items, automation raises your effective unit cost, because you are now funding idle capacity and paying exception premiums on top of it. Dense, steady and standard is where this pays. Sparse, spiky and strange is where you subsidise it.

Before you push any of this back onto the operator, run the same screen on your own four walls, because the decision is symmetrical. If you run a warehouse, you are making the same trade the operator is making, and the same three things decide it: is the volume dense enough that the automation runs full, is the work standard enough that exceptions stay rare, and is the peak flat enough that you are not buying capacity you use for two months. Answer yes to all three and the case is easy. Answer no to any one of them and you are the one funding idle steel, whether the steel is in your building or the operator's. The technology is the same on both sides of the invoice. So is the arithmetic.

So the ask of any supplier quoting this story at you is not a demo. It is three numbers and a contract clause. The number of distinct models and objectives, so that the scenario count finally has a denominator. The exception rate per thousand parcels and the peak throughput per hour, so that the automation has a performance floor you can hold it to. And a unit-cost mechanism with a defined exception price, so that the gain has a path to reach you at all. Get those three and the numbers at the top of the release turn into something you can put in a budget. Do not get them, and you are reading a procurement plan that was never addressed to you.

↑ Back to the key points

— By Ravi Chandran