Most warehouse orchestration systems are designed for the case where everything goes according to plan. Tasks are compiled, routes are assigned, robots move. The implicit assumption underneath this is that the physical environment is stable: lanes remain open, equipment stays in predictable positions, and no human crosses a robot path at an inconvenient moment.
In practice, none of those assumptions hold reliably. A pallet gets dropped in the middle of an aisle. Maintenance parks a cage in a cross-aisle. A forklift operator takes a shortcut through zone 3 during a shift changeover. These things happen several times a day in active warehouse operations, not occasionally. Designing an orchestration layer that treats these events as exceptions to handle in the error path is designing for the wrong operating model.
This post is about what it means to design for uncertainty from the start: treating environmental disruption as a first-class concern in the architecture, not a bolt-on. We are still working through our own thinking here, and we will be honest about the tradeoffs.
The Problem with Optimistic Architectures
An optimistic orchestration architecture assumes the world will match the plan. Routes are computed at dispatch time and treated as fixed commitments. The system sends a robot toward dock 7 via lane 6 and then, functionally, forgets about lane 6. If lane 6 becomes unavailable after dispatch, the robot either stops and waits for operator intervention, or it reaches the blockage and triggers a fault.
Waiting for operator intervention has a real cost. A robot idling at a blockage is not just one robot down. Every task downstream in the same ops request that depends on this robot's completion is now stalled. In a 15-robot fleet running concurrent ops requests, a single idle robot can stall two or three dependent task chains simultaneously. The idle time compounds before any human notices.
Fault-on-contact is worse. The robot has moved partway through its task. Whatever it was carrying may be in the wrong location. The task graph now has a partially-completed node that is neither done nor cleanly failed, and the system has to reconcile that before anything else can proceed.
The root problem is not that blockages happen. It is that the architecture gave itself no mechanism to respond to them while work was in progress.
What "Designed for Uncertainty" Actually Means
Designing for uncertainty in warehouse orchestration means treating the current state of the physical environment as something that needs to be continuously reconciled against the plan, not just sampled once at dispatch time.
This has several concrete implications for how the system is structured.
First, route assignments cannot be truly final at dispatch. They are working assumptions that the system holds provisionally and is prepared to revise. The task graph carries enough information about what is required (move from bay 3 to dock 7) to generate an alternative route if the originally planned path becomes unavailable. This is different from storing the route as an immutable field in a completed dispatch record.
Second, the system needs to know which physical resources each task depends on. Not just "robot 07 is going to dock 7" but "robot 07's current route passes through lane 6 and uses cross-aisle 4B." When lane 6 is reported blocked, the system can immediately identify which active tasks are affected, because it has been tracking that dependency. Identifying affected tasks is the prerequisite to replanning them. If the system doesn't know which tasks care about lane 6, it has to either stop everything or attempt to replan everything, both of which are far more disruptive than targeted replanning.
Third, the replanning response has to be fast enough to be useful. If a robot is 10 seconds from a blockage and the replan takes 45 seconds, the robot arrives at the block before the new route is ready. The useful budget for replanning is measured in seconds, not tens of seconds. This puts real pressure on how the state store is structured and how the route alternatives are computed.
The Role of Task History in Recovery
One pattern that changes how recovery works: keeping a record of what tasks have already completed within a running ops request, not just what tasks are currently active or pending.
Consider a pallet movement op with three sequential tasks: pick from bay 3, traverse to dock staging, deposit at dock 7. If a blockage occurs during task 2 and the robot has to take a longer alternative route, the system needs to know task 1 has already completed successfully. The completed pick is not in question. Only task 2 needs replanning. The recovery scope is bounded by what has already happened.
In a stateless dispatch model, this history is not retained. When something goes wrong, the system knows the current command it issued but not what preceded it in the same logical operation. Recovery becomes a manual reconstruction exercise.
Task history also matters for partial-failure recovery. If robot 07 gets stuck and cannot complete its current task, a different robot can be assigned to pick up the work. But what that replacement robot needs to do depends on where the original robot got to. A pick task that was half-executed is different from one that never started. Without history, both look the same to the system.
Handling Persistent vs. Transient Blocks
Not all lane blocks are equal, and the right response depends on the type.
A transient block is something that will clear on its own: a forklift in motion, a pedestrian crossing, a momentary equipment jam. The right response may be to wait briefly rather than immediately commit to a longer alternative route. Replanning onto a longer path, and then the original path clears 20 seconds later, wastes time. But waiting indefinitely for a transient block that turns out to be persistent is equally bad.
A persistent block is something that will not clear without deliberate intervention: a maintenance cage left overnight, a damaged pallet dropped in an aisle, a vehicle that has broken down. These require immediate rerouting because waiting accomplishes nothing.
The system has to make this distinction without reliable ground truth. There is no sensor that directly distinguishes "temporary" from "permanent." The practical approach we have been thinking through involves a time threshold: hold briefly (on the order of 5 to 15 seconds, depending on context), monitor for clearance, and if the block has not cleared, treat it as persistent and commit to the replan. The threshold is a parameter, not a fixed value, because different warehouses have very different traffic patterns.
We are not claiming to have fully solved this. The right threshold depends on operational knowledge that varies by facility, and getting it wrong in either direction has costs. This is an area where the orchestration software has to expose tunable parameters rather than embed assumptions.
Design Principles That Follow From This
Working through these constraints has pushed us toward a few design principles that we think are generally applicable to orchestration systems facing real warehouse conditions.
Route assignments should be treated as mutable working assumptions, not immutable commitments. The graph representation should store what is required and what is available, not just the specific path chosen at dispatch.
Physical resource dependencies should be tracked at the task level, not just at the robot level. Knowing that robot 07 is in zone 3 is less useful than knowing that robot 07's current task passes through lane 6. The former tells you where a robot is; the latter tells you what breaks when a specific resource becomes unavailable.
Replanning needs its own latency budget, and that budget should be respected in system design. If the replan engine can produce alternatives in under a second on test scenarios, that is a useful capability. If it takes 30 seconds because the state store requires a full graph traversal on every query, the replanning capability is not actually useful in practice.
The system should distinguish between tasks that are affected by a disruption and tasks that are not. Replanning the entire fleet on every block event is operationally disruptive and unnecessary. The subset of tasks that actually depend on the disrupted resource is usually small, and those are the only ones that need to change.
What This Does Not Solve
It is worth being explicit about what uncertainty-aware design does not address.
Replanning assumes the disruption is detectable. If the sensor layer cannot report a lane block reliably, or reports false positives at a high rate, replanning fires on bad data and creates its own disruption. The orchestration layer cannot fix sensor quality. There is a detection dependency that the software alone cannot resolve.
Dynamic replanning also assumes the alternative routes exist. In a facility with high lane utilization and few cross-aisle options, a block in a critical corridor may have no good alternative. The system can find the least-bad option, but it cannot create physical space. Layout constraints are outside the scope of what software can fix.
And replanning adds coordination complexity. Every replan that redirects a robot may now put that robot into potential conflict with another robot that was relying on its original position. The system has to account for this, which means replanning is not just a path-finding problem but a fleet-level coordination problem. The scope of replanning cannot be entirely local to the affected task.
These constraints are real. We are not suggesting that building in dynamic replanning makes uncertainty disappear. The argument is narrower: an orchestration layer that cannot attempt a reasoned response to common disruptions is not deployable in a production warehouse. The uncertainty is there regardless. The question is whether the system is designed to respond to it or to fail on contact with it.