A pallet drops sideways off a hand truck and blocks lane 7 at 14:23 on a Tuesday. At that moment, three robots in your fleet have active tasks that route through lane 7. Twelve more are on tasks that don't touch lane 7 at all. What happens next depends entirely on how your orchestration layer is built.
In most deployments today, the answer is: everything stops, or close to it. The robots approaching lane 7 halt. A supervisor gets a notification. Someone walks the floor, confirms the block, manually reroutes or cancels tasks, and eventually things start moving again. The twelve robots on unaffected tasks may or may not keep running depending on whether the halt propagates through the dispatch system. The whole episode takes eight to twenty minutes and leaves a gap in throughput during what might have been a peak pick window.
This is the problem we built the replanning engine to solve. The core claim is this: a blocked lane should affect only the tasks that actually depend on it, and those tasks should receive updated routes within sub-second latency, while everything else keeps running without interruption.
Why the naive response halts more than it should
The failure mode has a clear mechanical cause. In systems that dispatch tasks one robot at a time, each task is an isolated instruction. There is no shared model of which tasks depend on which lanes. When a block is detected, the safest thing the system can do is pause and wait for human confirmation, because it cannot reason about scope. It does not know that robot AMR-04's current task is entirely in the eastern zone and has no relationship to the blocked western corridor. So it pauses AMR-04 too.
This is not a bug in those systems. It is the correct response given what they know. The problem is that they were not designed to hold the information needed for a more precise response.
The fix is not a better halt algorithm. The fix is building the system so it holds enough task-graph state to know, at the moment of a block event, exactly which tasks are affected and which are not.
What the task graph holds at the moment of a block
When we compile an ops request into a task graph, every task node carries its route requirements as part of its precondition set. A task defined as "pick from bay 3, traverse lane 7, deposit at dock 2" has lane 7 explicitly in its path dependency list. A task defined as "pick from bay 11, traverse lane 9, deposit at staging area C" does not.
The graph also holds current execution state for each task: not started, in progress, completed, or blocked. And it holds robot-to-task assignment, so we know which physical robot is executing which graph node at any given moment.
This means that when a lane block event arrives, the engine can do a targeted query: which tasks in the currently running graph have a path dependency that includes the blocked lane, and what is their current execution state? That query runs against the in-memory task store, not a database round-trip, which is how we keep replan latency inside the sub-800ms window we see in our internal test bench running 40-robot lab scenarios.
The replan sequence, step by step
The block event arrives from one of two sources: a sensor signal from the lane's occupancy detector, or a manual block report submitted through the API (typically from a supervisor using a mobile interface). Either way, the event carries the blocked lane identifier and a timestamp.
Step one is scope identification. The engine queries the running task graph for all task nodes with a path dependency on the reported lane, filtered to nodes in state "not started" or "in progress." Completed tasks are irrelevant. Tasks in other zones are irrelevant. The result is a bounded set of affected nodes.
Step two is route recalculation. For each affected task node, the engine runs the routing solver against the current warehouse graph, with the blocked lane marked as unavailable. The warehouse graph is a live representation: it reflects not just the new block but all other currently active robot positions and reserved corridor segments. This matters because a naive reroute might send three robots down the same alternative corridor simultaneously, creating a secondary congestion problem. The routing step allocates each affected robot an alternative path and, where necessary, a holding position while a corridor clears.
Step three is command emission. Updated route commands go out to the affected robots via their native API. Each robot receives a delta instruction: continue from current position via updated path. Robots that were already traversing the blocked lane and are now past it receive a no-action signal. Robots that had not yet entered the lane receive the alternative route. Robots in progress at the block receive a hold-and-reroute instruction.
Step four is state reconciliation. The task graph updates the route field for each affected node and records the replan event with a timestamp and the triggering block ID. This audit trail matters for post-shift analysis and for understanding whether a particular ops request's throughput was affected by an environmental event.
At no point in this sequence do unaffected tasks receive any instruction. The twelve robots on tasks outside lane 7's dependency set keep executing without interruption.
The boundary: what replanning cannot do
It is worth being direct about what mid-run replanning does not solve. If the alternative routes are themselves congested, or if the warehouse layout has genuine single-point choke paths with no viable alternatives, replanning cannot conjure routes that don't exist. The routing solver works against the actual warehouse graph. If a facility has a layout where lane 7 is the only path between the pick zone and all dock doors, a block in lane 7 means affected tasks must wait. The replanning engine will identify this correctly and emit a "route unavailable, holding" state rather than a forced reroute into a congested corridor.
This is not a failure of the replanning system. It is accurate information about an infrastructure constraint. The value the system adds in that scenario is still meaningful: unaffected tasks continue running, the hold state is communicated immediately rather than discovered by a supervisor noticing idle robots, and the moment the block clears, replanning runs again and restores normal operation automatically.
We are also not claiming replanning eliminates the need for supervisors to respond to physical blockages. Someone still needs to clear the pallet. What replanning changes is the scope of the operational disruption while that clearing happens.
Integration with the WMS during a replan event
When a replan event affects an ops request, the orchestration layer fires a webhook to the connected WMS with the event payload: which ops request was affected, which tasks within it were replanned, the estimated impact on completion time, and the task IDs involved. This gives the WMS visibility into why a particular ops request is running behind its expected completion window without requiring a human to investigate.
The WMS can use this information to update its own scheduling layer: if ops request OP-1847 is now estimated to complete 11 minutes later due to a replan, the WMS might adjust the dock door assignment for that request or bump the priority of a competing request that can complete on time. That downstream scheduling logic stays in the WMS where it belongs. The orchestration layer handles task execution; the WMS handles business scheduling.
Latency budget and what drives it
The sub-800ms replan figure from our test bench refers to the time between block event receipt and the emission of updated route commands to affected robots. The dominant components are the graph query (typically 20-60ms depending on active task count), route recalculation (50-200ms depending on number of affected robots and routing complexity), and command emission (varies by robot API response time, which is outside our control). Under our test conditions with 40 robots and realistic task loads, end-to-end stays well inside 800ms.
In a live warehouse deployment, the actual time a robot receives its new route also depends on network latency to the robot. This is a physical-layer variable we cannot control from the orchestration layer. What we can control is that the orchestration side of the calculation completes fast enough that network latency is the binding constraint, not our processing time.
The practical floor impact of an 800ms replan is that robots typically receive updated instructions before they reach the blocked lane, unless they were within a few meters of it when the block was detected. In most warehouse layouts with realistic robot speeds in the 1.2-1.8 m/s range, that 800ms window corresponds to 1-1.5 meters of travel. The closer a robot is to the block at detection time, the more likely it is to need a hold instruction rather than a clean reroute. Both outcomes are handled; the hold case just means a brief stationary wait while the reroute is processed.
What this looks like in a pick-window scenario
Consider a facility running a high-density pick wave: 18 robots active, 340 open pick tasks assigned across a dependency graph, a 2-hour completion window. A lane block occurs 40 minutes in. The replan engine runs, identifies 4 tasks as affected (2 in progress, 2 not yet started), recalculates routes for all 4, emits updated commands within the replan window. The other 14 robots on 276 unaffected tasks continue executing without interruption. The pick wave completes roughly 12 minutes behind schedule, attributable to the rerouting delay on the 4 affected tasks, not to a full-fleet halt.
This scenario is illustrative, not a measured deployment result. Actual figures depend on facility layout, robot count, task distribution, and where in the task graph the block occurs. But the structural point is real: isolating the replan to affected tasks directly limits the throughput cost of a block event, and that isolation is only possible if the orchestration layer holds task-graph state at runtime.