We started tracking aisle congestion events closely about eight months after we first deployed Botpylon at a mid-size fulfillment center running two different AMR vendors. What we found surprised us, not because congestion was happening, but because it was happening at the same twelve locations on the floor every single shift, at nearly the same clock times. That regularity is the tell: if your congestion looks random, it probably isn't.
Mixed-vendor AMR fleets have a structural congestion problem that single-vendor deployments don't. When every robot runs the same fleet management software, that software at least has full visibility into all robot positions. It can, in principle, space out task assignments to reduce head-on conflicts. When you run two or three AMR vendors with separate fleet controllers, each controller is blind to the other fleet. The robots move as if they own the aisle. They don't.
Why Static Pick Sequences Concentrate Traffic
Most WMS systems output pick sequences that were designed for human pickers, not robots. The logic is sound for people: minimize walking distance by sequencing picks within a zone before moving to the next. For a single human picker, that produces nearly optimal travel. For sixty robots all receiving similar zone-biased pick sequences simultaneously, it produces predictable hotspots at zone boundaries and main transit aisles.
The floor topology matters here. In a typical pick-and-deposit layout, there are a small number of high-traffic corridors connecting pick zones to the deposit area. These aren't design flaws; they're structural features of efficient racking layouts. But when your WMS pushes sixty robots toward those corridors at the same time, and when each robot's vendor controller is independently deciding on shortest-path routing, you get what one of our customers called the "funnel effect." Everyone arrives at the bottleneck from different directions with no coordination protocol between fleets.
We measured this directly. On a 95-robot floor with two vendor fleets (call them Fleet A and Fleet B), we logged robot position data at 1-second intervals over fourteen shifts before enabling Botpylon's congestion-aware dispatch. The twelve most congested aisle segments each showed peak occupancy clusters between 09:15-10:00 and 13:30-14:15 daily. Those windows aligned exactly with when the WMS released large pick batches into both fleet controllers simultaneously.
What Congestion-Aware Dispatch Actually Changes
We want to be precise about what we mean here, because "congestion-aware" gets used loosely. Our dispatch layer does four specific things that a standard fleet controller does not.
First, it maintains a unified floor graph that includes position updates from all vendor fleets, not just one. The floor graph is updated every 250ms. Every robot from every vendor appears as a node on that graph, with a velocity vector and a current task assignment. This is the data structure that makes cross-fleet coordination possible. Without it, you're not doing congestion-aware routing; you're doing congestion-aware routing for one vendor while ignoring everyone else.
Second, the dispatch system applies path weight adjustments based on current and predicted occupancy. A corridor that currently has eight robots transiting it receives a higher path cost, which nudges newly assigned robots toward alternate routes. The weight increases aren't binary; they're graduated so that minor congestion causes minor rerouting and severe congestion causes aggressive avoidance. This keeps the system from overreacting to transient clusters.
Third, task release timing is staggered. Instead of releasing an entire pick batch simultaneously to both fleet controllers, Botpylon staggers releases by a few seconds per zone, reducing the synchronized surge that produces the funnel effect. This one change alone produced roughly 30% of our total congestion reduction in early pilots, which surprised us given its simplicity.
Fourth, deposit queue management. The area immediately in front of deposit stations is frequently where the worst congestion occurs. Multiple robots arrive simultaneously, and queuing behavior without coordination creates multi-robot clusters that block aisle access. We model deposit station capacity as a constraint and limit simultaneous approach assignments.
A Concrete Scenario: Two Floors, 95 Robots, Three Vendors
One deployment we can describe in detail (anonymized) involved a fulfillment operation running three AMR vendors across two connected floors, linked by a shared main transit corridor on the ground level. The transit corridor was the site of most of the serious congestion events, because robots from Floor 1 and Floor 2 used it simultaneously, and neither floor's fleet controller knew anything about the other.
Total active fleet: 95 robots. Daily peak shift volume: roughly 4,200 order lines. Before Botpylon, they were logging between 85 and 110 congestion stop events per shift (we define a congestion stop as any robot that halts for more than 12 seconds without a task completion event in that window). Many of these cascaded: one stopped robot caused approaching robots to stop, which blocked the corridor and caused more stops further back.
After connecting Botpylon to all three fleet APIs and enabling cross-fleet floor graph construction, we saw congestion stops drop to 22-35 per shift within the first week. By week three, after the path weight model had observed enough shift patterns to build a stable congestion prediction profile, stops dropped to 14-20 per shift. Pick-path travel distance per order line decreased by around 38% measured across a 30-shift window. Robot utilization (time actively in task vs. idle or stopped) went from 73% to 91%.
We're not claiming those exact numbers will apply to every deployment. Floor layout, robot mix, batch sizes, and WMS release cadence all affect the baseline and the improvement ceiling. What we are saying is that the underlying mechanism is generalizable: cross-fleet visibility plus path weight adjustment plus staggered task release consistently reduces the structural congestion that mixed-vendor fleets produce.
The Underrated Factor: Congestion Prediction vs. Congestion Reaction
Most congestion management approaches are reactive. A robot stops; the system reroutes it. That's better than nothing, but reactive routing still allows the cascade to begin. By the time you're rerouting a stopped robot, the robots behind it are already queuing.
What changes the picture more substantially is predictive routing: adjusting path weights before the congestion event occurs, based on the known task queue and the current robot distribution. If you know that in 40 seconds, twelve robots are going to finish their current picks and head toward the same deposit station, you can start routing the next wave away from that corridor now. The prediction window doesn't have to be long. Even 30-60 seconds of lookahead, applied to the task queue already committed to fleet controllers, is enough to substantially reduce synchronized arrival events.
This is where the floor graph's freshness matters. If your position data is 5 seconds stale, your predictions are 5 seconds stale, and at robot speeds of 1-2 m/s, a 5-second error is 5-10 meters of position uncertainty. That's enough to miss a developing congestion event entirely. We keep our floor graph at sub-300ms latency specifically because the prediction model needs current data to be useful rather than just plausible.
What This Doesn't Fix
Congestion-aware dispatch addresses the coordination layer. It doesn't fix racking layout issues, robot speed mismatches, or WMS pick sequencing logic that's fundamentally zone-unaware. If your floor has a physical chokepoint because of how the aisles were built, congestion-aware routing can distribute robots around that chokepoint better, but it can't eliminate the chokepoint itself.
We also want to be clear that fleet-agnostic dispatch does not require robot vendors to cooperate or certify anything with each other. The coordination happens at the dispatch layer. Each robot vendor's fleet controller still manages its own robots. Botpylon sits above all fleet controllers, assigning tasks and adjusting timing, while each controller handles the actual robot commands. The robots never need to know they're sharing a floor with a different brand.
The data pattern we see consistently is that the first 60-70% of congestion improvement comes from cross-fleet visibility and basic path weight adjustment. Getting from there to 85-90% improvement requires the predictive component and sustained operation so the model can learn your specific floor's congestion signature. Most fulfillment floors develop stable congestion patterns tied to their shift structure and WMS batch release cadence. Once those patterns are characterized, predictive routing becomes significantly more effective than purely reactive approaches.