Tasks that hand work from one vendor's robot to another's

Consider an ordinary job on a fulfillment floor. A mobile robot brings a tote to a pick station. A pick arm takes the item out of the tote and places it in an order carton. A humanoid collects the finished carton and carries it to the outbound lane. Three robots, very often three vendors, one job. Today that job exists nowhere as a single thing. It is three separate tasks in three separate systems, stitched together by the integrator with conveyors, sensors, and hope.

Agency Studio exists to let the site write that job down once.

One task, several robots

Agency Studio is the task layer on a Czar Grid. A site task authored there describes the work as the site sees it, not as any one vendor sees it: the tote arrives here, the pick happens here, the carton goes there. The steps that belong to different vendors' robots sit in the same task, and the handoffs between them are explicit steps rather than accidents of timing.

The task does not tell a robot how to move. Each vendor's robot carries out its step under its own software and its own on-board model, asking the pool for perception and decisions where its vendor built it to. What the task provides is the shared description of the job, the bounds on it, and the record of each run.

Bounded before it runs

Every site task in Agency Studio is bounded. The author sets the zones the task may use, the speeds it permits, the distances it allows between a robot and a person or a fixture, and the stops that apply. A handoff step between a humanoid and a pick arm can be bounded to a particular cell at a particular speed with a stop condition if anything else enters the zone.

These bounds sit above the vendors' safety envelopes, not in place of them. Stops, speed limits, reflexes, and motion limits stay on each robot as the vendor shipped them. The task can only ask for less than the robot allows, never more. A task that asked a robot to exceed its own envelope would simply be refused by the robot, and the bounds make sure the site never writes such a task in the first place.

Versioned and approved

A task is versioned, and a version runs only after named roles have approved it. For a task that spans vendors, that usually means more than one signature: the safety officer for the handoff zone, the automation lead for the sequence, the area supervisor for the shift. The record shows who approved which version and when.

This matters most when the job changes. A new carton size, a moved pick station, a humanoid replacing a person at the outbound lane: each is a new version, reviewed and approved, and the previous version remains on the record. The floor always knows which version of the job it is running and who said it could.

Every run on the record

Each run of a site task is recorded and replayable. For the job above, the record shows the mobile robot's arrival, the arm's pick, the handoff to the humanoid, and the carton's departure, with what each robot asked the pool, what the pool answered, and where any robot fell back or stopped.

When a handoff goes wrong, the site can replay it. It can see that the arm placed the carton slightly outside the zone the humanoid expected, or that the humanoid's question to the pool was late and it fell back, or that a person entered the zone and the stop fired as designed. That is a very different conversation from the one most floors have today, in which three vendors each produce a log that shows their own robot behaving correctly.

The record stays on the operator's hardware inside the operator's network. Camera frames, task records, and the replay itself never leave the building.

The vendors' place in it

A vendor whose robot takes part in a cross-vendor task gives up nothing. Its fleet software still runs its robots, its safety case is untouched, and the task layer exchanges anything with the vendor's systems only over routes the site declared. What the vendor gains is a customer who can describe the whole job, bound it, and prove what happened, which makes the vendor's robot easier to deploy alongside everyone else's.

Some integrators will author these tasks as part of delivering a floor, and some will ship the Grid under their own name as Czar Chassis with the tasks already written. The task layer is the same either way. For how this fits across the floor, see mixed-vendor fleets on one floor and the technology overview.