Most early AMR deployments start with a single zone: one area of the warehouse, one robot type, bounded scope. A task graph that covers a single zone is relatively tractable. You have a defined set of pick locations, a defined set of staging or dock destinations, and a robot pool assigned to that zone. Dependencies within the graph are spatially local.
Multi-zone operations change the problem in ways that are not just additive. It is not a matter of running the same task graph engine across N zones independently. The interesting complications arise at the zone boundaries: tasks that cross zones, robots that can operate in multiple zones, priority rules that vary by zone, and replanning that has to consider the whole facility rather than a contained area.
This post covers the architectural changes we have been working through as we think about multi-zone task graph design. We are writing this in early 2025 as we are working through these problems ourselves, so some of this is thinking-in-progress rather than settled decisions.
Zone Models: What a Zone Is and Is Not
Before talking about what changes architecturally, it is worth being precise about what a zone is in the context of task graph orchestration.
A zone is a named spatial partition of the warehouse floor with its own robot pool assignment, its own set of navigable nodes and edges, and potentially its own operational rules (speed limits, priority weights, permitted robot types). Zones may be physically separated (different rooms, different floors), or they may share some physical space with soft boundaries defined by the orchestration layer.
A zone is not necessarily a clean operational boundary. An ops request can require work in multiple zones, and a robot assigned to zone A may need to pass through zone B to complete a cross-zone task. This is where single-zone orchestration assumptions break down.
The operational question that determines complexity is: how often does work cross zone boundaries? A facility where 90% of ops requests are fully contained within a single zone and 10% involve zone-crossing can be structured differently from one where cross-zone tasks are routine. The architecture should fit the actual traffic pattern.
Cross-Zone Task Assignment: The Handoff Problem
The simplest approach to cross-zone task execution is robot handoff at zone boundaries: robot A from zone A picks an item and delivers it to a transfer point at the zone boundary, then robot B from zone B picks it up and completes the delivery to its final destination. This keeps robots in their assigned zones and avoids the coordination complexity of cross-zone robot movement.
Handoff works well when the transfer points are well-designed, the two robots can be synchronized without long waits, and the additional transfer step does not create unacceptable latency. It is a simpler architecture to build and operate.
The alternative is cross-zone robot assignment: assign a task to a robot that is capable of operating in both the source and destination zones, and let that robot complete the whole task without a handoff. This is more efficient for individual tasks (no transfer latency) but requires the orchestration layer to track that robot's position across zone boundaries, apply the correct constraints as the robot moves between zones, and handle the case where the robot is needed back in its home zone while it is mid-task in another zone.
In practice, many facilities use both patterns depending on task type. Short cross-zone tasks with a single transfer step use handoff. Long-range tasks (dock to dock across the full facility) use direct cross-zone assignment with a robot that is explicitly configured for multi-zone operation.
Cross-Zone Dependencies in the Task Graph
When an ops request spans multiple zones, the task graph has dependencies that cross zone boundaries. A task in zone B might depend on a task in zone A completing successfully (the inbound pallet must arrive at staging before the outbound sort can begin). The graph needs to represent these dependencies accurately, and the orchestration engine needs to track completion state across zones, not just within each zone separately.
This sounds straightforward but creates some tricky edge cases in replanning. Suppose task A in zone A is blocked and needs replanning. Task B in zone B depends on task A completing. Does the zone B orchestrator know that task B should wait? If the zone A and zone B orchestrators are independent systems, this coordination requires an explicit cross-zone dependency notification mechanism. If they share a unified task graph, the dependency is visible to the same system that is handling the replan.
The unified graph approach is architecturally cleaner for cross-zone dependencies, but it puts the full cross-facility state into a single data structure that has to be updated by every zone's robot events. At high task volumes, this can become a write contention point. Zone-partitioned orchestrators with explicit cross-zone messaging are more complex to build but scale better under load.
There is no universally correct answer here. The right choice depends on the cross-zone dependency density of the actual ops requests, the task volume, and the latency requirements for dependency propagation. Building the architecture to allow either pattern and choosing based on observed behaviour is pragmatic if the choice can be deferred.
Priority Rules Across Zones
Priority rules often vary by zone in ways that reflect the operational function of each area. A dispatch dock zone might have strict time-based priority rules tied to truck departure windows. A picking zone might use task-age-based priority (oldest unstarted task first) to ensure even throughput. A charging zone might use battery-level priority to ensure the most depleted robots are served first.
When a cross-zone task is assigned, whose priority rules apply? The source zone, the destination zone, the zone the robot is currently in, or a top-level priority that overrides all zone-local rules? This is a policy question that has to be explicitly answered in the architecture, because leaving it unspecified produces inconsistent behaviour.
One practical pattern: define priority at the ops request level (the whole request has a priority), and let zone-local rules operate within the constraint that a high-priority ops request's tasks get preferential resource access within each zone they touch. Zone-local priority only applies among tasks of equal ops-request priority. This gives the top-level prioritisation system control over the operationally critical decisions while letting zone-local rules handle the routine throughput optimisation.
Replanning Scope in Multi-Zone Operations
When a lane block occurs in zone A, the replanning question is: which tasks are affected? In a single-zone system, this is contained: the affected tasks are those whose routes pass through the blocked lane. In a multi-zone system, the affected set potentially includes tasks from other zones if those tasks depend on zone A tasks that are now affected.
The dependency chain has to be traversable in both directions. Given a blocked resource in zone A, the system needs to identify: (1) which tasks in zone A are directly affected, (2) which tasks in other zones depend on those zone A tasks, and (3) whether there are alternative ways to satisfy those downstream dependencies that do not require the blocked zone A tasks to complete first.
Step 3 is the hard part. If the zone B task requires the specific output of a zone A task (a specific item from a specific bay), then the zone B task is fully blocked until zone A replanning resolves. If the zone B task requires a category of output that could be sourced from an alternative zone A location, the replanning might be able to substitute a different source rather than waiting for the original path to clear.
Building the task graph to carry enough information to support step 3 requires more semantic richness in how tasks are specified. A task specified as "pick item X from bay 14" has a fixed dependency on bay 14. A task specified as "pick item X from any bay in zone A that currently holds item X" has a flexible dependency that replanning can resolve differently. The specification model is a design choice with significant downstream consequences.
Operational Observability Across Zones
A practical consideration that compounds as zone count increases: how do you get a useful real-time view of what is happening across all zones simultaneously?
A per-zone dashboard that shows the state of each zone independently is functional but makes cross-zone dependency problems invisible. If zone B is waiting for a zone A task that is blocked and is being replanned, a per-zone view shows zone B "waiting" without indicating why, and shows zone A "in replan" without indicating that zone B is affected.
An ops-request-level view that shows the full task graph state across zones, regardless of which zone each task is in, makes cross-zone relationships visible. This requires the orchestration layer to maintain and expose that full view, which is an additional query capability on top of per-zone task tracking.
For operations teams doing live monitoring, the ops-request view is more useful when something is wrong. The per-zone view is more useful for routine throughput monitoring when everything is working. Both views are worth building, but if you can only have one in the first iteration, the ops-request view catches more problems faster.
What We Are Not Claiming
We want to be clear that we are describing how we are thinking about these problems, not describing a system we have fully built and validated in a multi-zone production environment. The architectural patterns here are grounded in the problem constraints, but multi-zone implementation has complexity that thinking-on-paper does not fully surface.
Specifically: the right tradeoffs between unified versus partitioned task graph architectures depend heavily on actual task volume numbers we do not yet have from multi-zone production deployments. The priority rule patterns described here are conceptually sound but the edge cases in real mixed-priority multi-zone operations are likely to produce behaviours that require iteration. Anyone building this system should treat these as starting points, not blueprints.