Kejie and Daka Robotics sign embodied-AI logistics partnership

The Analysis

When a warehouse automation deal is announced, I do the same thing I do with a port release: I draw the queue before I read the numbers twice. Arrivals on the left, service stations in the middle, departures on the right, and the waiting line, which is where the money actually sits. The agreement between Kejie, the smart supply-chain arm of Digital China Holdings, and Daka Robotics, signed at the 2026 World Artificial Intelligence Conference, hands me four numbers to work with. Close to 200 warehouses. About 1 million square metres. A peak of 5 million orders a day. Inventory accuracy of 99.95 percent. Multiple robots already working together on live orders at the Wuqing warehouse in Tianjin, running task generation, path planning, item recognition and picking, and sorting-cart return. And a proof of concept coming on per-item and per-warehouse robotics-as-a-service pricing.

Of those four numbers, two are scale and two are performance, and the habit of mixing them up is where budgets go to die. Two hundred warehouses and a million square metres tell you how big the estate is. They tell you nothing about whether a robot picks faster than a person in it. The peak order number and the accuracy number are the ones that could enter my model, and both of them arrive with a question attached. What is the denominator of the accuracy figure. And peak relative to what.

I am not here to sell you anybody's hardware, and I am not going to tell you which firm to call. What I want is the discipline you apply before you sign anything: which decision does this replace, what does the delay go from and to, who pays when it is wrong, how you build the comparison, and what number makes you stop. Everything else in a launch like this is a press release, and press releases are not measurement plans.

Model the warehouse first. An order arrives, becomes a wave, becomes a pick task, travels to a location, gets picked, travels to a packing bench, gets sorted, leaves. That is a chain of service stations, each with its own mean service time and its own variance, and the space between two stations is where a parcel sits doing nothing, gets mis-scanned, gets dropped, or disappears for two hours with nobody claiming it. If you have ever wondered why a parcel that lives four kilometres from the customer takes two days, the answer is almost never travel. It is waiting. Adding robots does not change that sentence. Adding robots changes the service rate at one or two of those stations, and whether that matters depends entirely on whether those stations were the constraint.

So take the scale numbers and give them their proper weight. Close to 200 warehouses across about 1 million square metres works out to roughly 5,000 square metres per site, which is a mid-sized regional warehouse, not a mega distribution centre. Assume, and this is my assumption rather than a published figure, that a robot-ready pick area is about 30 percent of a site of this kind, because aisles, packing, staging, returns and non-conforming goods take the rest. That gives you something near 300,000 square metres of addressable floor across the estate. That is the ceiling on what this could touch, and it is less than a third of the headline area. Any benefit calculation that starts from a million square metres has already lost the argument.

Now the number I would argue about most: a peak of 5 million orders a day. Peak is one end of a distribution, and it is the end that makes slides look good. What I need is the other end. Assume, purely as an illustration you should replace with your own data, that peak runs at 2.2 times the mean, which puts the mean around 2.27 million orders a day. That ratio is the single most expensive unknown in this entire proposition, because it decides how much equipment you buy and how much of it stands idle. If you size the fleet for the peak, you run at roughly 45 percent utilisation on an average day. If you size for the mean, you queue explosively on peak days, and the queue on a peak day is exactly when your customers are watching.

Here is the provisioning arithmetic, with every input flagged as mine. Assume one robot sustains 200 picks an hour in a live environment, which is a generous number for mixed SKUs, and assume 20 effective operating hours a day after charging, maintenance and changeovers, so 4,000 picks per robot per day. Assume 2.5 picks per order. At the peak of 5 million orders, that is 12.5 million picks a day, which wants about 3,125 robots. At the mean of 2.27 million orders, it is 5.68 million picks, which wants about 1,419. The gap is 1,706 machines, and that gap is the bill for peak-to-mean ratio. When a supplier quotes throughput, ask at what utilisation it was measured and over what window. A throughput number measured at 90 percent utilisation on a good day is a different product from the same number measured across a quarter.

Next, the accuracy figure, and this is the one where I slow right down. Inventory accuracy of 99.95 percent sounds like a solved problem until you ask what it is a percentage of. If the denominator is stock-keeping-unit locations, you are counting records. If it is order lines, you are counting customer-facing events, and those are not the same population. Run both, with assumptions stated. Assume the estate holds 10 million SKU-location records. At 0.05 percent error that is 5,000 mismatched records a day. Assume each mismatch touches 0.3 orders and each touched order costs 15 yuan to fix in labour, repicking and customer service.

That is 22,500 yuan a day, about 7.4 million yuan a year. Now take the other denominator. At 5 million orders and 2.5 lines each, that is 12.5 million lines a day, and 0.05 percent of that is 6,250 bad lines. Assume 8 yuan to correct a line. That is 50,000 yuan a day, around 16.5 million yuan a year. Same percentage, two denominators, a factor of two between them.

And here is the part that matters more than either calculation. Read the figure in its context: it is inventory accuracy reported for the company, which makes it a property of the existing operation and its existing systems, not a measured outcome of putting robots on the floor. A baseline that gets quoted next to an intervention will be read as a result of the intervention, by your finance team if not by you. So before the pilot starts, lock the definition in writing: what is counted, over what population, sampled how often, measured by whom, with which reconciliation method. Then re-measure after. If you cannot produce the delta under a fixed definition, you have no result, only a number that follows you around.

Look at the four steps named for the Wuqing work and ask which one is the bottleneck, because they are not equally hard. Task generation is planning and it is largely solved. Path planning for a known floor is close to solved. Returning the sorting cart is unglamorous and it is where multi-robot systems quietly seize up, because a cart that is five centimetres out of position stops a whole aisle. Item recognition and picking is the hard one. It is the step that depends on the physical world behaving, on packaging not changing, on a new SKU having a record before it arrives, on a soft bag behaving like the soft bag in the training set. In my experience the first year of these projects is not lost to the algorithm. It is lost to the catalogue.

Which brings me to the calculation I insist on before any of these go live: size the human fallback pool. Assume the grasp failure rate is 0.3 percent per attempt, which would be a good number for mixed goods. Assume 2.5 pick attempts per order, so the chance an order needs at least one human touch is roughly one minus 0.997 to the power of 2.5, about 0.75 percent. At 5 million orders a day that is 37,500 orders needing a person. Assume 40 seconds of human time per intervention, once you include walking over, diagnosing, re-picking and logging. That is 1.5 million seconds, about 417 hours of labour a day, which at eight effective hours is around 52 people per day at peak, and around 24 at the mean. That pool does not disappear because the robots work. It is the price of the tail, and it has to be in the business case as a line item with a name beside it.

Now the commercial experiment, which is the genuinely interesting part of this announcement. Per-item pricing and per-warehouse pricing are not two discounts. They are two different allocations of risk. Under per-item pricing, idle capacity sits with the supplier, which is what you want if your volume is volatile or seasonal. Under per-warehouse pricing, idle capacity sits with you, which is fine if you run a steady, predictable volume and can keep the machines busy. The proof of concept is really an attempt to find out which side of that trade you are on. Do the crossover, with my numbers. Assume a per-item price of 0.35 yuan and a per-warehouse price of 600,000 yuan a month over 30 days. The two are equal at 600,000 divided by 0.35 times 30, which is about 57,000 picks a day per site. Below that, per-item is cheaper. Above it, per-warehouse is cheaper.

Then look at where your own volume sits relative to that line and how much it moves. If a site runs 50,000 picks a day with a peak-to-mean ratio of 2.2, it spends most of the year below the crossover and a few weeks above it, and per-item pricing is the right shape for you even though the blended rate looks higher. If it runs 80,000 flat, per-warehouse wins and wins by a lot. The trap is negotiating the unit price before you know the distribution, because the unit price is the thing everybody argues about and the distribution is the thing that decides. Get twelve months of daily picks per candidate site on the table, with the seasonal shape visible, before anybody talks about rates.

Whatever pricing shape you land on, put three clauses in it and do not sign without them. A ceiling on the per-item rate during peak weeks, stated as a multiple of the base rate, because a variable cost model without a ceiling is not a variable cost model, it is an open-ended one. A minimum volume commitment, stated per site and per month, and be honest that a minimum is the price of a ceiling. And an availability obligation with teeth: if cluster availability falls below the agreed level for a stated number of consecutive days, the fee for that period is rebated, and if it stays below for a longer stated window, you may revert the site to manual operation without penalty. A service level with no remedy attached is a sentence in a contract, not a term.

The part of this announcement I would actually pay for, and it has nothing to do with robots, is the opening of OMS, WMS and TMS interfaces. Event-level data out of the systems that already run the estate is worth more than any single piece of hardware, and it is worth something whether or not a robot ever touches a carton. Instrument first: a timestamped event for order released, wave created, task assigned, pick started, pick completed, sorted, and departed, with a single clock across all three systems. If you cannot reconstruct the life of one order end to end from your own logs today, then you cannot evaluate anything, and you will end up believing whichever narrative is told most confidently.

Then the maintenance burden that kills year one. Recognition models degrade when the physical world drifts: a supplier changes a carton, a promotional bundle appears, a season brings soft packaging that behaves differently, three thousand new SKUs arrive in a quarter with no dimensions recorded. None of that is a model problem, it is a data custody problem. So assign it before the pilot, not after. One named owner for SKU master data. A service level for new SKU attributes, dimensions, weight, and a packaging image, recorded within 24 hours of a purchase order, with coverage above 99 percent measured weekly. And a versioned catalogue, so when accuracy drops you can bisect against a catalogue version instead of guessing. This is the least glamorous work in the whole programme and it is the one that decides whether year two looks like year one or like a demo.

Now the question I ask before any metric: when this is wrong, who covers it. Not what is the contingency, which commits nobody. Who provides people when a cluster goes down, and within how many hours. Who pays the customer remedy when a mis-pick ships. Who owns the order when the WMS interface drops in the middle of a wave and nobody knows which cartons have been picked. Write it down with times and amounts: a four-hour response obligation for cluster faults, a eight-hour obligation to supply manual capacity, a named owner for interface failures, and a documented manual wave procedure that the floor has actually rehearsed, not one that exists in a folder. Rehearse it once before go-live and time it, because a fallback that has never been executed is a hope.

Instrumentation, with thresholds, since a tool without a threshold is a hobby. Fully landed cost per unit fulfilled, including the fallback labour pool, measured against the control site, looking for at least 8 percent. Fallback labour hours as a share of total pick hours, capped at 12 percent, investigated at 10, and a four-week run above 12 pauses expansion. Grasp failure rate under 0.5 percent, recognition failure rate under 0.3 percent, sorting-cart return failure rate under 0.2 percent, all read daily and rolled weekly. Picks per square metre per day in the robot zone, tracked against the pre-pilot baseline. Median and 95th percentile of order-to-departure time, with the 95th percentile not allowed to run more than 10 percent worse than control. Cluster availability above 95 percent. Interface availability above 99.5 percent. Event timestamp completeness above 98 percent. And SKU attribute coverage above 99 percent with a 24-hour entry service level. If a vendor conversation does not include numbers like these, you are being sold a story.

Build the comparison as though you want an answer rather than a confirmation. Take two sites that match on SKU profile, order lines per order, daily volume band, floor area and product category, automate one, and leave the other on the current process for twelve weeks. Do not read the result until each leg has carried at least 3 million orders, and do not swap the sites halfway through because the automated one looks busy. If you cannot spare a whole site, split one warehouse into two matched zones with the same SKU mix, accept that you now have a weaker experiment, widen your intervals, and do not publish a point estimate as if it were a finding. Randomised weeks will not work here either, because your volume is seasonal and you would be comparing a promotion month with a quiet one.

Set the stop-loss while nobody is defending a decision. Four triggers: fallback labour above 12 percent of pick hours for four consecutive weeks; or landed cost per unit not at least 8 percent below control by week twelve; or the 95th percentile of order-to-departure time more than 10 percent worse than control; or a single batch mis-ship event above 500 orders. Any one pauses expansion to further sites. Two of them, or one repeated after a fix, reverts the site to manual for a quarter while a written cause analysis is produced. Expansion to additional sites waits for week twelve and releases only when landed cost, the 95th percentile time and the fallback share have all held together for four consecutive weeks.

And what could you get without buying anything, in case the capital committee says no. Three things, all cheap, all boring. Slotting: put the fastest movers in the shortest walking path, which is a data exercise on your own order lines and usually buys back a meaningful share of pick time. Wave discipline: fix wave size and release cadence instead of letting the floor release whenever, which flattens the arrival burst that creates the queue in the first place. And cart and tote standardisation, which is the single cheapest thing you can do to make an eventual robot deployment viable, because half of grasp failures trace back to containers that were never specified. Do these regardless. They pay on their own, and they are also the prerequisites that make the expensive thing work.

Where does this leave the announcement. It is a serious attempt to move embodied systems from demonstration into a replicable operating model, and the fact that multiple robots are working on live orders rather than on a staged demo is the detail worth respecting. Whether it survives contact with a real catalogue and a real peak season is not something a launch can tell you. Frame it as an experiment with a control and a stop-loss, pay for the interfaces and the master data discipline whether or not the machines arrive, and keep the fallback pool funded. Do that and you will know within a quarter whether the queue actually moved. Skip it and you will have a very fast picker in front of the longest line in the building.

↑ Back to the key points

— By Ravi Chandran