Routing a single autonomous mobile robot across a warehouse floor is a solved problem. Coordinating a hundred of them at once is not. Multi-agent AMR fleet scheduling is the discipline of assigning a continuously changing stream of tasks to a group of mobile executors that keep getting in each other's way — deciding who picks up which task, which route each robot takes, and who yields at every intersection. It is as much an organizational problem as an algorithmic one.
The phenomenon: scheduling problems grow with fleet size
AMR deployment density has changed stepwise over the past decade. Amazon's $775 million acquisition of Kiva Systems in 2012 is widely regarded as the starting point; by 2024, Amazon disclosed a warehouse robot fleet surpassing 700,000 units, and vendors such as Geek+ and Hikrobot now routinely deliver single-facility deployments with hundreds of robots. As robots move from "a handful of pilots" to "a fleet," scheduling graduates from a single-robot navigation problem to a multi-agent coordination problem.
Why does this graduation matter? Because single-robot navigation answers "how does one vehicle get from A to B," while fleet scheduling must answer three coupled questions at once: task allocation (which task goes to which robot), path planning (which route each robot takes), and conflict resolution (who yields when two robots want the same intersection). The three are entangled: the cleverest allocation is worthless if the aisles jam up, and the smoothest paths mean nothing if half the fleet idles while the other half queues.
Three multi-agent fleet scheduling approaches: centralized, decentralized, learning-based
Research and industry practice in multi-agent AMR fleet scheduling have broadly converged on three lines of attack. They are not a simple ranking from best to worst; they represent three different worldviews about how to handle uncertainty.
Approach 1: Centralized optimization — one brain for the whole floor
A central scheduler holds the global state: every pending task, each robot's position, battery level, and payload. Task assignment is typically solved with assignment algorithms (Hungarian-style methods and their variants), while path planning uses time-extended A* or conflict-aware methods such as CBS (Conflict-Based Search). All decisions are computed in one place and dispatched to the fleet.
The appeal is determinism. With global information, the scheduler can in principle compute the highest-throughput solution; the decision process is logged, reproducible, and auditable — a genuine advantage in environments with strict safety compliance requirements.
The costs are equally clear. First, computational complexity: task allocation is combinatorial, and solve times balloon as the fleet grows, forcing engineers to cap computation with heuristics and receding horizons — at which point "globally optimal" becomes an approximation. Second, single-point fragility: if the central scheduler stalls or the network jitters, fleet behavior degrades abruptly. Third, the approach assumes near-complete information, while real warehouses deliver anything but: task arrivals are stochastic, Wi-Fi fluctuates, and robots break down.
I saw a textbook case during a visit to an e-commerce fulfillment warehouse in California's Inland Empire last year: roughly 120 shelf-carrying AMRs under centralized scheduling, with beautifully low deadhead rates in simulation. In production, bursty task arrivals from the WMS forced constant replanning, and at peak season — around 20,000 orders a day — the system repeatedly fell back to simple rules because it "couldn't compute fast enough." Centralized optimization has the highest ceiling, but its demands on input quality routinely exceed what a real warehouse can supply.
Approach 2: Decentralized negotiation — every robot for itself, politely
The decentralized route pushes decision-making down: each AMR acts as an independent agent, claiming tasks through auction or bidding mechanisms (lowest bidder wins), while intersection conflicts are handled by priority rules or local negotiation. There is no central brain; robots exchange only the information they need.
The strengths are robustness and scalability: adding robots means adding nodes, with no central model to rebuild; a single robot's failure stays local; tolerance for communication outages is higher, since a disconnected robot can keep moving under local rules instead of freezing in place.
The price is local optimality. Each robot sees only its neighborhood, so collective behavior can settle into suboptimal equilibria — several robots converging on the same hot picking zone and clogging it, or politely deadlocking in a narrow aisle while each waits for the other to move first. Harder still is explainability: emergent behavior in distributed systems resists prediction, and post-incident reviews often end with nobody able to say exactly "who moved first."
A 3C distribution center in eastern China offers a representative case: around 80 sorting AMRs went live in 2023 with auction-based decentralized scheduling. Day-to-day operations were smooth, and scaling up was genuinely easy. But when promotional peaks doubled task density, negotiation overhead at intersections rose visibly, with episodes of robots waiting each other out until human-defined priority corridors broke the stalemate. Decentralized does not mean "no management" — it moves complexity from the central algorithm into rule design and exception handling.
Approach 3: Learning-based policies — let the fleet teach itself to cooperate
The third route is multi-agent reinforcement learning (MARL): hundreds of agents practice in simulation until they converge on cooperative strategies, which are then deployed on physical robots. In theory, this can discover coordination patterns no human engineer would design — a certain rhythm of yielding, for instance — and adapt naturally to dynamic environments.
But several hurdles stand between this approach and large-scale deployment. First is the sim-to-real gap: a policy that performs beautifully in simulation can fail against sensor noise, floor friction, and payload variance on real hardware, and anyone who has done sim-to-real transfer knows the final mile of tuning often costs more than the training itself. Second is the black-box problem: neural policies resist auditing, which makes them difficult to certify in safety-critical settings such as human-robot shared zones. Third is training cost: large-scale MARL demands substantial compute for returns that remain uncertain.
Hence the real pattern today: learning-based methods appear mostly in the "prediction" layer — forecasting task arrivals, anticipating congestion — rather than making the decisions themselves. Letting AI serve as advisor before promoting it to commander is the more realistic engineering path.
Choosing a fleet scheduling approach: no silver bullet, only fit
Comparing the three approaches to multi-agent AMR fleet scheduling side by side makes the selection logic clearer:
| Dimension | Centralized optimization | Decentralized negotiation | Learning-based policies |
|---|---|---|---|
| Decision maker | Central scheduler | Each robot independently | Trained group policy |
| Fleet scale | Best at small-to-medium scale; needs degradation at very large scale | Best scalability; adding robots adds nodes | Harder to train as scale grows |
| Responsiveness | Replanning latency is the bottleneck | Fast local response | Fast inference, but model-quality dependent |
| Single-point failure | Fragile; central outage hits everything | Robust; failures stay local | Depends on deployment architecture |
| Explainability / auditability | Strong; decisions replayable | Weak; emergent behavior hard to predict | Weakest; black box |
| Deployment maturity | Highest; the default for mainstream vendors | Medium; requires careful rule design | Lowest; mostly pilots |
One counterintuitive judgment deserves emphasis: the approach with the highest throughput in simulation does not necessarily win in production. Centralized "global optimum" rests on two assumptions — complete information and instantaneous computation — and real warehouses discount both heavily. A fast-reacting, gracefully degrading suboptimal design — say, centralized coarse task allocation combined with distributed local conflict resolution — often outperforms a brittle optimal one. In engineering, "not collapsing under bad conditions" is worth more than "optimal under good conditions."
Another underappreciated fact: the scheduling algorithm itself accounts for perhaps thirty percent of deployment difficulty. The remaining seventy percent is charging strategy, map zoning, and coordination with the WMS and human operators (task granularity, exception ownership). I have seen more than one project where the algorithm team tuned CBS to perfection, only to have throughput capped by too few charging docks. Fleet scheduling was never just an algorithms problem.
Outlook: hybrid architectures now, learning-based methods as the long variable
Causally, the three approaches embody three attitudes toward uncertainty: centralized eliminates it with compute, decentralized tolerates it with redundancy, and learning-based adapts to it with data. In the near term, hybrid architectures (central coarse allocation plus distributed local resolution) will dominate deployments, striking an acceptable balance between auditability and robustness; learning-based components will enter through prediction and simulation tuning before migrating toward decision-making.
Looking further ahead, an open question: as AMR counts keep rising and humanoid robots, unmanned forklifts, and autonomous trucks join the same floors, will the boundary of "fleet scheduling" expand from "one class of equipment" to "a traffic operating system for the entire site"? On that day, the scheduler would coordinate heterogeneous traffic participants rather than a homogeneous fleet — potentially a bigger paradigm shift than today's three approaches. For now, that question has no standard answer.
By Dr. Chen, Supply Chain Researcher
