Sequential robot dispatch is intuitive. You have a task, you send it to an available robot, you wait for confirmation, you send the next task. When you have one or two robots, this is exactly the right model. The cognitive overhead is low, the failure modes are obvious, and the system is easy to reason about.
The problem is that the model does not compose. Each additional robot multiplies the interaction surface with every other robot. A dispatch decision that was safe with two robots may not be safe with twelve, because the space of possible concurrent path conflicts grows combinatorially. The dispatcher, whether human or software, cannot track all of those interactions in real time. The sequential model breaks not because it was wrongly designed, but because it was designed for a context that no longer applies once fleet size crosses a threshold.
This post works through the specific failure modes that appear as fleet size grows: convoy formation, corridor thrashing, idle accumulation, and the human overhead that fills the gap when software coordination is insufficient. Each of these is a direct consequence of the sequential dispatch architecture, not a bug or configuration issue.
Failure mode one: convoy formation
In sequential dispatch, tasks are issued to robots without coordination across the set of in-flight tasks. This means nothing prevents two robots from being assigned routes that use the same corridor at the same time. When a corridor allows only single-file navigation (most warehouse aisles), the second robot must wait behind the first, forming a two-robot queue. If three tasks were dispatched to that corridor in rapid succession, you have a three-robot queue, each waiting for the one ahead to clear the corridor.
From a throughput perspective, this is near-equivalent to having one robot doing all three tasks sequentially. The other two robots are consuming floor space and occupying the corridor reservation while providing no throughput. The convoy also creates a cascading delay: the third task doesn't complete until the second completes, which doesn't complete until the first completes, regardless of whether the tasks themselves have any logical dependency on each other.
At small fleet sizes, convoys are rare because the probability of two tasks being routed to the same corridor at the same time is low. At 15 to 20 robots with a typical warehouse layout where major thoroughfares are shared by most tasks, convoys become a regular occurrence during busy pick windows. They are not visible in task completion data as a distinct event, because the convoy robots eventually complete their tasks. The symptom appears as throughput that is lower than the fleet's theoretical capacity should produce, with no obvious single cause.
Failure mode two: corridor thrashing
A subtler problem than convoys is corridor thrashing. This occurs when sequential dispatch assigns tasks that create opposing traffic flows in a corridor, causing robots to alternately yield and advance in a back-and-forth pattern. In warehouses with yield-on-conflict navigation rules (where one robot stops to let the other pass), opposing flows in a single-direction corridor create repeated yield events that compound into significant delays.
The cause is the same as convoys: sequential dispatch has no visibility into the combined routing pattern of in-flight tasks. It makes each assignment looking only at whether the corridor is currently occupied, not at whether the robot it just dispatched will still be in the corridor when the next assignment is made. Dispatching a robot to travel east through corridor C, then immediately dispatching another to travel west through corridor C, creates a head-on encounter that both robots will stop and negotiate.
Thrashing is particularly expensive because it creates stop-start motion for both robots, not just one. The yield protocol in most AMR navigation systems also introduces additional latency: robots must detect the opposing robot, communicate the yield decision, execute the yield manoeuvre, confirm the pass, and resume. A complex yield negotiation in a narrow corridor can consume 30 to 90 seconds of robot time for both parties.
Failure mode three: idle accumulation
Sequential dispatch systems typically run a polling or event-driven model: when a robot reports task completion, the dispatch system assigns it a new task from the queue. This design means robot idle time is bounded below by the round-trip time of the completion report plus the time to compute and issue the next task assignment.
In a well-tuned system with fast network response, this round-trip might be under a second. But it accumulates. If a 20-robot fleet each completes a task every 4 minutes on average, the dispatch system is processing 5 completion events per minute. Each requires a queue lookup, conflict check, and command emission. During peak task density, the dispatch system may be processing multiple completions simultaneously, and response time can increase. Even a 3-5 second average idle gap per task completion, across 20 robots running all day, represents a meaningful fraction of total available robot time.
The deeper problem is that the sequential model cannot pre-position robots. In a fleet with good spatial diversity of tasks, an optimal allocation would dispatch robots to their next task locations in a way that minimises travel distance to the next pick location. Sequential dispatch, which only assigns the next task after the current one completes, cannot do this look-ahead. A robot that just completed a deposit at dock 1 gets assigned the next task in the queue, which might be a pick at bay 18 on the opposite side of the floor, because the dispatcher did not know at the start of the previous task that bay 18 would be the next assignment.
Failure mode four: human coordination overhead
The operational response to the first three failure modes is typically human intervention: a supervisor watching the floor and making adjustments. They see the convoy forming and manually pause one robot. They notice two robots heading toward each other in a corridor and manually reroute one. They observe that a robot is sitting idle for an unusual period and manually push it a task.
This is rational behaviour. The humans are providing the fleet-level coordination that the dispatch software cannot. The problem is that this intervention does not scale, and it creates its own failure mode: the supervisor becomes the coordination bottleneck. During high-intensity pick windows with 20-plus active robots, a supervisor cannot track all of the relevant interactions simultaneously. Interventions get missed, or applied incorrectly because the supervisor is reasoning about an incomplete picture of fleet state.
There is also an asymmetry in supervisor availability. Convoy formation and corridor thrashing occur unpredictably and resolve within minutes. A supervisor who is at lunch, attending a meeting, or handling a separate incident on the other side of the floor cannot intervene in time for these short-duration events. The throughput impact of those missed interventions is absorbed as unexplained variability in the shift's task completion data.
Why the fix is architectural, not configurational
A common first attempt at addressing these failures is tuning the sequential dispatch system: adding corridor reservation logic, implementing minimum spacing rules between robots on the same route, building a manual priority queue for high-urgency tasks. These improvements can reduce the frequency of failure modes, but they do not eliminate them, because they are adding constraints on top of a model that still lacks a shared representation of fleet state.
Corridor reservation, for example, requires a centralised corridor state store that every dispatch decision reads from. Building that state store is the beginning of fleet-level orchestration, not sequential dispatch with better locks. Once you have a corridor state store, you also want it to incorporate planned reservations from in-flight tasks, not just current occupancy. Once you incorporate planned reservations, you need a task graph to know which corridors each in-flight task plans to use. At this point you have rebuilt the core of a task graph orchestration system incrementally, usually with architectural inconsistencies from the piecemeal approach.
The argument for building fleet orchestration from first principles, rather than incrementally patching sequential dispatch, is that the task graph structure is load-bearing throughout the architecture. The compilation step that produces the graph also produces the route assignments and corridor reservations. The execution engine that runs against the graph handles completion events and dependency propagation. The replan engine queries the graph for affected tasks when disruptions occur. These components are coherent because they all work against the same data structure.
What fleet scale actually requires
The threshold where sequential dispatch stops working adequately is not a fixed number of robots. It depends on the warehouse layout's chokepoint density, the task distribution across the floor, and the tolerance for throughput variability. In our test bench with 40-robot lab scenarios, the convoy and thrashing failure modes become measurable above around 12-15 active robots in a standard mid-density warehouse layout.
What fleet scale requires is a dispatch system that makes assignment decisions with visibility into the current and planned positions of all in-flight robots, not just whether a specific robot is currently available. That visibility requires persistent fleet state and a task representation that captures route plans, not just current commands. Sequential dispatch was designed without those requirements because they did not exist at the scale it was designed for. The shift to fleet orchestration is not about fixing sequential dispatch; it is about replacing it with a system that was designed for the coordination problem that actually exists.