A hospital's agents, on one Czar in the building

A hospital's clerical work is clinical work seen from the back. Messages between the hospital's systems, coding, insurance correspondence, prescriptions: each is drafted from the patient record, each is a first pass an agent can prepare, and each is a point where a person has to decide. The question for a hospital is not whether agents can do the first pass. It is where the record goes while they do it. A cloud assistant does its work by carrying the patient record out of the building. One Czar in the hospital does the same work on the hospital's own data, and every draft it produces waits for the person whose name goes on it.

The work a department sees

Walk through a hospital's back offices and the same shape repeats. A coder reads an encounter and assigns the codes that describe it. An insurance desk reads a denial and drafts the response. A pharmacy reads an order against the chart and the formulary before it is filled. An integration team watches messages move between the admission system, the laboratory, the pharmacy, and billing, and sorts out the ones that land wrong. All of it is reading a record and writing a draft, done many times a day by people who are also responsible for the result.

Each department has been offered its own assistant for this, usually inside the department's own tool. Each one would bring its own model, its own log, and its own path out of the building. The hospital would end up with several assistants it cannot see into and several logs to reconcile before it could answer a simple question about what happened to one patient's record on one afternoon.

Why a cloud assistant fails here

The first constraint is the plainest. Patient records cannot leave the building to be summarized. An assistant that works by sending the encounter to a vendor's cloud and receiving a draft back has moved the record off the premises, whatever its contract says about retention.

The second constraint is about authority. A draft a clinician did not approve is not a decision. A prescription is a decision a prescriber makes, a code is a judgment a coder stands behind, and an appeal is a letter the hospital sends. An assistant that produces these things and lets them pass has quietly become the decision-maker, with nobody's name on the result. The third constraint follows from the first two: when something is questioned later, the audit must be reconstructible from one record, not assembled from several vendors' partial logs.

Drafts that wait for the clinician

On one Czar in the hospital, agents in Agency Studio prepare coding, insurance, and prescription drafts from the record and hold them. Retrieval reads the encounter, the chart, and the hospital's own guidance; Inference writes the draft; the agent is bounded to the material and the actions it was authored for. The draft goes nowhere. It waits in a queue for the responsible clinician or coder, who approves it, amends it, or rejects it, and that act is written to the log beside the draft.

The pharmacy's case is the clearest. An agent can read an order against the chart and the formulary and prepare the check, the flag, and the note. The prescriber or pharmacist is the one who signs. The agent has saved the reading; it has not taken the decision.

Messages between the hospital's systems

The integration desk's work fits the same pattern. Messages between the hospital's systems arrive constantly, and a fraction of them need a person: an admission that does not match a patient, a result addressed to a department that no longer exists, an order that references a bed that has been reassigned. An agent on the Czar reads each message, interprets what it is about, and routes it to the right queue, with the interpretation recorded. Local Bridge carries the messages over routes the hospital declared, one by one, to the systems the hospital already runs. There is no default path out, and adding an agent does not create one.

One record for every agent

Everything the agents do is written once, on the appliance: every prompt, every retrieval, every draft, every approval and who gave it. Evaluation scores the drafts against the hospital's own standard, and Watchman verifies what is running. When the hospital's own review asks what the agent read and who approved the result, the answer is one record on one machine the hospital holds, and a run can be replayed to show it.

That is the boundary this solution is built around. Agents prepare and propose; a named person approves. Nothing customer-facing, client-facing, or production-changing leaves the appliance without that approval, and every step is on the record the team holds. In a hospital that means no code, no appeal, no order, and no routed message goes out on an agent's say-so.

One Czar, placed and bought

The Czar is a sealed node in the hospital's own rack, in a room the hospital already secures, on the hospital's own network. The routes it may use are declared at commissioning: the record system, the pharmacy system, billing, the integration engine, and nothing else. It can run air-gapped, or connected only to systems the hospital already secures. The hospital holds one subscription for the configured appliance, with the hardware, the platform license, and sustainment in one line, fixed for the term. A solution brief for healthcare teams describes the intended architecture; it is substantiated at commissioning and makes no customer claim.

A hospital that wants agents for its back offices has mostly been offered a choice between doing without and sending the record out. One Czar in the building removes that choice. The record stays where it was, the drafts arrive sooner, and the person whose name goes on the result is still the one who decides.