JD Logistics says AI agents now run more than 1,000 supply-chain scenarios

The Analysis

When a platform team tells me their agents now run more than a thousand supply-chain scenarios, I do not start with the number. I start with the queue it is supposed to describe. JD Logistics says its Super Brain 2.0 platform has put AI agents into more than 1,000 scenarios spanning the full supply chain: vehicle dispatch and routing, inventory allocation and replenishment forecasting, and warehouse layout and capacity balancing. Each one of those used to be a decision a person made at a screen with a clock running. Swapping a person for a model is not a branding exercise. It changes the tail behaviour of your operation, and you cannot know whether it helped unless you measured the same queue before and after the swap.

Think of it as a queue. Work arrives, it waits for a decision, the decision assigns it a vehicle or a stock position or a slot at a dock, and then it leaves. What hurts you is almost never the average. It is the ninety-fifth percentile, the handful of jobs that sit for hours because the dispatcher was on the phone, or the forecast was optimistic, or the building had nowhere to put the pallet. An agent that trims four minutes off the average while making the tail fatter will raise your complaint rate, not lower it. That is why a latency number in a platform announcement is a claim and not a result, and why my first question is always which percentile they measured and on how many days.

The figures in this story are worth taking seriously, and worth treating as unproven. More than 1,000 scenarios. More than 100 domestic drone routes, including the June 2026 village-delivery network in Zizhong, Sichuan, covering 78 administrative villages with flight times as short as seven minutes. A five-year commitment to buy 3 million robots, 1 million unmanned ground vehicles and 100,000 drones. And a heavy-payload humanoid, the Genie G2 Max built with AgiBot, now working inside JD's own goods-to-person Zhilang warehouses. I am not going to argue with any of them. I am going to say what each one would have to demonstrate before it should change how you plan your own network, and where the bottleneck will actually show up.

Start with the unit of account, because it is the softest number in the release. More than 1,000 scenarios counts places where an agent has been switched on. It does not count places where an agent has been shown to beat the thing it replaced. Those two counts can differ by an order of magnitude, and the difference is your exposure. In my book a scenario only becomes real when four things exist: a named decision, a baseline measured before the switch, a metric that moved in the right direction for more than a few weeks, and a human being who owns the result when the metric moves the wrong way. With those four, you have an asset. Without them, you have a configuration file with a nice name.

That definition has a calendar attached, and the calendar is the part nobody puts in a release. Suppose you decide a scenario is not validated until it has four weeks of clean baseline data and four weeks of post-switch data, on the same lanes, the same SKUs and the same shift pattern. That is eight weeks per scenario. Suppose further that your team can hold twenty-five of those comparisons at once, because each one needs an analyst, a dispatcher who will actually use the thing, and a control set not contaminated by a promotion. One thousand scenarios over twenty-five concurrent slots is forty waves. Forty waves at eight weeks is three hundred and twenty weeks, which is a bit over six years. Ask the honest question instead: which twenty-five do you start with, and what makes them the right twenty-five.

The three families of decision in the announcement fail in different ways, so they need different instruments. Vehicle dispatch and routing is a latency and utilisation problem. The metric that matters is not average time to plan a route. It is the ninety-fifth percentile of time from order release to vehicle assignment, and the empty-running kilometres that follow from a bad assignment. Put the acceptance line at a fifteen percent dispatcher override rate by week eight: if your people are rewriting the agent's plan more than one time in seven after two months, the plan is not earning its place. Pair that with empty-run kilometres per loaded kilometre, measured weekly, and with on-time-in-full on the treated lanes against matched control lanes.

Inventory allocation and replenishment forecasting is a bias problem, and bias is more expensive than variance. A forecast that is wrong by the same amount in the same direction every week does not look noisy, it looks stable, and it quietly rebuilds your safety stock. Track mean absolute percentage error by SKU class, but track signed bias separately, because a model that over-forecasts by six percent on A-class items will inflate inventory without ever triggering a stockout alarm. My threshold would be a ten percent relative improvement in error on A-class SKUs against your current method, measured over eight weeks, plus a hard check that inventory days did not rise while the error fell. If the forecast gets better and the stock gets bigger, you have optimised the wrong variable.

Warehouse layout and capacity balancing is a throughput problem, and throughput problems have a physical bottleneck that no amount of modelling will move. In a goods-to-person building the constraint is usually the pick station or the outbound dock, not the storage density, so a layout agent that improves slotting by eight percent while the dock is saturated has saved you nothing. Measure picks per labour hour, dock turnaround per vehicle, and the variance of daily capacity utilisation against plan. My acceptance line is simple: picks per labour hour up at least five percent with dock turnaround unchanged or better, sustained for four consecutive weeks. If dock turnaround degrades while pick rate improves, the agent has pushed work downstream, which is the oldest trick in the book.

The drone network is the part that will be quoted most and the part where the number and the decision are furthest apart. More than 100 domestic routes, and a June 2026 launch in Zizhong, Sichuan covering 78 administrative villages with flight times as short as seven minutes. Seven minutes is a flight time. It is not a delivery time, it is not a door-to-door time, and it says nothing about what happens at the landing point. The decision this technology actually replaces is narrow and specific: for a given parcel on a given day, does it fly or does it stay on the van. Everything else in the announcement is context. So the instrument has to measure that decision, not that flight.

Here is the arithmetic I would run, with every assumption written down so you can replace it with your own. Assume the Zizhong network moves 40 parcels per village per day across 78 villages, which is 3,120 parcels a day. Assume a drone sortie carries 20 parcels, so the day needs 156 sorties. Assume the sortie cycle is twenty minutes: seven minutes of flight plus thirteen minutes for loading, take-off checks, landing and handover. One hundred and fifty-six sorties at twenty minutes is 3,120 minutes, or 52 hours of sortie time. Assume one operator can supervise three aircraft at once, which gives 17.3 operator-hours a day.

Now the alternative: assume a van circuit covering the same villages takes six hours door to door and clears 260 parcels, so 3,120 parcels needs twelve circuits and 72 driver-hours. Assume a loaded driver-hour costs 40 yuan and a loaded operator-hour costs 60 yuan. The van option is 2,880 yuan a day. The drone option is about 1,040 yuan a day plus aircraft amortisation, which I am leaving out because it is a procurement question rather than an operating one. On those assumptions the operating labour difference is roughly 1,840 yuan a day, about 670,000 yuan a year.

Now break one assumption and watch the thing fall apart, because that is the whole point of writing them down. Suppose the handover at the village end takes twenty-five minutes rather than thirteen, because the landing point is a village square and someone has to walk to it. The cycle goes to thirty-two minutes, sortie time goes to 83.2 hours, operator-hours go to 27.7, and the daily labour cost goes to about 1,664 yuan. The gap against the van falls to about 1,216 yuan. Change a different assumption instead: suppose wind and visibility rule out one day in five, and on those days the van has to run anyway, so you are paying for both systems.

Add 0.2 times 2,880, which is 576 yuan a day of standby van cost, and the gap falls to about 1,264 yuan. Change both and the daily gap is about 640 yuan, which is roughly two thirds of the original saving gone. That is not an argument against drones. It is an argument against quoting seven minutes as if it were a service level.

Then there is the procurement plan, and I want to look at it from the integration side rather than the announcement side. Three million robots, one million unmanned ground vehicles, one hundred thousand drones, over five years. Divide by five and by 365 and you get about 1,644 robots, 548 ground vehicles and 55 drones every single day, weekends and holidays included, for five straight years. That is roughly 2,247 units a day entering the network. Assume each unit takes four engineer-hours to commission, register in the local telemetry and warehouse systems, and hand over to a site. That is 8,988 engineer-hours a day. Assume an engineer delivers eight productive hours a day on this work. You need about 1,124 engineers doing nothing else, continuously, for five years.

If your real commissioning capacity is a tenth of that, the maths turns against you quickly. Two thousand two hundred and forty-seven units arriving against 225 commissioned leaves about 2,022 units a day stacking up in the queue. After one quarter that is roughly 182,000 units of backlog, all of it financed, insured and occupying floor space. That is the bottleneck, and it is not the robot. It is the integration engineer, the depot's physical slot and the local grid connection. Before you commit to any procurement curve at all, compute your own commissioning throughput in units per week and put it on the same chart as the delivery curve. If the two lines cross in month four, the programme is a warehousing problem wearing a technology costume.

The humanoid deserves one paragraph, because it is the most photographed part of this and the least useful as a decision input today. The Genie G2 Max, developed with AgiBot, is a heavy-payload embodied robot working in JD's own goods-to-person Zhilang warehouses. That is the friendliest possible environment for it: flat floor, known SKUs, predictable light, no weather, no pedestrians. The claim to test is not whether it can lift. It is whether it holds a shift. Measure units moved per operating hour against a human benchmark on the same station, availability as uptime over scheduled hours, human interventions per hundred cycles, and pick accuracy. My acceptance lines would be availability above ninety percent over a rolling thirty days, fewer than three interventions per hundred cycles, and no more than a fifteen percent shortfall against the human benchmark on units per hour. Below any of those for two consecutive weeks, the unit goes back to supervised trials.

And then the question nobody likes: who covers it when the model is wrong. In every one of these deployments there has to be a named person who can stop the machine without calling a meeting. For dispatch that is the duty dispatcher, and the fallback is manual assignment with a published time penalty. For forecasting it is the planner who can override the suggested order quantity, and the fallback is the previous method held in parallel for at least one quarter. For warehouse slotting it is the shift supervisor, and the fallback is the pre-agent layout kept in a version-controlled plan. For the drone lane it is the station manager, and the fallback is the van circuit that must still exist, staffed, on the days the aircraft cannot fly. Write the fallback down and name the person. If you cannot name the person, you have not deployed a system, you have deployed a dependency.

Now the experiment design, because without a control group everything above is enthusiasm. Do not randomise across the whole network. Match. Pick treated lanes or treated villages that resemble the control set on order mix, distance band, road class and promotion exposure, then run both through the same weeks so weather and campaign effects cancel. Read the result only after at least forty paired observations per comparison, and report the difference with its spread, not just its average. Three stop-loss lines, all reversible inside one shift. One, if on-time-in-full on the treated unit runs more than two percentage points below control for two consecutive weeks, revert. Two, if the exception rate on the treated unit exceeds one and a half times control, revert. Three, if cost per parcel on the treated unit is still more than ten percent above control at week eight and the trend is flat, freeze further expansion and go back to diagnosis.

There is a smaller and cheaper version of all this that most teams skip, and it is worth doing first. Before you add an agent to a decision, measure the input data that decision runs on. If your master data on pack sizes, lead times and address geocodes is stale, the agent will learn the staleness and produce confident wrong answers at machine speed. Set a data health KPI before you set a model KPI: the percentage of orders with a usable geocode, the percentage of SKUs with a measured rather than an assumed lead time, and the lag between the latest transaction and the feature store. Thresholds: geocode usable above ninety-eight percent, feature lag under twenty-four hours, and no more than two percent of features missing on any scoring run. Fail any of those and fix the data. It is unglamorous and it usually beats tuning the model.

Agents also degrade quietly, so the programme needs a drift instrument as much as a performance one. Set a weekly check on the input distribution: the share of orders outside the distance band the model trained on, the share of SKUs that were not in the training set, and the lag between the most recent transaction and the features used for scoring. Alert when the new-SKU share exceeds ten percent, or when out-of-band orders exceed ten percent for two consecutive weeks. After any retrain, run two weeks in shadow mode where the agent scores but does not act, and promote it only if its shadow decisions beat the live ones on the same metric you used at acceptance. Retrain on a fixed quarterly cadence rather than whenever somebody remembers.

One more ratio is worth writing down, because it tells you where the weight of this programme sits. More than 100 drone routes against more than 1,000 scenarios means the aerial piece is roughly a tenth of the footprint by count. If you are a shipper reading this and wondering what to copy, that ratio is a useful brake. Most of the claimed coverage is software sitting on decisions that already exist in your business, and software is cheap to test on one lane. The aerial and robotics pieces are capital, infrastructure and airspace, and they are slow to test. Fund the cheap experiments at volume and the expensive ones at one unit per site until the numbers are in.

The alternatives deserve a fair hearing too, because handing decisions to a model is not the only lever. For the village network, a consolidated pickup point served by a van can beat aircraft on cost per parcel once you count airspace approvals, weather cancellations and the handover labour, and it has no single point of failure. For dispatch, a human-in-the-loop design where the agent proposes and the dispatcher approves gets you most of the speed benefit with none of the silent failure modes; measure the acceptance rate and treat a falling acceptance rate as a drift signal. For forecasting, a simpler statistical method with clean inputs often matches a complex one with dirty inputs. And for capacity balancing, a weekend shift or a dock appointment system can move more throughput than any slotting algorithm. Try the cheap lever first, measure it, and then decide whether you need the expensive one.

The traps are mostly about counting the wrong thing. Counting scenarios instead of decisions. Publishing a seven-minute service promise built on a flight time. Treating a single-lane result as a network result. Letting the agent train on a quiet quarter and then expecting it to behave in a peak quarter. Reading a dashboard average instead of the tail. And the one that bites hardest in a tender: quoting a performance number you cannot reproduce from raw logs. If you tell a customer your operation is faster or greener, be ready to hand over the underlying event log with timestamps. If you cannot, do not say it.

So the order of operations is the same as always: quantify first, then optimise. Take each number in an announcement like this one and convert it into a decision, a metric, a threshold and a named human being. Run the comparison for eight weeks against a matched control. If the agents are as good as the claims suggest, the data will show it inside two months and you can scale with a straight face. If they are not, you have spent eight weeks and learned exactly where your bottleneck is, which is information you needed anyway. The asymmetry is the whole argument. A measurement programme costs weeks. A rollout built on an untested claim costs years, and the queue does not care how good the slide looked.

↑ Back to the key points

— By Ravi Chandran