Skip to content
ELEMENT 31

Running a humanoid pilot inside the plant segment

A humanoid pilot succeeds or fails on its bounds. Here is how a plant runs one on an inference pool inside the plant segment, with tasks bounded, approvals named, and every run on record.

· 4 min read

IN SHORT

A humanoid pilot inside the plant segment runs on the pool the plant already controls: Czar in the plant's own rack, connected only to the robot vendor's fleet software and the systems the plant declares. Tasks are authored in Agency Studio with zones, speeds, distances, and stops, approved by named roles, and recorded run by run, so the pilot ends with a record rather than an impression.

Humanoid pilots have a way of ending without a verdict. The robot walked, it carried a kit, people took video, and at the end nobody could say with confidence what it had done, how often, within what limits, or whether it should stay. The missing piece is almost never the robot. It is the bounds and the record.

Running the pilot on an inference pool inside the plant segment fixes both. The pool is the plant's own, in its own rack, under its own posture. The task the humanoid performs is written down, bounded, and approved before the first run. And every run is recorded and replayable, so the pilot ends with evidence.

Pick a zone, then write it down

A pilot starts with a zone the safety officer has walked. A supermarket area, a kitting cell, a line-side delivery route between two stations. The zone is where the humanoid may be and nowhere else, and it is drawn before anything is powered on.

In Agency Studio, that zone becomes the first bound on the task. The others follow: the speeds the humanoid may move at in each part of the zone, the distances it keeps from people and from running equipment, and the stops it observes. Those bounds are the plant's statement of what the pilot is, and they are versioned, so when the plant widens them in a later phase, the change is on record too.

What the pool serves and what it does not

The humanoid arrives with its own on-board model for reflexes and balance and with its vendor's safety behavior: stops, speed limits, motion limits. None of that moves to the pool. The Czar Grid serves the humanoid its perception and its decisions: what this part is, where the kit is, whether the aisle is clear, what to do next. It does so over the plant's own network, within the humanoid's latency budget.

When the pool is late or unavailable, the humanoid falls back to its own model or stops, exactly as the vendor built it to. The pilot team walks that fallback with the vendor before the first run, with the pool deliberately offline, so everyone has seen it. A pool that fails leaves a humanoid that stops, not one that guesses.

Approval by a named role

A pilot task does not run because an engineer pressed go. It runs because a named role approved that version of that task with those bounds. In most plants that is the safety officer or an automation lead, and in a plant with a strong controls culture it may be both. The approval is on record with the task version.

That matters when the plant extends the pilot. Widening the zone, raising a speed, adding a second shift: each is a new version, and each needs the same approval. The plant ends up with a lineage of task versions and approvals that tells the story of the pilot in a form an auditor can read.

Reading the record

Every run is recorded: the task version, the bounds in force, what the humanoid saw, what the pool decided, what the humanoid did, and where it stopped. The run is replayable. When a kit was delivered to the wrong station on a Tuesday afternoon, the plant can watch exactly that run and see whether the pool misread the rack, the humanoid misplaced the kit, or the task bound was wrong.

That record is the pilot's output. Not a highlight reel but a set of runs that can be sorted, replayed, and compared. A pilot with two vendors' humanoids on the same pool, doing the same bounded task, produces two records that can be read side by side.

Learning during the pilot

The pilot generates captures: this plant's parts, racks, light, and floor markings, seen by this humanoid. Substrate adapts the perception models on the pool using those captures, on the pool, with nothing leaving the plant segment. The adapted model is evaluated and recorded before it serves the robot, and the plant can see which version served which run.

Those captures and models are the plant's. When the pilot ends, they stay on the plant's hardware. If the plant chooses to continue, it continues on models that already know the floor.

The pilot ends with the record read and a decision made: extend, widen, change vendor, or stop. The pool is unchanged by that decision. It was serving the plant's other robots before the humanoid arrived, and it keeps serving them after. The subscription for the configured Grid did not move when the humanoid joined and does not move when it leaves.

For the commissioning that precedes a pilot, see Bringing a pool into a plant that already runs PLCs and vision. For what the safety officer looks for in the record, see The safety officer and the task record.

Questions this raises

What does the plant need to have before a humanoid pilot can start?
A pool inside the plant segment, a declared route to the vendor's fleet software, a zone the safety officer has walked, and a task authored and approved in Agency Studio. The humanoid's own safety behavior comes from the vendor and is confirmed before the first run.
Can the pilot include humanoids from more than one vendor?
Yes. The Grid serves every robot on the network from any vendor, and each vendor's fleet software keeps managing its own machines. Running two vendors on one pool with the same bounded task is a fair comparison.
What happens to the pilot's data when it ends?
It stays on the plant's hardware. The task records, captures, and any adapted models are the plant's, on the pool, and nothing was sent to a vendor's cloud during the pilot.

KEEP READING