Day two: operating the pool

Once the installers leave, a Czar Grid stops being a project and becomes a fixture, like the conveyor controller or the fleet manager. The automation team owns it. The daily work is unglamorous and that is a feature: read the record, look at the fallbacks, approve what needs approving, and go back to the floor.

This article describes that routine as it runs on an ordinary site. There is no outside operations center involved. The pool serves the building and reports to the building.

The morning read

The shift begins with the record. Substrate writes down what the pool did: which robots asked, what they asked for, which model answered, and whether the answer arrived inside that robot's latency budget. Agency Studio writes down every task run alongside it. All of this is on the operator's hardware and readable by the operator's people.

The morning read is a scan, not an audit. The lead looks for anything that changed shape overnight: a fleet that fell back more than usual, a task version that ran for the first time, a node whose integrity check deserves a second look. Most mornings the scan finds nothing, and the lead notes that it found nothing, because a record that says "clean" is worth as much as one that says otherwise.

Reading fallbacks correctly

Every robot on the pool keeps its own on-board model and uses it when the pool does not answer in time. Those events appear in the record as fallbacks. New operators sometimes read them as failures. They are not. A fallback is the design working: the robot had a budget, the pool missed it, and the robot did what its vendor built it to do, which is to carry on with its own perception or to stop.

What operations does with fallbacks is look for patterns. A single fleet falling back at the same hour each day suggests a load question worth raising with the integrator. Fallbacks spread evenly across every fleet suggest a pool question. Fallbacks from one robot alone usually point back at that robot's network drop or its own configuration. The record makes these distinctions readable without anyone guessing.

The approval queue

On floors where tasks change, the second block of work is the queue in Agency Studio. A task is authored, given a version, and bounded by zones, speeds, distances, and stops. It does not run until a named role approves that version. On most sites those roles include the automation lead and the safety officer, and on sites with an integrator in residence, the integrator as well.

The operator's job here is judgment, not clerical work. Approving a version means reading what changed between it and the one running now, checking that the bounds still match the floor as it is today, and signing. The signature is recorded with the version. Later, when someone asks why a robot did a particular thing on a particular afternoon, the answer is a version number and the name of the person who approved it. Approvals, named roles, and versions covers this in more detail.

Integrity and the end of the shift

Watchman verifies the integrity of what each node is running. Operations does not need to understand how it does that; they need to know that it reports clean or it does not, and that the result is in the record. A node that cannot verify its image does not serve, and the rest of the Grid continues while the site decides what to do about it.

The shift ends the way it began, with a note in the record. The lead writes down anything the next shift should know: a task version approved, a fleet that needs watching, a fallback pattern that has not yet been explained. The next morning, someone opens that note and begins again. That cycle, more than any single feature, is what operating the pool means. The night's record and what to do with it is the subject of the run record and the next morning.

What day two does not involve

It does not involve a vendor's cloud, a telemetry stream, or a dashboard hosted elsewhere. The pool does not phone home. If the site chose a connected posture, the pool reaches only the systems the site declared, and those connections are for serving robots, not for reporting on them. If the site chose air-gapped, there is no path out at all.

It also does not involve Element 31 unless the customer decides it should. Support sessions are customer-initiated through the portal, and on sovereign sites they happen only inside an approved window with a hard expiry. On an ordinary day, nobody outside the building is watching, and that is the operating model, not a gap in it.