A pool that serves people as well as robots
The pool was installed for the robots. It holds the record, the site's documents, and a language model to read them, which is exactly what the people who run the floor have been missing.
· 4 min read
IN SHORT
A facility inference pool built to serve robots also serves the people who run the floor. The same language model, retrieval over the site's documents, and record of every decision let a supervisor, integrator, or safety officer ask what happened and why, in plain words, on the site's own hardware. People are served in the pool's slack; robots keep the tight budgets.
The pool was installed for the robots. It has the perception, decision, and language models they cannot carry, the record of everything it has served them, and retrieval over the site's documents so that it knows this site rather than a general one. It turns out that this is also exactly what the people who run the floor have been missing.
Who asks, and what
A shift supervisor wants to know which robots hesitated on the inbound dock this morning and whether it was the same aisle as yesterday. An integrator commissioning a new task wants to see what the robots were shown the last time they paused at the mezzanine door. A safety officer wants a plain account of why a humanoid set a part aside. A new operator wants the procedure for a damaged pallet without finding the binder.
Each of these is a question about the floor, and each is answered from things already on the pool: the record of every decision, the site's own documents, and a language model to read them. None of them requires anything to be added. They require the pool to be reachable by a person at a terminal on the site network, which it is.
The same model, the same record
The language model that reads work orders for robots reads the record for people. Asked why a robot took the alternate route, it retrieves the entries for that robot and that time, finds the perception answer that described the blocked aisle, the decision that chose the alternate, and the task version that permitted it, and renders them as a short explanation. The entries remain underneath for anyone who wants the full record.
Retrieval over the site's documents does the rest. Asked for the damaged-pallet procedure, the model finds the site's own procedure, not a general one, and reads from it. The documents are on the pool, held like everything else on the operator's hardware. A site that has written down how it works now has a way to ask.
Budgets keep robots first
A reasonable worry is that people's questions will slow the robots. They do not, because of how Substrate schedules. Every request has a latency budget, and a person waiting at a terminal has a far looser one than a humanoid mid-step or a mobile robot approaching a doorway. The pool serves tight-budget requests first and fills the slack with everything else.
So a supervisor asking a long question at the busiest hour gets an answer slightly later than at a quiet one, and no robot notices. The pool has the same capacity either way; people are using the part of it the robots were not using at that instant.
Nothing new leaves the building
A person's question to the pool carries the site's operational detail: what is on the floor, what went wrong, what the procedure is. Sending that to a vendor's cloud is the thing many sites will not do, and the reason a general assistant was never adopted on the floor. On the pool, the question goes from the terminal to the rack and back. On an air-gapped site there is no path out; on a connected site the only routes are the ones the site declared.
The record of people's questions sits beside the record of robots' requests, on the same hardware, under the same rule.
What people cannot do from the pool
Serving people does not make the pool a control surface. A person can ask what a robot did and why. A person cannot, from the pool, tell a robot to do something different. Site tasks are authored, versioned, bounded, and approved by named roles in Agency Studio, and changing a robot's behavior goes through that layer and its approvals. The robot's stops, speed limits, and motion limits stay on the machine regardless.
This is the right division. The pool is where the floor's knowledge is, and it should be readable by the people who run the floor. What the robots will do next is a decision with authority behind it, and it lives where authority is recorded.
A Czar for a small floor and a Czar Grid for a facility both serve people in this way. It is a use of the pool rather than a feature added to it. For the language model that makes it possible, see Language models on the facility network.
Questions this raises
- Does serving people require a separate system?
- No. The same pool, running Substrate, serves robots and people. People use the language model and retrieval over the record and documents that are already on the pool, and the Czar or Grid that serves the floor serves them too.
- Can a person's question slow down a robot?
- No. Substrate schedules against latency budgets, and a person at a terminal has a far looser budget than a robot mid-step. Robot requests are served first and people's requests fill the remaining capacity.
- Can a person use the pool to change what a robot does?
- Not from the pool. Site tasks are authored, bounded, and approved by named roles in Agency Studio, and the robot's safety functions stay on the machine. A person can ask the pool what a robot did and why; changing what it will do goes through the task layer and its approvals.
KEEP READING