The first AMR deployment most facilities run is one robot, maybe two, in a confined zone. The tooling that ships with those robots is designed for exactly that scale: send a task, wait for completion, send the next task. It works. The robot moves pallets, the task queue drains, operators learn the interface. Everyone is happy.
Then the facility adds more robots. Maybe they go from two to eight over the course of a year. The same tooling is still there, the same mental model of "send task to robot" is still in use, and things mostly work. There's a bit more coordination overhead, some manual rerouting when two robots end up in the same corridor, but it's manageable.
At fifteen to twenty robots, the model breaks. Not all at once, but progressively. Throughput plateaus despite more robots being added. Supervisors spend more time watching the floor. Incidents where robots block each other increase. Tasks that should complete in parallel end up serialising because of chokepoint conflicts nobody anticipated at dispatch time. The operational overhead of managing the fleet starts consuming the gains from having a larger fleet.
The cause is not the robots. It is the mental model and the tooling built around it.
The single-robot model and why it cannot scale
Single-robot dispatch treats each task as an isolated unit of work: pick up item X, carry it to location Y, return to dock Z. The task is self-contained. The robot receives it, executes it, reports completion. This model fits a single robot perfectly, because a single robot has no one to conflict with.
The problem with applying this model to a fleet is that it produces no shared representation of the work. Each robot knows its own task. No part of the system knows that Robot 4 and Robot 7 are both routing through corridor B at the same time, or that task T-108 cannot start until task T-104 deposits its pallet at the staging area, or that three robots are heading to the same charging dock simultaneously when only one port is free.
These are fleet-level concerns that simply do not exist in a single-robot paradigm. Adding more robots to a single-dispatch system does not produce fleet coordination. It produces a larger collection of isolated robots, each following its own instructions, with no mechanism for them to reason about each other's work.
The operational overhead grows because humans step in to provide the fleet-level coordination that the software cannot. A supervisor watches the floor, calls out "don't send anything to zone C right now, there are three robots already there." A dispatcher manually sequences tasks to avoid conflicts. These are rational responses to the gap in the tooling. They are also expensive and do not scale past a certain fleet size.
What changes with an ops-request model
The shift we are making with Stateful Robotics is moving the unit of work from the individual task to the ops request. An ops request is a complete work instruction at the warehouse level: "move batch A47 from bay 3 to dock 7." That instruction, when compiled into a task graph, produces all the individual robot tasks required to execute it, along with the dependency relationships between them.
This changes the unit of dispatch from "task for Robot N" to "ops request to be executed by the fleet." The orchestration layer handles the decomposition. It looks at the ops request, the current warehouse state (which lanes are available, which robots are free, what other ops requests are running), and produces an assignment that coordinates the fleet rather than instructing individuals.
The practical difference is visible at a few levels. First, the system has a shared representation of all running work. It knows that T-104 and T-108 are part of the same ops request, that T-108 depends on T-104's completion, and that both are assigned to robots in the eastern zone. When Robot 4 completes T-104, the system can immediately trigger T-108 assignment without waiting for a human to notice and dispatch.
Second, corridor allocation happens at the fleet level. When compiling an ops request into tasks, the routing step considers which corridors are already reserved by in-progress tasks from other ops requests. If corridor B has two robots booked through it in the next 90 seconds, a new task that would also route through corridor B gets either a timing offset or an alternative route, not a collision.
Third, the system can reason about robot-type matching across the whole request. An ops request might require a pick operation that needs a small-format AMR and a pallet transport that needs a heavy-payload AMR. The compilation step knows the fleet's robot types and assigns accordingly, as part of the single compilation run, not through two separate manual dispatches.
Task dependency graphs and why they matter for execution
The task graph produced by compilation is a directed acyclic graph (DAG). Each node is an individual task. Each edge is a dependency relationship: task B cannot start until task A completes. The graph also carries preconditions at the node level: task B requires that staging position P3 is free, which is a condition that might be satisfied by task A's completion or might need to be checked against current bay state.
Executing against a task graph rather than a flat task queue produces two significant operational benefits. The first is correct parallelism. Tasks with no dependency relationship can run concurrently, and the system knows which those are because the graph is explicit about dependencies. In a flat queue, the dispatcher would need to manually determine which tasks can run in parallel. In a graph, the DAG structure encodes that information directly.
The second benefit is meaningful replanning. When a lane blocks, the system can traverse the graph from the blocked lane upward to identify which tasks are affected. Tasks downstream of the block in the dependency chain are affected; tasks in parallel branches of the graph are not. This is a graph traversal, not a guess. It produces accurate scope identification in milliseconds, which is what makes sub-second replan latency achievable.
A flat task queue has no equivalent structure. It cannot distinguish between tasks that are logically related and tasks that are coincidentally adjacent in the queue. Replanning against a flat queue requires either stopping everything (safe but expensive) or making heuristic guesses about task relationships (risky and often wrong).
What the mental model shift asks of operations teams
Moving from single-robot dispatch to ops-request-based orchestration requires a shift in how operations teams think about submitting work. Instead of "assign task to robot," the interaction becomes "submit ops request to the fleet." The operator describes what needs to happen at the warehouse level. The orchestration layer determines how to allocate the fleet to execute it.
This is an adjustment. Teams that have been managing robot dispatch manually need to trust that the compilation and assignment logic is making better decisions than they would make by hand. That trust is earned incrementally: starting with a bounded zone, observing the task graph execution, building confidence in the assignment logic before expanding to the full floor.
We are not saying that operators become passive observers. There are still real decisions humans make: which ops requests are high priority, when to manually override a robot assignment, when to pause the entire fleet for a physical intervention. The orchestration layer handles the combinatorial allocation problem. Operational judgment about priorities and exceptions remains with the team running the floor.
What the mental model shift does eliminate is the need for humans to manually reason about robot-to-corridor conflict across a 20-robot fleet. That is a combinatorial problem that scales badly with fleet size, and it is exactly what the task graph approach is designed to handle computationally.
Mixed fleets and the coordination challenge
One practical complication that often gets underestimated is the mixed fleet. Most warehouses that have been adding robots over time have accumulated multiple generations from multiple vendors: older models with different speed profiles, a batch from a different supplier with a different navigation SDK, perhaps a few specialist AMRs with lifting capacity that the standard units lack.
Single-robot dispatch systems typically handle this by having separate interfaces for each robot type, often managed by different team members. This works until you need to coordinate work across robot types, at which point the separate-interface model breaks down entirely. A pallet movement that requires a small AMR to pre-position items and a heavy AMR to transport the consolidated load cannot be orchestrated by two separate dispatch systems with no shared state.
Fleet-level ops request compilation addresses this directly. The compilation step knows the capabilities of every robot in the fleet pool. It assigns robot types to tasks based on those capabilities, and it models the handoff points where one robot type's output becomes another robot type's input. The ops request remains a single unit of work; the decomposition into robot-type-specific tasks is handled by the compiler, not by the operator managing two separate interfaces.
Where the single-robot model is still appropriate
It is worth noting that fleet orchestration is not the right tool for every situation. If you have three robots and a simple pick-to-staging workflow with no lane dependencies or multi-step handoffs, the overhead of maintaining a task graph and running a compilation step adds complexity without adding value. The single-robot dispatch model is genuinely sufficient for small fleets with straightforward, independent tasks.
The shift to fleet orchestration makes sense when: concurrent task counts regularly exceed the number of robots (meaning tasks queue and need intelligent assignment); robot-to-corridor conflicts are causing measurable throughput loss; or ops requests routinely require coordination between multiple robots in a dependency chain. These conditions tend to appear around 10-15 active robots in a mid-complexity layout, though the exact threshold depends on the warehouse's physical constraints and task distribution.
Our focus is on the facilities where those conditions are present or approaching. The operational overhead of running a 20-plus-robot fleet on single-robot dispatch is real and gets worse as the fleet grows. Fleet-level task graph orchestration is not a marginal improvement on single-robot dispatch at that scale; it is a different architecture for a different problem.