Every few weeks we get a version of the same question: "We already have a WMS. Why do we need an orchestration layer on top of it?" It's a fair question, and the confusion is understandable. Both systems are involved in warehouse operations. Both influence what robots do. But they solve fundamentally different problems operating at fundamentally different timescales and data resolutions.
The short answer is: your WMS decides what needs to happen. Your orchestration layer decides how to make it happen across a fleet of robots without those robots getting in each other's way. These are not overlapping functions. They're complementary, and both are necessary.
What a WMS Actually Does
A warehouse management system is an inventory and order processing system. Its core functions are: tracking what inventory exists and where it's located, processing inbound orders from upstream systems, generating pick lists and task sequences, managing receiving, put-away, replenishment, and outbound shipping workflows, and producing the compliance documentation and reporting that operations need to run.
A WMS operates at the order and inventory level. It knows that order #482941 needs SKU A from bin C4-12, SKU B from bin F7-03, and SKU C from bin B2-08. It produces a pick list. In a manual operation, that pick list goes to a human. In a robotic operation, that pick list goes to whatever system manages the robots.
What a WMS does not know: how many robots are currently in aisle C, whether bin F7-03 is accessible right now or blocked by a queuing robot, which robot has the payload capacity to handle this batch, what the current path weight is between the robot's current position and bin C4-12, or whether sending this task to robot #47 will create a conflict with robot #53 that's currently three meters away heading in the opposite direction.
These are not WMS failures. They're outside the WMS's scope by design. A WMS is built to manage inventory state and order processing workflows, not to track real-time robot positions or compute conflict-free path assignments across a fleet. The WMS vendors who have added "robot management" features typically implement a simplified dispatch interface that works reasonably well for single-vendor, low-density deployments. At scale, those features don't hold up.
What an Orchestration Layer Actually Does
Fleet orchestration operates at the robot-task assignment level, in real time, with awareness of the physical floor state. It receives task inputs from the WMS (or whatever upstream system is generating work orders) and translates them into specific, conflict-aware assignments to specific robots, sequenced and timed to minimize congestion and maximize throughput.
The orchestration layer maintains a real-time floor graph: the current position, velocity, state, and task assignment of every robot on the floor. This graph is updated continuously (sub-second). It's the data structure that makes congestion-aware dispatch possible.
When a new pick task arrives from the WMS, the orchestration layer doesn't just assign it to the nearest available robot. It calculates which robot, given its current position and task queue, can complete this task with the least total impact on floor congestion. It applies path weight adjustments based on current zone density. It staggers release timing to avoid synchronized robot surges. It monitors for blocked robots and reassigns tasks when a robot enters a fault state. It manages deposit station approach queues to prevent bottlenecks at the few critical points where congestion compresses most severely.
None of this is visible to the WMS. From the WMS's perspective, it sent a pick task and the task got completed. What happened in between, all the real-time routing and conflict avoidance and task resequencing, is handled at the orchestration layer. The WMS doesn't need to know. It has other work to do.
The Temporal Mismatch
One of the clearest ways to understand why these are different systems: the timescale they operate at.
A WMS processes order batches. In most fulfillment operations, the WMS releases task batches on a cadence, commonly every 15-30 minutes, sometimes every hour. Its decision-making horizon is minutes to hours: which orders need to ship today, in what priority sequence, how to balance the pick workload across zones.
Fleet orchestration operates on a sub-second decision cycle. A 300ms dispatch latency target means the system is making assignment decisions faster than a human can perceive. Robot positions change every few hundred milliseconds. A path-weight calculation needs to reflect the floor state at the moment of assignment, not 15 minutes ago. The dispatch decision made at 10:00:00.000 is different from the one made at 10:00:00.300 because three robots have moved and two new tasks have entered the queue.
You can't bolt a sub-second decision loop onto a batch-oriented inventory system. The data models are wrong, the update cadence is wrong, and the computational profile is wrong. They need to be different systems that communicate through a defined interface: WMS pushes task lists to the orchestration layer; orchestration layer reports task completions back to the WMS for inventory update.
A Practical Scenario: Where the Gap Shows
Consider a fulfillment center that upgraded from human pickers to a 90-robot AMR fleet without adding an orchestration layer. The WMS was extended to send pick tasks directly to the robot fleet controller. Early on, with 30 robots, the system worked. The WMS pushed pick lists, the fleet controller assigned them to robots using shortest-path logic, and throughput improved.
When the fleet grew to 90 robots and order volume tripled, the operation started seeing systematic problems: peak congestion events every shift around zone boundaries, robots queuing at deposit stations for 3-5 minutes, pick cycles that were theoretically 8 minutes stretching to 14 minutes because of wait time. The WMS had not changed. The fleet controller had not changed. The problem was that neither system was managing the emergent dynamics of 90 robots sharing a floor, because neither was designed to.
Adding an orchestration layer between the WMS and the fleet controller reduced congestion events by roughly 55% in the first month, as the path weight model learned the floor's congestion signature and dispatch timing was adjusted to reduce synchronized task surges. The WMS didn't change. The fleet controller didn't change. The orchestration layer inserted itself in the task assignment flow and handled the problem that the other two systems weren't designed to handle.
Do They Ever Overlap?
Some WMS platforms have added orchestration-adjacent features: robot dispatch modules, pick zone optimization, basic task sequencing. We're not saying those features are useless. For small-scale deployments with a single robot vendor and fewer than 30-40 robots, a WMS with good dispatch features may be enough. The complexity that drives the need for a dedicated orchestration layer scales with fleet size, vendor diversity, and floor density.
Where WMS dispatch extensions reliably fall short: multi-vendor fleets (the WMS dispatch module typically only supports its certified integration partners), real-time floor state awareness (WMS systems aren't built for sub-second telemetry processing), and dynamic path weight adjustment (most WMS dispatch modules use static zone assignments, not continuous congestion-aware routing).
We built Botpylon specifically to handle what WMS systems don't: the real-time, fleet-agnostic, congestion-aware dispatch layer that operates between the inventory system and the robot fleet. The WMS is your authority on what needs to happen. Botpylon handles how it happens on the floor, in real time, without your robots blocking each other.