RCS task priority was a non-issue in the era of small fleets. With a dozen robots, first-come-first-served worked well enough: a low battery meant go charge, and a rush order could be inserted by hand without breaking anything. But once a fleet crosses a certain threshold, scheduling stops being dispatch and becomes a genuine trade-off. Wave tasks need throughput, rush orders need lead time, and charging needs the fleet to stay online — and all three compete for the same robots. The RCS, the robot control system sitting between the WMS and the fleet, spends every day allocating capacity across these three task types.
Once the Fleet Scales, RCS Task Priority Becomes a Real Problem
Start with the data. According to Interact Analysis, cumulative shipments of mobile robots were approaching 2.1 million units by the end of 2025, representing roughly $18 billion in revenue, while the number of customer sites deploying mobile robots grew from just over 9,000 in 2020 to more than 53,000. The industry's story over the past five years has been the move from "a few dozen robots on pilot" to "a fleet as an operating unit."
Yet the same firm downgraded its outlook in a mid-2025 update: it cut the year's AMR forecast by $800 million, trimmed the five-year compound growth rate from 26% to 21%, and lowered the 2030 revenue projection to $15.6 billion, citing tariff disruption and a wait-and-see mood in customer capital spending. The downgrade is worth pausing over. It does not mean the scheduling problem is getting smaller — quite the opposite. In years when expansion slows, operators squeeze more utilization out of the fleets they already have, and the higher the utilization, the sharper the conflict between task types.
A second signal comes from Amazon. In June 2025 the company announced its one-millionth robot deployment, spanning more than 300 facilities, alongside DeepFleet, a generative AI model built to coordinate robot movement, which the company says can improve robot travel efficiency by 10%. That figure is a vendor claim, not an independently verified measurement, and the distinction matters. But the direction is clear: when the coordination target grows from dozens of machines to a million, scheduling can no longer be "rules written in stone." It has to become something the system learns.
A Real Dilemma: When Rush Orders Steal the Wave's Robots
Ahead of the 2024 peak season, an e-commerce fulfillment warehouse in the southwestern United States ran into the textbook case. On the night of a major promotion, rush orders poured in, and the RCS switched on preemptive priority: high-priority rush tasks could interrupt lower-priority wave tasks in progress and pull the robots away.
The cutoff was saved, and that night's rush orders shipped more or less on time. The price showed up in the second half of the night. Interrupted wave tasks kept getting deferred, the following waves all slipped, and at one point the pick stations sat idle with robots waiting for goods that had not arrived — the vehicles were waiting on the work, not the other way around.
The case illustrates a fact that is easy to miss: preemption is not free. It does not eliminate delay; it relocates it, moving the cost from rush orders onto wave tasks in a different form. A priority policy is, at its core, a decision about who bears the system's congestion cost.
Three RCS Task Priority Strategies: A Scheduling Trade-off Framework
In practice, the industry's approaches to the three-way conflict fall into three broad strategies, each with its own costs:
| Strategy | Logic | Best fit | Cost |
|---|---|---|---|
| Static priority | Fixed ranking, e.g., rush > wave > charging | Small fleets, homogeneous task mix | Waves starve when rush orders are frequent; charging is systematically neglected |
| Weighted scoring | Each task type is scored dynamically on wait time, due-time pressure, and vehicle state; the highest score goes first | Mixed tasks, volatile load | Weights need continuous recalibration; tuning is expensive and drift degrades performance |
| Preemptive with safeguards | Rush orders may preempt, but wave tasks keep a guaranteed minimum share; charging is reserved in windows | Large fleets, peak season | Most complex to implement; requires forecasting fleet state and task arrivals |
None of them is the standard answer. My observation is that most mature fleets run a variant of the third: preemption is allowed, but the preempted side gets starvation protection — for example, a wave task automatically escalates in priority after being deferred a set number of times. The point is not which strategy to pick but whether the operation accepts the premise that any static rule will fail under some load, and that the policy itself needs feedback.
The Counterintuitive One: Charging Is the Hidden Throughput Variable
Of the three task types, charging is the easiest to underestimate. The intuition says charging produces no orders, so it should rank last. One warehouse followed that intuition and set charging priority to the minimum, letting only robots below a battery threshold go charge.
Then, on a peak-season night, a large share of the fleet hit the threshold at nearly the same time. A queue formed at the charging stations, fleet availability fell off a cliff in the early hours, and the site's throughput went down with it. The engineers' fix was counterintuitive: they raised the priority of charging tasks and moved to fragmented opportunity charging — topping up between tasks whenever a robot happened to pass a charger — combined with concentrated charging windows during off-peak hours. The availability curve flattened, and the system became more stable, not less.
The trade-off is worth unpacking. The real cost of a charging task is not electricity. It is vehicles going offline at the wrong time, together. In a high-utilization fleet, charging is a precondition for throughput, not an afterthought. Treating it as a "whenever there's time" low-priority task plants a time bomb in the schedule.
Why the Three Task Types Conflict by Design
The conflict is structural, not managerial. The three task types live on three different time scales: wave tasks are planned by the hour and highly predictable; rush orders arrive by the minute and are essentially unpredictable; charging is governed by battery curves and the physical count of chargers, which makes it a constraint-satisfaction problem at heart.
One layer deeper, their objective functions were never aligned. Wave tasks want to maximize throughput, rush orders want to minimize latency, and charging wants to maximize fleet availability. Every day, the RCS performs an online trade-off across all three objectives, and any rule that optimizes a single one — "always prioritize rush orders," for instance — pays for it on the other two dimensions. This is also why the bigger the fleet, the faster hand-written rules run out of road.
Trend Judgment: RCS Task Priority Is Moving From Rule Engines to Learning-Based Optimization
Putting the data and the cases together, my judgment is that over the next three to five years, mainstream RCS scheduling will shift from "humans write rules and tune parameters" to "train in simulation, infer online" learning-based optimization. Three reasons: first, fleet scale — 2.1 million cumulative units across 53,000 sites — has already made manual tuning unsustainable; second, practices like Amazon's DeepFleet show that leading operators are replacing rules with models for fleet-level coordination; third, mature digital-twin simulation lets a policy rehearse thousands of peak seasons in a virtual fleet before it ever touches a real one.
The judgment has a precondition, though. Learning-based scheduling needs high-quality operational data as fuel, and most warehouses' data governance is still at the "good enough" stage. The algorithm is not the bottleneck. The data is.
Which leaves an open question. When the scheduling policy itself becomes a system that learns, does the warehouse operations team still need to keep a hand on manual priority override? And if so, at what granularity — tuning a few weight parameters, or seizing control of an individual robot in an emergency? There is no standard answer yet, but the answer will likely shape what the next generation of RCS products looks like.
By Dr. Chen, Supply Chain Researcher
