Pick-to-light systems have been a standard fulfillment technology for decades. They do one thing well: they tell a picker exactly which bin to reach into and how many units to pull, using a small LED display mounted at the bin location. The WMS knows the floor layout, illuminates the right lights in sequence, and the picker follows the lights. Accuracy is high, training time is short, and the coordination model is simple.
AMR-guided picking works differently. Instead of a stationary light system directing a person through a fixed route, mobile robots carry totes, transport goods, or act as dynamic pick carts that move around the floor based on the current task queue. The coordination model shifts from "illuminate the right bin" to "route the right robot to the right location at the right time without creating congestion."
These are fundamentally different coordination problems, and the differences become operationally significant when you run both systems on the same floor.
The Coordination Model for Pick-to-Light
Pick-to-light coordination is essentially a stationary sequencing problem. The WMS assigns picks to a zone, illuminates the corresponding bins within that zone in a sequence designed to minimize picker travel distance, and waits for confirmation (usually a button press at each bin) before illuminating the next. The floor infrastructure is fixed. The coordination logic is deterministic given the pick list.
Where pick-to-light systems create coordination complexity is at the zone boundaries. When a zone is actively illuminated and a picker is working through it, incoming AMRs routing through the same zone create path-sharing conflicts. The pick-to-light system has no awareness of robot positions. The robots have no awareness that a human is actively picking in a sequence that depends on unobstructed access to specific bin locations. The two systems are operationally adjacent but informationally isolated.
For fulfillment operations running both systems, this isolation creates real operational friction. Robots navigating through active pick-to-light zones interrupt picker flow. Pickers walking their pick sequences can create robot queuing at zone entries. Neither system, on its own, sees the full picture.
The Coordination Model for AMR-Guided Picking
AMR-guided picking has more moving parts. The key coordination challenges are dispatch sequencing (which robot goes to which location next), path conflict avoidance (robots moving toward the same aisle segment simultaneously), zone load balancing (avoiding concentrating all active robots in the same floor area), and task resequencing when priorities change mid-shift.
In a pure AMR environment, a good fleet orchestration layer handles all of this. The floor graph models each aisle segment and intersection, the dispatch engine assigns tasks with path awareness, and robots reroute dynamically when conflicts are detected ahead. The system is self-coordinating within the robot fleet.
The complication in a mixed environment is that the floor graph only models what it can see. AMRs show up as positions on the floor graph with velocity and heading vectors. Pickers working a pick-to-light sequence are not on the floor graph at all, unless the orchestration layer has been explicitly integrated with the pick-to-light system's zone activity state.
What Changes When Both Systems Share the Floor
The primary operational difference in a mixed pick-to-light and AMR environment comes down to zone reservation and traffic anticipation.
In a single-mode AMR floor, the orchestration layer can model the entire floor as navigable robot space (minus static exclusion zones). Task assignments route robots through any available aisle. When a zone becomes congested with robot traffic, the orchestration layer reroutes incoming robots away from that zone dynamically.
In a mixed environment, some zones are intermittently occupied by pickers who are following light sequences that assume those zones are not robot-active. The orchestration layer needs to know which zones currently have active pick-to-light sequences running and treat them as soft-exclusion zones for AMR routing during that window. This requires an integration point: the pick-to-light controller needs to expose zone activity state to the orchestration layer, and the orchestration layer needs to weight routing costs upward for those zones accordingly.
The integration is not technically complicated. Most pick-to-light systems expose zone completion events over a simple API or MQTT feed. The orchestration layer treats zone-active signals from the pick-to-light controller as time-bounded path cost adjustments in the floor graph. When the zone clears (all bins in the sequence confirmed), the path cost normalizes and AMR routing resumes through the zone as normal.
Consider a growing fulfillment operation in the mid-Southwest running a hybrid floor with pick-to-light covering a high-velocity "A" SKU section and AMRs handling the broader pick floor. Without orchestration integration between the two systems, AMRs frequently routed through the pick-to-light zone during active sequences, causing picker flow interruptions averaging 4-6 per shift. After the orchestration layer was integrated with the pick-to-light zone activity feed, AMR routing avoided those zones during active sequences, and cross-system interruption events dropped to near zero during normal operations.
Task Assignment Sequencing Differs Between Systems
Pick-to-light sequencing is optimized for a single picker's travel path through a zone. The WMS or the pick-to-light controller calculates the optimal bin sequence for one person moving through physical space on foot, typically an S-curve or I-route through the aisles.
AMR task assignment is optimized for a robot's travel path considering the current state of every other robot. The right task for an AMR is not just the nearest pick location. It is the pick location that, when combined with the current task assignments of all other active robots, produces the best overall fleet throughput without creating congestion. These are different objective functions, and conflating them leads to suboptimal behavior.
This distinction matters when a fulfillment operation tries to apply pick-to-light sequencing logic to AMR task assignment, which we have seen happen when operations teams port their existing pick workflow templates to a new AMR deployment without adjusting for the different coordination model. AMRs assigned via human-optimized S-curve routes will cluster together in the same aisle segments, creating exactly the congestion that fleet-aware task assignment is designed to avoid.
We are not saying pick-to-light sequencing logic is wrong, it is correct for the problem it solves. The point is that the coordination model for mobile robots requires taking into account the full fleet state, not just the optimal single-agent path.
When Mixing Both Systems Makes Sense
Mixed floors are common for several operational reasons. Pick-to-light systems represent significant infrastructure investment that 3PLs are not going to decommission when they add AMRs. High-velocity SKU zones often benefit from the low latency and simplicity of light-guided picking for human pickers. AMRs are better suited for the broader, lower-velocity floor where pick density is lower and travel distances make human-only picking less efficient.
The coordination overhead of running both systems together is manageable with the right orchestration integration. The key requirements are: zone activity state from the pick-to-light controller fed into the floor graph, explicit exclusion or cost-adjustment logic for active pick zones in the AMR dispatch engine, and clear physical zone delineation on the floor so robot routing can respect the boundaries without ambiguity.
Operations that attempt to run mixed floors without this integration tend to resolve the coordination problem with physical separation, keeping AMRs entirely out of pick-to-light zones via hard floor markings and robot-enforced exclusion zones. This works but sacrifices the routing flexibility that makes AMRs valuable for throughput optimization. Integrating at the orchestration layer, rather than enforcing hard physical separation, keeps more of the floor available as dynamic robot space while still protecting active pick-to-light sequences from interruption.