Adding a vendor's fleet to an existing pool

The second vendor is where a facility learns whether it bought a pool or a point solution. A Czar Grid is one pool for the whole building, and the robots it serves can come from any vendor: the mobile robots that were there first, the pick arms installed later, the humanoids a third vendor is piloting on one aisle. Bringing a new fleet onto a running Grid is therefore a procedure the automation team should expect to repeat, and it should feel routine by the second time.

Start with what the fleet needs to reach

The first question is whether the new fleet's software needs a route. Many fleets talk to the pool directly over the facility's network, robot to Grid, and need nothing else. Some have fleet software that the pool should see, for context or for task handoff. If so, that route must be declared.

Local Bridge admits only declared routes and denies everything else. On a connected site, the integrator proposes the route, the automation lead approves it, and both are recorded. On an air-gapped site, the answer is usually that the fleet software, if it exists, lives inside the isolated segment too, and the route is declared within it. Either way, nothing is opened by default because a new vendor arrived.

Set the budgets

Every robot on the pool has a latency budget: the time within which an answer is useful to that machine. The new vendor knows its robots best and should say what those budgets are. A mobile robot navigating a busy aisle and an arm at a fixed station do not need the same thing, and Substrate serves each against its own budget rather than a site-wide average.

Budgets are also where fleets are protected from each other. Because the record shows budgets met or missed per fleet, the site can see on the first shift whether the new load is changing anything for the fleets already running. If it is, the conversation with the integrator is specific and grounded rather than a general complaint that things feel slower.

Point the robots at the pool

The robots keep their on-board models. They keep every stop, speed limit, and motion limit their vendor built in. The only change is that for perception, decisions, and language they ask the pool first and fall back to their own model when the pool does not answer in time.

This is why onboarding carries no safety change. The vendor's safety case is untouched. A robot that cannot reach the pool on its first afternoon behaves exactly as it did the day before the pool existed. The safety officer's involvement at this step is to confirm that nothing about the robot's own limits has been altered, and the vendor should be able to state that plainly.

Watch the first shift and bound the first tasks

The automation team reads the record during and after the new fleet's first shift. The questions are simple. Did the fleet ask the pool. Did the pool answer within budget. When it did not, did the robots fall back cleanly. Did any existing fleet's pattern change.

Most onboardings produce an unremarkable record, which is the goal. When something does appear, it is usually a network path for one robot, a budget set too tight for the aisle it works, or a route that was needed and not declared. All three are visible in the record and all three are fixed by the people already on the floor.

If the new fleet will run site tasks through Agency Studio, those tasks are authored, versioned, and bounded like any other, and approved by the named roles before they run. A task written for one vendor's mobile robots is not automatically right for another vendor's, because the bounds depend on the machine's size, speed, and reach. The safety officer reads the bounds with the new vendor present and signs when they match the floor. Every run is then recorded and replayable regardless of whose robot ran it.

What does not change

The subscription does not change. It is for the configured Grid, fixed for the term, and more robots on the pool do not move it. The posture does not change; a site that runs air-gapped stays air-gapped, and a connected site reaches only what it declared. The record does not fragment; the new fleet's runs and requests join the same local record as everyone else's, which is what makes a mixed floor readable.

What the site gains is one place where all its robots' perception and decisions are served and recorded, whichever vendor built them. That is the practical meaning of a pool, and the procedure above is how it grows. For how the people involved divide this work, see who operates the pool.