Skip to content

TECHNICAL PREVIEW · IN ACTIVE DEVELOPMENT

ALL NOTES

DEPLOYMENTS

Warehouse fleets and the coordination ceiling

Fulfillment is the archetype that puts the most machines in the least space, so the binding constraint is coordination cost rather than connectivity. Coordination scales badly, and where it stops scaling is set by how fresh the fleet's shared picture is.

· 7 min read

Of the environments that want robot fleets, fulfillment packs the most machines into the least space. Mobile robots, lifts, conveyance, people, and the goods themselves share a floor laid out for throughput rather than for traffic. That density, not connectivity, is what makes the archetype distinctive. A warehouse usually has a serviceable network. It has a harder problem than a network.

The problem is that machines in a shared space are not independent. Two robots in separate buildings can be reasoned about separately. Two robots in the same aisle cannot, because each one's plan is a constraint on the other's. Add a third and there are three pairwise relationships to keep consistent, and the count of interactions climbs faster than the count of machines. Interactions, not machines, are what has to be resolved before anyone moves.

So a fleet has a ceiling. Capacity does not scale with machine count, because every machine added brings both a unit of work and a share of coordination overhead, and the overhead term grows faster than the work term. Above some density, the next robot on the floor makes the floor slower.

Where the ceiling comes from

Coordination is not free-floating. It is resolved against a shared picture of the space — where the machines are, where they intend to go, what is blocked, what is reserved, what changed in the last few seconds. Every decision a machine makes about motion is a decision made against that picture, and the picture's quality is bounded by how recently it was updated and how widely that update has been agreed.

Staleness converts directly into conservatism. A machine that cannot be confident about what a neighbor is doing must behave as though the worst plausible thing is true: slow earlier, yield sooner, keep a wider berth, hold a reservation longer than it needs. Each of those responses is individually correct and collectively expensive, because they all consume the resource the building is actually short of, which is floor. Margin is measured in space, and space in a fulfillment building is the thing that was already optimized away.

That gives the ceiling a mechanism rather than a mystery. The freshness of shared state determines how tight the margins can safely be; the margins determine how many machines fit in an aisle while still moving; the number of machines moving is the throughput. Coordination latency is not an abstraction here. It is floor area, spent.

Distance does not merely add delay

The consequence for architecture is sharper than the usual argument about round trips. Putting the shared picture behind a wide-area link does not add a constant to every decision. It lowers the ceiling.

The reason is that margins have to cover the worst case, not the typical one. A shared picture served from somewhere far away has an update interval whose tail is governed by things the building does not control, so every machine has to plan as though the picture might be older than it usually is. The fleet then operates permanently at the conservatism appropriate to its worst moment. The control-loop version of this argument — that the tail, not the average, is what disqualifies a network round trip — is well worn. The fleet version is less discussed and arguably worse, because it does not present as a failure.

That is the trap. A coordination layer that reaches offsite rarely breaks; it just quietly makes the building slower, in a way that looks like the fleet being unimpressive rather than the architecture being wrong. Nobody files a ticket for margin. And the network budget that would pay for a better link has usually been committed already, to the systems that were in the building first.

The building will not hold still

The second particular of this environment is that the site's own definition keeps changing. Layouts shift with the season, with a product mix, with a promotion, with a customer won or lost. Pick faces move. Aisles get narrowed to fit more racking, then widened again after a peak. Packaging changes shape, which changes how a thing is picked, how it stacks, and whether it can be seen.

This is fatal to the idea of commissioning as a one-time event. A fleet tuned to a building in one configuration is tuned to a building that will not exist next quarter. The site-specific learning problem — the long tail of this floor, this lighting, this pallet dialect — never converges, because the target moves at roughly the rate the learning does.

Worse, the changes are not announced to the software. They are announced to the floor, with tape and a forklift. Whatever adaptation the system does has to be continuous, has to run on what the fleet observed rather than on what a configuration file claims, and has to happen on the operator's clock. A learning loop that requires exporting the day's data and waiting on someone else's schedule is structurally incapable of tracking a building that changes faster than the loop closes.

Everything worth having is shared

Spatial deconfliction gets the attention, but a warehouse fleet also contends for discrete resources: chargers, lifts, dock doors, induction points, the good aisle at the busy end of the building. These allocations behave differently from path planning, and they behave worse.

A charger queue has a deadline attached. A machine that waits too long for a charger does not simply wait; it strands, and a stranded machine is an obstacle in the space the rest of the fleet is trying to use. The resource contention creates the spatial contention. Priority inversion in this environment has mass — a low-value task holding a lift blocks a high-value task that cannot route around it, and the fleet's response to being blocked consumes the capacity that would have relieved the block.

Getting these allocations right requires a scheduler that sees the whole building and can act on the current state of it. That is a facility-scoped problem by construction. It is not something an individual machine can solve from its own vantage point, and it is not something that tolerates being answered from far away, because the answer is only correct for as long as the state it was computed against holds.

The score is public and the data is not

Two more properties shape what is acceptable here. The first is that throughput in a fulfillment building is measured continuously and watched by people whose compensation depends on it. There is no quiet period during which a new system can be mediocre while it learns. Any degradation is visible within a shift, attributed quickly, and remembered. That argues for a system that is additive from the first day and that fails toward the building's existing behavior rather than toward a stop.

The second is that the data describing all of this is commercially sensitive in an ordinary but serious way. Order flow, inventory position, and pick rates describe what a business is selling, how fast, and how well it runs. Video of the floor shows the layout, the process, and the people. Much of this belongs to the operator's own customers under terms that were negotiated before any robot arrived. The practical effect is the same as in industries with statutory constraints: the useful data exists in a place it is not permitted to leave, and the compute that wants to learn from it has to stand there.

The part that is not solved

The honest position on this archetype is that the ceiling is real and we have not proved where it sits. Coordinating a modest number of machines against one onsite plane is tractable. Keeping the worst-served machine inside its timing bound, rather than the average one, as the fleet grows and the floor gets tighter, is an open problem — and average-case coordination is not a useful answer when the machine that misses its window is the one that becomes an obstacle. Admission control, degradation order under contention, and what the fleet should do as it approaches the ceiling rather than after crossing it are active design questions.

What the constraint does settle is placement. The shared world model and the scheduler belong onsite, on the building's own switches, where the picture can be refreshed at the rate the floor changes. Per-machine autonomy belongs on the machine, so a robot that loses the plane degrades to cautious independence rather than to stationary. Adaptation belongs inside the boundary and has to run continuously, because the building it is adapting to is being rearranged while it runs. E31 Network is being built around that division, with the ceiling treated as the thing to raise rather than a number to quote.

DESIGN PARTNER PROGRAM

Build this with us.

We are working with a small number of teams operating real fleets in constrained environments. If the cloud is not an option where your machines work, we want to talk.