Magazino's October 2025 pathway design guidance states that AMR transport by elevator should be avoided because it creates bottlenecks and long waiting times, not only during the cabin call but across the queue that forms on every floor the robot must clear before boarding [S1].
In dense production halls the same constraint reappears at roller shutters, air-shower doors, and conveyor interlocks, and it is the leading cause of idle-fleet time on IFR-cited 2024 lithium-battery deployments where more than ten cartridge-handling AMRs autonomously call elevators, pass through air-shower doors, and dock in aisles as narrow as 1,301 mm [S5].
For a 2026 procurement spec, the floor-to-floor handoff should be treated as a discrete subsystem with its own latency budget, interlock contract, and traffic-manager hook, not as a free side-effect of the robot's onboard planner. The same lesson shows up in AMR fleet management software design notes from OTTO and Fives, where queue management and exception handling are listed alongside mission dispatch as the three failure modes that decide whether a fleet pays back [S2][S4].
Why Elevators Become the Single Hardest Node
An elevator car is a single shared resource with a fixed cycle time (door open, level, close, travel, door open again), and a robot that misses its call holds the entire queue behind it, so even a 10-15 second cabin dwell compounds into minute-scale floor wait when several AMRs converge on one shaft [S1].
Vertical handoff is the one place where an AMR physically surrenders motion control to a non-robotic subsystem, which means the robot cannot self-recover from a missed call, a blocked door, or a passenger override, and the fleet manager must treat the elevator as a black-box resource with hard reservation semantics rather than as another lane on the floor map [S1][S2].
Magazino recommends avoiding elevator transport entirely when the layout allows a single-floor, ground-level layout, and limiting it to multi-floor brownfield retrofits where no greenfield re-routing is possible, which lines up with the IFR 2024 case study in which elevator-calling AMRs were deployed only because the front section of the battery plant forced vertical transfer [S1][S5].
For greenfield plants, the practical guidance is to relocate mezzanines, dock points, and battery chargers so the AMR fleet can stay on a single elevation; for retrofit, the design trick is to add a pre-elevator staging buffer so the robot commits to the call only when the car is verified empty, a pattern that holds for IFR-cited deployments and that fits the IPLUSMOBOT CLOUDIA fleet architecture [S1][S5].
Doors, Shutters, and Air Showers: A Second Bottleneck Class
Roller shutters and air-shower doors impose a fixed cycle time of their own: an air-shower door typically locks for 10-30 seconds of decontamination cycle, and during that window the AMR must hold position without entering, which is the same wait-then-surge problem the elevator creates, just at floor level [S5].
IPLUSMOBOT's 2024 case study describes AMRs that "communicate their status in real-time with equipment like air shower doors, elevators, and buffers," and that pass through "more than ten air shower and roller doors" in a single route, which means the cumulative dwell across one mission is the sum of every door's cycle time, not just the longest one [S5].
The fix is a hard interlock contract: a single digital I/O or OPC UA handshake per door, owned by the fleet manager, so the robot never initiates a crossing on a stale "open" state and so a faulted door fails the route, not the robot [S2][S5].
Where multiple vendor fleets share a doorway, the interlock must be exposed at traffic-management level rather than per-robot, because each brand's fleet manager traditionally cannot talk to another's door controller, which is the same interoperability gap that motivates the MassRobotics AMR Interop standard and the Open-RMF read-only adapter discussed below [S3][S6].
Fleet-Manager Behavior That Actually Clears Queues
OTTO's 2026 integration notes frame AMR handoffs as a relay race, and the three legs that decide throughput are: the right mission trigger at the right time, prioritized queue management so jobs do not starve each other, and exception handling that reassigns available robots when a destination is occupied, a pallet is missing, or priorities shift [S2].
Fives' GENI-Ant AMR Sorter Traffic Management System explicitly states it can "change routes in the event of bottlenecks" and "reassign tasks from non-operating to operating AMRs," which is the minimum capability a 2026 spec should require from a fleet manager when the elevator or door is the slow link [S4].
For queue management, the spec should require job allocation, mission sequencing, and traffic management as named features, not as bundled marketing terms, because without those three primitives the fleet will fall back to first-come-first-served dispatch and idle robots will sit while queued missions wait [S2].
For exception handling, the spec should require continuous re-evaluation of fleet status rather than a fixed path from start to finish, which is the only way to keep materials moving when a door fault or elevator outage breaks the planned sequence [S2][S4].
Interop Standards So Different Brands Do Not Collide at the Door
Interoperability matters at bottlenecks because the worst congestion happens when two fleets from two vendors converge on a single elevator lobby or doorway, and their fleet managers cannot natively share state [S3].
The 2025 Open-RMF discourse thread documents that "AMRs that are compatible with the MassRobotics AMR Interop standard could be exposed to Open-RMF as read-only traffic participants," which gives multi-vendor sites a workable pattern: one traffic authority, many robots, none of them owning the bottleneck [S6].
ANT Driven's 2023 framing of the three interoperability paths (shared spaces with interlocks, native compatibility, and full standards-based interop) is still the cleanest decision tree, and a 2026 spec should at minimum require shared-space interlocks and a documented upgrade path to MassRobotics AMR Interop or Open-RMF, even if full standards compliance is deferred [S3].
The cost case is concrete: multi-fleet sites without interop typically run separate virtual paths, pay for separate fleet-manager licences, and need custom code at every cross-path, which is why the platform-first, vehicles-second procurement posture is gaining ground in 2026 [S3].
Selection Criteria for a 2026 AMR Door-and-Elevator Stack
A spec that holds up in 2026 should be graded against four decision criteria, each of which lines up with a documented failure mode in the research: elevator avoidance, hard door interlocks, queue-aware dispatch, and interop exposure [S1][S2][S3][S5][S6].
Elevator handling: avoid unless multi-floor brownfield forces it, and if forced, require a pre-call staging buffer plus a floor-availability check before commit, because the cabin is a single shared resource and the queue behind it is the real cost [S1][S5].
Door and shutter handling: require a per-door interlock handshake owned by the fleet manager, with explicit fault state, so an AMR never crosses on a stale "open" signal and the fleet can reroute before the robot reaches a faulted door [S2][S5].
Dispatch and queueing: require job allocation, mission sequencing, and traffic management as named features, with documented exception handling that reassigns robots when conditions change rather than freezing on the original plan [S2][S4].
Interop: require shared-space interlocks at minimum, with a documented path to MassRobotics AMR Interop or Open-RMF read-only traffic participation, because two-vendor sites converge on the same elevator and door nodes whether or not the fleets are designed to [S3][S6].
Who This Fix Is For, and Where It Does Not Apply
This bottleneck pattern is for production-logistics AMRs that share an elevator, a roller shutter, or an air-shower door with humans or with another vendor's fleet, which covers most 2026 greenfield and brownfield deployments above 5-10 robots in a single hall [S1][S3][S5].
It is not for single-floor, single-vendor, single-aisle cells where the robot never leaves its own lane, because the elevator and door nodes simply do not exist there, and the cure is wasted scope [S1].
It is also not a substitute for floor-condition and KLT sizing work; Magazino's own pathway series treats route length, source-sink planning, and floor quality as preconditions, and a fleet manager cannot rescue a layout that funnels every robot through one doorway every cycle [S1].
Buyers building a fresh spec should pair this bottleneck guidance with the 2026 AMR fleet size calculation method and the 2026 AMR unit price and fleet software cost breakdown, so the elevator/door latency budget is sized against the same fleet headcount and software cost model that pays for it.
Limits, Failure Modes, and Open Questions
Elevator avoidance is a layout recommendation, not a fleet-software feature, and on a constrained brownfield site the only honest answer may be "the robot will wait," which means the queue and the dwell should be priced into the throughput model up front rather than discovered in production [S1][S5].
Door interlocks reduce but do not eliminate dwell, because an air-shower cycle of 10-30 seconds is a fixed cost per crossing, and a route that crosses ten such doors will spend 100-300 seconds per mission in forced waits regardless of fleet-manager intelligence [S5].
Standards-based interop is still maturing: the Open-RMF read-only adapter is documented as a 2025 proposal, and MassRobotics AMR Interop compliance varies by vendor, so a 2026 spec should require the path to compliance without promising the compliance itself [S6].
Watch, as the next verifiable signal, for vendor disclosures of MassRobotics AMR Interop conformance tied to specific elevator-call APIs, and for any IFR or vendor case study that publishes quantified door-cycle dwell per mission, which is the metric that turns this guidance from qualitative advice into a procurement threshold.
Detailed specification references: energy management, and construction machinery and equipment.