From a pilot to the whole floor
A pilot shows that one fleet in one zone can draw from a pool. Taking it to the whole floor means more fleets, vendors, tasks, and readers of the record, on a pool configured for the destination from the start.
· 4 min read
IN SHORT
A pilot runs one fleet in one zone on a pool inside the building, with safety on the robot and the record kept on site. Going to the whole floor means joining more Czar nodes, connecting each new fleet under its own latency budget, approving new tasks in Agency Studio, and widening the roles that read the record. The subscription line does not move as robots are added.
Pilots fail to become production for a familiar reason. The pilot was built on something temporary, the record was kept somewhere informal, and the fleet that proved the idea was the only one the pool ever learned to serve. When the automation lead asks to take it to the whole floor, the answer is a second project rather than an expansion. A Grid pilot is designed so that the answer is an expansion, and this article describes the path from the first zone to the last.
Start on the destination
The most important decision happens before the pilot, in the proposal. The Grid is configured against the floor it will eventually serve: every fleet planned for it, every model those robots will ask for, every latency budget, and the posture the site chooses. The pilot then runs on that same configuration, in one zone, with one fleet.
One Czar is a pool for a small floor, and it is often the right size for a pilot zone. But it is the same sealed, attested node that will be joined with others into the facility's Grid. The posture is already chosen: air-gapped with signed bundles carried in, or connected only to the systems the site declared. The record is already on the operator's hardware. Nothing about the pilot is a mock-up of the real thing. The Czar page describes the node the pilot runs on.
What the pilot has to show
A pilot has a short list of things to demonstrate, and they are the same things the safety officer will want to see before signing off on the next zone. The pilot fleet's perception, decision, or language requests are served within the budget the vendor set. When the pool is busy or paused, the robots fall back to their on-board models as described, and a robot that cannot get an answer stops rather than guesses.
The pilot's site tasks were authored in Agency Studio, bounded by zones and speeds and stops, approved by named roles, and recorded. The record can be opened and a run replayed by someone who was not on the floor when it happened. That record is the evidence for expansion. It is not a slide; it is the thing an auditor could read.
Adding the second fleet
The first real test of the pool is the second fleet, especially when it comes from a second vendor. The integrator and the vendor set that fleet's latency budget and its fallback boundary. The pool now serves mobile robots from one vendor and pick arms from another, each under its own budget, from the same Grid.
This is where a pool built on a single vendor's compute would have to be rebuilt. A neutral Grid simply takes on another fleet. The declared routes in Local Bridge grow by whatever the second fleet's software needs and nothing more. The record now shows two fleets' runs, read by the same named roles. The solutions page describes how warehouses, plants, and ports each tend to add fleets.
Growing the Grid
As zones are added and the floor fills, the configured Grid may call for more Czar nodes to be joined. Each new node arrives sealed with a signed, read-only image, attests what it is running before it joins the pool, and carries its own provenance record. The pilot node is not retired; it is one of several, and the Grid is still Czar.
Adaptation starts to matter here. Models fine-tuned on the pool, on the site's own captures, improve the floor's perception and decisions for every fleet that draws from them, and the adapted weights never leave the building. A floor that has been running for a while on its Grid has a pool shaped to that floor, which is something no pilot on temporary compute could have produced.
The line does not move
Through all of this the commercial form stays put. The subscription is one line for the configured Grid: hardware, platform license, and sustainment, fixed for the term. Adding the second vendor's fleet did not move it. Adding humanoids to the plant floor did not move it. If the proposal configured the Grid for the whole floor, the pilot and the production floor sit on the same line from the start.
That is the practical meaning of starting on the destination. The pilot's budget conversation is the floor's budget conversation, held once. The How to buy page describes the routes by which a site holds that line.
Questions this raises
- Should a pilot use a smaller or different appliance?
- No. A pilot runs on Czar, which is the only appliance. One Czar is a pool for a small floor, which is often the right size for a pilot zone. When the floor grows, more Czars are joined into a Grid; the pilot node is not replaced.
- What should a pilot prove before the floor expands?
- That the pilot fleet's requests are served within its latency budget, that fallback to the on-board model behaves as the vendor described, that tasks were bounded and approved by the named roles, and that the record of every run can be read and replayed by the people responsible for the floor.
- Does the subscription change when the pilot becomes the whole floor?
- The subscription is for the configured Grid. If the proposal configured the Grid for the whole floor from the start, adding fleets and zones does not change the line. If the pilot was configured as a smaller Grid, growing it is a reconfiguration described in the agreement, not a per-robot charge.
KEEP READING