Hospital robots on a pool that keeps the feeds inside

A hospital campus is the most sensitive floor a robot works on. Delivery robots carry specimens, meals, and linen through corridors full of patients and visitors. Disinfection robots work in rooms that were occupied an hour earlier. Pharmacy automation handles medication under a pharmacist's supervision. Each of these usually comes from a different vendor, each carries a small model on board, and each calls its vendor's cloud for the perception it cannot run itself. That means camera footage of wards and hallways leaving the campus several times over, on uplinks nobody at the hospital chose together. A Czar Grid on the hospital's own network answers every robot and keeps the feeds inside.

What moves through the corridors

The fleet on a campus accumulates. A delivery fleet arrives with a logistics project; disinfection robots come later, through infection control; pharmacy and specimen automation is bought by other departments on other timelines. Each robot sees the same lifts, the same doors, the same trolleys left in the same places, and none of them learns anything from the others, because each vendor keeps its own model and its own cloud.

The pool does not ask the hospital to replace any of them. Each vendor's software calls the Grid over the campus network for the models its robots cannot carry, within the time budget each robot has. Safety, stops, and motion limits stay on the robot as the vendor built them; the pool answers questions, it does not drive the machine.

Why a vendor cloud and a GPU on every robot both fail

The cloud fails first on where the footage goes. A corridor camera on a delivery robot sees patients, visitors, whiteboards, and screens, and sending those frames to a vendor's servers to recognize a door is a decision few hospitals would make if asked plainly. It fails second on time. A robot stopped at a lift that is behaving unusually, or at a hand-off with a nurse who is pointing rather than typing, cannot wait on a model in a distant region. It fails third on fragmentation: pharmacy, delivery, and disinfection systems from different vendors share no perception, so the campus is learned several times over and known whole by nobody.

A GPU on every robot fails for reasons of its own. A machine that works in a ward should be small, quiet, and able to run a long shift, and hardware sized for its hardest moment is none of those. The same model is then loaded, updated, and verified on every unit separately, by each vendor in turn.

Delivery robots, one pool, no patient data out

On the Grid, Inference serves the perception and language models the robots need from the hospital's own rack, over the hospital's own network, to any vendor's fleet that asks. The footage a robot sends to be read is read on the campus and stays there. Adaptation tunes the shared models on the campus's own corridors overnight, so this hospital's signage, trolleys, and door hardware are learned once for every fleet. Evaluation checks each adapted model against a held-out set of the hospital's own images before it is served.

Local Bridge permits only the routes the hospital declares: the dispatch or transport system, the vendors' fleet software, and the lift and door controllers if the hospital chooses to connect them, and denies everything else by default.

Decisions in a corridor the robot can't read

The moments that matter are the unfamiliar ones. A ward is reconfigured after a refit and the map on board no longer matches. A lift stops short of its floor. A nurse at a hand-off says something the robot needs to understand before it releases a drawer. The small model on the robot cannot resolve these, and today the robot either waits on a distant cloud or stops and calls for a person.

A larger model on the pool resolves them inside the time budget the robot has. Memory keeps what the pool has learned about the campus across requests, so a lift that tends to stop short is known the second time, not rediscovered. A round that crosses vendors, such as a disinfection pass followed by a restock delivery, is authored once in Agency Studio, bounded, approved by a named role, and recorded, so the hospital can replay it when it wants to know what happened on a given night.

What stays on the campus, and who holds the record

Footage, adapted models, task definitions, and the record of every decision sit on the hospital's own hardware, in a room the hospital already secures. Watchman verifies the integrity of what the nodes are running. Every decision the pool served is written once, with the model version that made it, for the hospital's own review and for anyone the hospital invites to read it. On an air-gapped campus there is no route out at all, and updates arrive as signed bundles carried into the room; on a connected campus the declared routes are the only routes.

Placing and buying the pool

The nodes go in the hospital's own rack, where the network equipment already lives. The subscription is for the configured Grid: hardware, platform license, and sustainment in one line, fixed for the term. It does not move when a second delivery vendor arrives or when the disinfection fleet doubles. Where a robot vendor would rather ship the pool with its fleet under its own name, it does so as Czar Chassis, and the footage and the record are placed the same way.

The hospital keeps what it should keep: its corridors, its footage, and the record of what the machines in them decided. The vendors keep their robots and their software. The pool in the rack is what lets both be true at the same time.