Supply Chain Action Points
Read this first — the conclusion, and the moves to make:
- By 31 July 2026, instrument the inbound node rather than the robot: timestamp, carton ID and robot ID on every handling cycle, from which you compute mean cycle time, its standard deviation and the ninety-fifth percentile.
- Track buffer fill level and buffer time-to-empty on the same dashboard as throughput, and set the alert on time-to-empty below ten minutes, because that is the point at which a picker starves.
- Set the fleet duty cycle floor at eighty-five percent over a full day; if a unit falls below it, add a standby robot rather than extra shifts, and re-check after one full charge-and-swap cycle.
- Run the humanoid against the alternative on one line for a quarter: log picker starvation minutes per shift and inbound cycle-time variance, and if the site's cartons are standardised, price a fixed depalletizer against it before scaling.
JD Logistics and AgiBot (Zhiyuan) unveiled the 精灵G2 Max, an industrial-grade humanoid robot deployed in JD's 'ZhiLang' (smart-wolf) goods-to-person warehouse—the first humanoid robot put to work in a real warehousing production scenario. The dual-arm, force-controlled robot handles case picking, handling and palletizing around the clock, linking the inbound stage to JD's automated outflow.
The Analysis
Before we talk about the robot, let's model the problem, because the robot is not the interesting part. JD Logistics and AgiBot have put the Jingling G2 Max, an industrial-grade humanoid robot, to work inside JD's ZhiLang goods-to-person warehouse, and it is the first humanoid actually working in a live warehousing production scenario. It has two force-controlled arms, it does case picking, handling and palletizing around the clock, and it sits at the inbound stage, feeding an outflow that was already automated.
Read that last clause twice. Outbound was already solved. The robot is filling the one node that was still human. So this is not a story about robots getting smarter, and it is not a story about a warehouse getting bigger. It is a story about where the bottleneck moved. Strip the humanoid out and ask the system question: in a goods-to-person warehouse, what actually limits throughput?
A goods-to-person warehouse is a queue with a service discipline. Orders arrive, and the system locates the item, which JD says takes under five seconds in a ZhiLang warehouse holding more than a million SKUs. A retrieval robot takes the tote off racks taller than ten metres, a transport robot carries it, and the goods reach the picking station in about a minute. Storage density runs about four times a conventional warehouse. Now bolt inbound onto the front of that pipeline. Cases come off a truck, and they have to be depalletized, picked and palletized onto the flow that feeds the racks. That is the node that was still manual, and that is the node the humanoid has taken.
Why a humanoid rather than a fixed machine, and why now. Fixed automation wins on repetitive, standardised motion, and a conventional depalletizer beats any arm at one carton size, all day. But inbound is the least standardised node in the building. Carton sizes vary, pallet patterns vary, load quality varies. A fixed machine needs the world to conform to it; a humanoid is a machine built to tolerate the world as it is. Force control is the technical unlock, because it lets an arm pick up a case without crushing it or dropping it. JD already runs a robot matrix across storing, picking, moving and conveying under a central planning model it calls Super Brain 2.0, and the humanoid is the unit that reaches the step the rest of the matrix could not physically touch.
Two layers of impact, and the first one is counter-intuitive. Automating inbound removes a manual buffer, and a buffer is a shock absorber. The outbound side already delivers in about a minute, which is a very short pipe. Little's Law, which says work-in-process equals arrival rate times flow time, gives the size of that pipe: if the station has to run nine hundred order-lines an hour with a one-minute flow time, the pipeline holds fifteen order-lines. Fifteen. A pipe that thin has almost no slack, so an inbound hiccup is now visible at the picking station within about a minute, where previously a human inbound crew was itself the absorbent layer.
Automating a buffer is not the same as deleting variance. It changes who owns the variance. The other layer is fit: a warehouse with a million SKUs and four-times storage density has the volume to amortise a robot fleet, while a warehouse with a thousand SKUs and uniform cartons should not buy a humanoid, because a fixed depalletizer is cheaper per case and has fewer failure modes. The business case is a function of variety, not of wage rates.
Timing. This is live now, and ZhiLang is already deployed at scale in Beijing, Wuhan, Chengdu and the UK, so the deployment reality is here. The throughput reality is a quarter of data away. You need a full charge-and-swap cycle, a full shift rotation and at least one peak week before effective robot-hours per day are a number rather than a hope. The wider fleet plan, three million robots, a million unmanned vehicles and a hundred thousand drones over five years, is a procurement target, not capacity. Read it as a signal about where JD expects the labour constraint to sit, not as a rate you can plan against.
This is the piece the coverage skipped. Everyone is comparing the robot to a human on speed, and that comparison answers the wrong question. In a queue, waiting time depends on two things: how heavily loaded the server is, and how much the service time varies. A human inbound crew is slower on average, but it is also irregular, because of fatigue, shift change and badly stacked pallets, and variance is what makes queues long. The real contribution of a force-controlled robot is not a higher mean rate. It is a lower variance in inbound cycle time, and on a thin pipe, cutting variance shortens the queue faster than raising the average would. So the number that decides whether this scales is not cases per hour. It is the coefficient of variation of the inbound cycle time, and the duty cycle of the fleet, which is uptime minus charge and swap time.
Which gives a tool plan, and it is deliberately unglamorous. Instrument the inbound node rather than the robot: log every handling cycle with a timestamp, a carton identifier and a robot identifier, then compute the mean, the standard deviation and the ninety-fifth percentile of cycle time. Track two system variables continuously, buffer fill level and buffer time-to-empty. Set the alerts on time-to-empty, not on throughput, because a picker starves long before an average rate looks bad. Hold the line at a duty cycle of eighty-five percent: below that, the robot is not shrinking the buffer, it is adding a fixed cost and a new failure mode to it, and the honest answer is a standby unit rather than a bigger fleet. Measure the effect on the picker as starvation minutes per shift, because that is the number the queue actually cares about.
Quantify it, assumptions explicit. Assume one robot needs four working minutes per case and runs a duty cycle of eighty-five percent across a twenty-four-hour day of one thousand four hundred and forty minutes. Productive minutes per robot per day are about one thousand two hundred and twenty-four, which at four minutes a case is roughly three hundred and six cases per robot per day. Assume the inbound node needs nine hundred cases a day to keep the racks fed. That is three robots with one of them reserved as standby, because three units at three hundred and six capacity each leave almost no margin and no redundancy. Then the buffer: at nine hundred order-lines an hour and a one-minute flow time, the pipeline holds fifteen order-lines, so fifteen units is the entire cushion between a flat pick rate and a starving station. Fifteen, not three hundred and six, is the number for the dashboard.
The usual mistake is to buy the robot and then measure it the obvious way. Cases per hour will look acceptable and tell you nothing, because the queue does not care about the mean. A fleet that posts a great average and empties the buffer at every shift change has moved the problem, not solved it. A fleet that keeps the buffer above forty percent at the ninety-fifth percentile is doing its job even if its average speed is unimpressive. It is a queueing problem. It always was.
↑ Back to the key points