Serving humanoids from the rack, not the backpack

A humanoid carries its compute the way a hiker carries water: on its back, in a fixed amount, paid for in weight, heat, and battery. Everything the robot needs to think with has to fit in that allowance. The models that make a humanoid useful on a working floor, the ones that recognize an unfamiliar tote or parse a spoken instruction from a supervisor, do not fit comfortably in that allowance, and they are getting larger, not smaller.

The usual answer is to send the hard questions to a vendor's cloud. For a demonstration that works. For a floor where the robot is standing next to a person and holding a load, the round trip to a distant data center is too long and too uncertain, and the camera feed it carries leaves the building. Element 31's answer is to put the large models in the building's own rack, close enough to answer in time and inside the network the site already owns.

What stays on the robot

The humanoid keeps its on-board model. That model handles reflexes: balance, footing, the fast loop that keeps the machine upright and keeps its hands from closing on something they should not. It also carries the safety envelope the vendor shipped, meaning the stops, the speed limits, and the motion limits. None of that moves to the rack. Czar Grid does not take over the body.

What moves to the rack is the slow, heavy thinking. Which of these boxes is the one on the pick list. What the supervisor meant when she said "the ones that came in this morning". Whether the path across the aisle is clear of a pallet that was not there earlier. These are perception and decision questions, and they are the ones that benefit from a model too large to carry.

What the rack gives back

A Czar is a sealed node in the facility's rack. Several joined together are a Grid: one inference pool for the whole floor. A humanoid on that floor asks the pool for perception and decisions over the facility's own network and gets answers inside the latency budget set for that kind of question. When the pool cannot answer in time, the robot falls back to its on-board model and carries on with what it can do alone, or stops.

That last clause matters. A pool that fails leaves a robot that stops, not one that guesses. The humanoid does not improvise with a half-formed answer; it does what its own safety logic says to do when the better answer does not arrive.

Because the models live on the rack and not in the backpack, the vendor's hardware budget is no longer the ceiling on what the robot can understand. The site can run a larger perception model than any single humanoid could carry, and every humanoid on the floor shares it.

One pool, every body on the floor

Humanoids rarely arrive alone. A fulfillment floor that adds humanoids usually already runs mobile robots and pick arms, often from more than one vendor. The Grid serves all of them. Each robot keeps its own vendor's software and its own safety envelope; the shared part is the pool of models and the record of what the pool was asked and what it answered.

That record is kept by Substrate, the serving system on the Grid. Substrate manages inference across the pool, holds each robot's latency budget, and keeps memory and retrieval over the site's own documents so the humanoid can look up the packing standard for an item rather than guess at it. When the site wants the model to get better at its own totes and its own lighting, Substrate adapts on captures taken on the floor, on the pool, with nothing leaving the building.

Where the feed goes

A humanoid is a walking camera. Where its video goes is a question the site should be able to answer in a sentence. With a facility pool the answer is short: the feed goes to the rack, the rack is in the building, and nothing leaves. Camera frames, captures, task records, and any model weights adapted from them stay on the operator's hardware inside the operator's network.

Whether that rack is air-gapped or connected only to systems the site already secures is a decision made per site. A connection is a decision, not a default. The humanoid vendor's fleet software can be one of the declared routes if the site wants it to be, and nothing else gets a path out.

What this changes for the vendor

A humanoid vendor does not lose anything when a site adds a pool. The vendor still owns the body, the controller, the safety case, and the fleet software. What the vendor gains is a floor where its robots can call on models larger than the body can carry, without routing the customer's camera feed through the vendor's own cloud. Some vendors will choose to ship the pool themselves under their own name as Czar Chassis, so their customer receives one system; others will find it already installed through Facility Direct. Either way it is the same Grid.

For more on how the pieces fit, see the technology overview and the companion article on why safety stays on the robot.