Teleoperation and the facility pool

Behind most humanoid deployments today there is a person at a screen. When the robot reaches a situation it cannot resolve, it asks for help, and the person takes over for a moment, guides it through, and hands control back. Vendors call this teleoperation, or intervention, or supervision. It is honest engineering, and it is not going away. A facility pool does not try to make it go away. It changes the three things around it that matter to the site: how often it happens, where the session goes, and what the floor keeps afterward.

How often a person is needed

A robot asks for help when its own model is not confident. The on-board model is small, because the robot is small, and a small model is uncertain often. Most interventions are perception and decision failures: the robot could not tell what an object was, could not work out where to grasp it, or could not parse what it had been asked to do.

Those are the questions a Czar Grid exists to answer. With a larger perception, decision, and language model in the building's rack, the robot can ask the pool before it asks a person. Within its latency budget it gets an answer from a model it could not carry, and a situation that would have been an intervention becomes an ordinary step. The person is still there for the cases that remain, and there will be cases that remain. There are fewer of them.

Where the session goes

Teleoperation is the vendor's system. The link between the robot and the person is something the vendor built, and the pool does not carry it. What the pool does control is whether that link is allowed to leave the building.

Under Local Bridge, Substrate's governed connectivity, only declared routes are permitted and egress is denied by default. If a vendor's teleoperation runs from the vendor's own remote operators, the site has a decision to make: declare that route, with its terms, or decline it and put the person at a station inside the building. Both are legitimate. The point is that the camera feed of a robot in the site's own building goes to a remote screen only because the site said so.

An air-gapped site has already answered this. The pool has no path out, and teleoperation, if the site uses it, happens from inside. A connected site that has declared a route to the vendor's fleet software has not thereby declared a route for remote teleoperation; that is a separate route and a separate decision. A connection is a decision, not a default.

What the floor keeps

Every intervention is a lesson. The robot could not do something, a person showed it how, and the robot did it. On most deployments that lesson goes to the vendor, if it goes anywhere, and returns to the floor as a model update on the vendor's schedule.

On a floor with a pool, the intervention is a capture, and the capture stays on the operator's hardware. Substrate can adapt the shared model on captures from the floor, on the pool, with nothing leaving the building. The next robot to reach that situation asks a model that has, in effect, watched the person handle it. The learning stays local and serves every robot on the pool, from any vendor.

The record holds the rest. For each run, the record shows what the robot asked, what the pool answered, where the robot fell back, and where a person intervened. A site reviewing a shift can see where its robots needed help and whether the same situations keep coming up, which is a better guide to what the pool should learn next than any dashboard a vendor could provide from afar.

What does not change

Safety does not change. During a teleoperated session the robot is still inside the stops, speed limits, reflexes, and motion limits its vendor shipped, exactly as it is when acting on its own model or on a pool answer. The pool is not in that loop at any time, and a person at a screen does not put it there.

The vendor's ownership does not change either. The vendor built the teleoperation system and keeps it. The pool asks nothing of it except, where the site chooses, a declared route. For what else stays the vendor's, see what a robot vendor keeps when a site adds a pool.

A quieter screen

The goal is not a floor with no person at a screen. It is a floor where the person is asked less often, where the session they join stays where the site wants it, and where every time they help, the floor gets a little better at not needing them for that particular thing. That is what a pool offers teleoperation: not a replacement, but a smaller queue and a longer memory, both kept on site. For the humanoid case specifically, see serving humanoids from the rack, not the backpack.