Supply Chain Action Points
Read this first — the conclusion, and the moves to make:
- Measure picks per robot-hour in one zone for 4 weeks before any fleet expansion, and set the expansion trigger so that adding units is approved only while the marginal picks-per-robot-hour stays flat or rises.
- Split your handling work into deterministic loops and exception work, and target the loops first: aim to automate 80 percent of the repetitive cart-return and intake volume within two quarters.
- Write the data clause before signing: who owns the pick and exception data, where it is stored, and whether you keep a copy when the contract ends.
- Staff the exception queue explicitly: name who owns robot faults on the night shift and set a target that no exception ages past 2 hours without a human decision.
- Pilot on a steady, standardised zone, not your messiest one, and hold the rollout until picks per robot-hour has held for 6 consecutive weeks.
At WAIC 2026, China Investment (Kejet) and Daka Robotics showcased a multi-robot embodied-intelligence cluster operating live in Kejet's Tianjin Wuqing warehouse, completing order intake, path planning, picking and sorting-cart return. Kejet opened nearly 200 warehouses (≈1 million sqm, 5 million daily order peak) as a real-world training and deployment ground.
The Analysis
A robot cluster just ran a live shift, not a stage demo. At WAIC 2026, China Investment's Kejet and Daka Robotics showed a multi-robot embodied-intelligence cluster working inside Kejet's Tianjin Wuqing warehouse, completing order intake, path planning, picking and sorting-cart return end to end. Kejet opened nearly 200 warehouses, about one million square metres and a five-million-order daily peak, as a real-world training and deployment ground.
Read that last part twice. The interesting sentence is not the robots. It is the warehouses being opened as a training ground, because that is the part that changes the unit economics.
Think of the warehouse as a queue, and a robot as a server in that queue. One robot doing one task in a demo is a parlour trick. The number that matters is throughput per hour across the whole fleet, and throughput is set by coordination, not by the speed of any single arm.
Start with what a cluster is, technically. A cluster means the robots schedule against each other, share one map, and negotiate the same aisle and the same charging window. That is the hard part. One robot picking a known item in a fixed cell is a solved demo. Twenty robots in one aisle is a deadlock problem, a charging-queue problem and a handoff problem, and the failure mode is ugly: throughput does not degrade gently, it collapses, because robots block each other and then all wait on the one cart everyone needs. So the product here is the orchestration layer, the scheduler, not the hardware. Read the news that way and the live demonstration is a signal about the software, and the 200 warehouses are the data supply that software needs.
Why now. Embodied intelligence has been stuck at the demo boundary for years, and that boundary is not dexterity. It is exposure. A model trained on a curated shelf learns a curated shelf. Real warehouses are messy: mixed cartons, damaged cases, an order nobody expected, a pallet in the wrong lane. The fastest way to close that gap is to put the robots in front of real mess, at real volume, and capture what breaks. One million square metres and a five-million-order peak is not a showcase, it is a capture rig. That is the honest read of opening 200 warehouses.
Who feels it first. High-volume, standardised, repeatable handling moves first: intake, path planning, cart return, the repetitive loops with a known item and a known destination. Low-volume, high-variability, exception-heavy work moves last, because that is where the model has the least data and the human has the most. So an e-commerce fulfilment operator running standard categories on tight cycles is the early buyer, and a third-party logistics provider whose day is built on non-standard freight and custom handling is the late one. The volume threshold is the real question. Compute your own orders per day per zone, and compare it with the point where coordination overhead eats the labour saving.
Timing is measured in seasons, not weeks. Coordination software improves with data, and data arrives one shift at a time. The first wins are the deterministic loops, maybe inside two or three quarters; exception handling is a longer road. Plan for a mixed fleet for a while, humans and robots on the same floor, because that transition is where the real cost lives. Budget for the overhead of running two controllers at once, a warehouse system and a fleet scheduler that must agree on the same slot, and expect the first version to be slower than the person it replaces before it is faster. That dip is normal, and a pilot that skips the dip is a pilot that never proved anything.
Here is what the headline leaves out. The cluster is only as good as the data pipeline behind it, and the warehouse has quietly become a sensor. Every pick, every deadlock, every cart return is training data, and that raises two questions nobody puts on the slide. One, who owns that data and where does it live. Two, what is the human's job when the robot is wrong at three in the morning and the exception queue is longer than the day. A cluster that automates the easy 80 percent does not remove the hard 20 percent, it concentrates it, and concentrated exceptions need a person with the authority to break the loop.
Quantify before you deploy. Assume a zone that runs 100,000 picks a day with 40 pickers on a two-shift rotation, and a fleet that lifts throughput 30 percent. That is 30,000 picks a day of added capacity, about 12 pickers of equivalent output. But the fleet only pays if coordination overhead stays under that margin, so watch the number that decides everything: picks per robot-hour, not robots installed. If it climbs, add units. If it flatlines as you add robots, you have hit the coordination ceiling, and more hardware makes it worse, not better.
The counter-case is a warehouse with lumpy demand and a wide SKU spread. There, the coordination layer spends its capacity waiting, and the same fleet that shines on steady volume sits idle at peak and off-peak alike. Volume stability, not volume, is the hidden variable. Change it and the whole case flips.
↑ Back to the key points