Fleet-held orders versus onboard behavior trees when the network drops
You can choose between a central fleet manager that hands out short VDA 5050 orders and an AMR that plans its own missions at the edge by comparing two numbers: how long the network can disappear, and how much released path each robot holds. While outages stay shorter than that released path, the centralized design is simpler and fails safe, because a robot that runs out of authority just stops. When outages run longer, a centralized fleet stops wherever the radio drops out. Only robots that carry their own mission logic, plus some local way to claim shared floor space, keep producing work.
What each design does once the link is gone
In the centralized design, master control keeps the whole mission and releases only a base of nodes and edges the robot may drive. The rest of the route sits in a horizon the robot can see but cannot enter. When the connection drops, the robot finishes its base and halts. Nothing unsafe happens, but nothing productive happens either until the link returns. In the edge design, the mission itself lives onboard as a behavior tree driving the navigation stack, with fallback branches for a blocked aisle, a failed dock or a missing load. That robot keeps going without the fleet manager, which is the point of the design and also where the trouble starts. It is now deciding things about shared space that no other agent can see.
The failure that matters is not the robot that stops but two robots that each replanned correctly on their own and now face each other in a one-way aisle, with no arbiter left to tell one of them to back out.
Where the decision flips
The controlling parameter is the released base expressed as travel time. A typical tuning gives the base about 8 s of travel at nominal speed, because a longer base makes traffic control coarser and costs throughput at intersections. If your site survey puts the 95th percentile roaming gap below that figure, robots never notice the outages, so centralization wins outright and your effort belongs in base sizing and access point placement. Dense steel racking, mezzanines and cold store doors push gaps well past that, often to several seconds or more by my estimate. You can't fix those sites by stretching the base without giving up the traffic control you centralized for in the first place. The rule follows from that: when the measured 95th percentile dropout is longer than base travel time and stretching the base isn't acceptable, go to edge planning. Do that only if the robots can reserve corridor segments among themselves over a local link, and treat any reservation that can't be confirmed as denied.
What the edge option still costs you
Robots that keep working through an outage come back with a state that no longer matches the order master control thinks they are running. Somebody has to be authoritative at reconnection. If it is the master, you get duplicate or orphaned tasks. If it is the robot, the interface has to carry state the standard was never designed to carry, which in practice means vendor-specific extensions. My estimate is that this reconciliation logic ends up larger and harder to validate than the onboard planner itself, and every behavior tree version drifting across a mixed fleet makes it worse. Before the freeze, then, don't spend your time debating edge or central. Write down who owns mission truth during the first second after the link comes back, and make both the fleet manager and the robots enforce it.
Technical FAQ: Can a hybrid avoid the choice by planning centrally and falling back to onboard logic only during outages?
Yes, but the fallback is still edge planning, with all of its obligations: the robots still need a peer reservation scheme and a reconnection authority rule. A hybrid that leaves those out will deadlock in exactly the outages it was built to ride through.