A warehouse manager asked me once how many AGVs they actually needed for a new fulfillment floor. The honest answer was: it depends on things that don't show up on a floor plan — average travel distance per trip, how long each unit sits at a charger, and how many order lines get bundled onto a single run. Buy too few AGVs and pick rates crater during peak season. Buy too many and half the fleet sits idle burning capital. Getting the number right means modeling the fleet as a queueing system, not just dividing floor area by some rule of thumb.
What actually drives throughput
An AGV or AMR fleet's output depends on a chain of variables that all feed into each other. Starting from the layout:
- Warehouse type — e-commerce fulfillment, manufacturing flow, cold storage, and cross-dock all have different travel patterns, pick densities, and dwell times, so the same floor area behaves differently depending on which one you pick
- Floor area — bigger floors mean longer average travel per trip, all else equal
- AGV count — the fleet size you're trying to size in the first place
- AGV average speed — physical travel speed, usually capped well below a vehicle's max rating once you account for turns, congestion, and safety zones
- Picks per AGV per hour — the pick-station side of the cycle, not just travel
- Charging time and battery runtime — together these set how much of a shift each unit is actually available versus parked at a charger
- Lines per order — how many separate pick locations a single order touches, which multiplies travel and handling per completed order
The simulator combines these into a small set of results that map directly onto staffing and capital decisions: average travel distance, cycle time, per-AGV order rate, total fleet throughput, utilization, and AGV density relative to floor area.
Building the model step by step
Average travel distance in a random-destination warehouse scales with the square root of the floor area — this comes out of basic queueing-theory travel-distance approximations used for random storage layouts, and it's a useful mental model even before you touch a simulator: doubling floor area does not double travel distance, it scales it by roughly √2. Cycle time is travel time plus handling time at the pick face, and handling time itself scales with lines per order, since more pick stops per order means more start-stop cycles for the same trip.
Per-AGV order rate falls straight out of cycle time: however many cycles a single AGV can complete per hour, divided by how many lines make up a typical order, gives orders completed per AGV per hour. Multiply that by fleet size and by lines per order again to get total items moved per hour, and you have total throughput. Utilization folds in the charging constraint — an AGV that has to leave the floor for a recharge stops contributing to throughput during that window, so effective fleet output is always somewhat below what a naive full-time calculation would suggest.
A worked example: sizing a fulfillment fleet
Consider an e-commerce fulfillment floor of 8,000 m², running a fleet of 12 AGVs at an average speed of 1.2 m/s, with orders averaging 3 lines each, a charging time of 45 minutes, and a battery runtime of 5 hours between charges.
Start with average travel distance. Using the square-root scaling above with a layout constant appropriate for a random-storage e-commerce floor:
avg travel distance ≈ 0.5 * sqrt(floor area)
= 0.5 * sqrt(8000)
≈ 0.5 * 89.4 m ≈ 45 m
Travel time per leg at 1.2 m/s is 45 / 1.2 ≈ 37.5 s. Add handling time at the pick face — pick, scan, and place overhead per line, times 3 lines — and a realistic cycle time comes out around 95 seconds per completed order.
per-AGV orders/hr = 3600 s/hr / 95 s ≈ 37.9 cycles/hr
Since each cycle here corresponds to one completed order (3 lines bundled into a single run), that's roughly 38 orders per AGV per hour before any charging losses. Across 12 AGVs, raw fleet throughput is:
38 orders/hr * 12 AGVs * 3 lines/order ≈ 1,368 items/hr
Now apply the charging constraint. With a 5-hour runtime and a 45-minute charge, each AGV's duty cycle is:
duty cycle = 5 / (5 + 0.75) ≈ 0.87
So effective utilization sits around 87%, and realistic total throughput lands closer to:
1,368 * 0.87 ≈ 1,190 items/hr
Finally, AGV density — a useful sanity check for whether the fleet is going to start colliding with itself — comes out to:
12 AGVs / 8,000 m² * 1,000 ≈ 1.5 AGV per 1,000 m²
That density is comfortably below the point where most e-commerce floors start seeing congestion-driven slowdowns, which typically shows up above 3–4 AGV per 1,000 m² depending on aisle width and traffic control.
The pick-station side of the equation
Everything above treats the pick face as instantaneous, but in practice picks per AGV per hour is often the real ceiling, not travel speed. If a pick station can only process 40 picks per hour per lane because of a human picker or a fixed-cycle robotic arm, adding faster AGVs or shorter travel distances stops helping once the fleet's arrival rate at that station exceeds what it can process. Queuing at the pick face behaves the same way queuing at an intersection does: average wait time stays low right up until utilization crosses roughly 80%, then climbs steeply for any further increase in arrival rate. This is why a throughput model has to carry picks per AGV per hour as an independent constraint rather than assuming it always keeps pace with whatever the travel-time math suggests. In the worked example above, 38 order-cycles per AGV per hour is only achievable if the pick stations feeding that fleet can actually sustain that arrival rate without queuing — worth checking against the pick-station's own rated throughput before locking in a fleet size.
Where the simple math goes wrong
The hand calculation above assumes every AGV is always productive between charges, which understates congestion. Once AGV density climbs, vehicles start queuing at intersections and pick stations, and cycle time stops being a fixed number — it grows with fleet size in a way that a linear model can't capture. This is exactly why fleet-sizing decisions benefit from a model that sweeps AGV count against floor area rather than picking one number and hoping. Adding more AGVs increases raw capacity but eventually erodes per-unit efficiency enough that total throughput plateaus, or even falls, while density and collision risk keep rising.
A second trap is charging strategy. The example above assumes a single depleted-then-recharge cycle, but many real fleets use opportunistic charging at idle moments, which changes the effective duty cycle substantially. Warehouse type also matters more than it looks: cold storage floors typically run at lower average speeds due to traction and visibility constraints, and cross-dock operations have much shorter average travel distances but far higher pick frequency, so the same floor area and AGV count produce very different throughput numbers across warehouse types.
Try it yourself
Hand math is fine for a rough cut, but comparing warehouse types, AGV counts, and charging strategies side by side is where a simulator earns its keep. The AGV/AMR Warehouse Traffic Throughput Simulator lets you dial in floor area, AGV count, speed, and charging parameters across all four warehouse types and see cycle time, utilization, and AGV density update together, which is a faster way to find the point where adding one more vehicle stops paying off. If your floor also involves manual tow-tractor traffic, the Ackermann steering tool is a useful companion for turning-radius constraints in the same aisles.
