From one desk to a governed estate

A site that has run one agent for a while will be asked for a second, then a fifth. Each new desk wants its own. The question that arrives with the fifth is not whether the appliance can run it, but whether anyone still knows what all of them are allowed to do. On Czar, the answer is yes, because the structure that governed the first agent is the structure that governs the rest.

The admin's decisions carry forward

The first agent required the admin to decide which models agents on this site may use, who may publish, and which outside systems are available as tools. Those decisions were made for the site, not for the agent. The second agent's operator works inside the same set.

As the estate grows, the admin's list grows deliberately. A desk that needs an agent to reach a system no agent has reached before asks for it. The admin decides, the decision is recorded with who made it, and only then can a version name the new tool. Capability expands one administrative decision at a time, and the list of what agents on the site can touch is always a list someone wrote.

One live version per agent

Each agent has a stable address, and each address points at exactly one published version. The customer's applications call the address; the operator decides which version answers. With one agent this is a convenience. With many it is what keeps the estate legible.

The live state of the estate is the set of addresses and the versions behind them. Every change to that state, publishing a version or pointing an address, is written down with who did it. There is no agent somewhere running a version nobody can account for, because an address cannot point at something that was not published.

Bounds travel with the version

Every version carries its own bounds: which models, which material, which tools, where approval is required, what it may never do. The claims agent's bounds and the procurement agent's bounds are separate, even on the same appliance. Adding a tenth agent does not loosen the first nine.

This is what lets an estate hold agents with very different reach side by side. One agent reads a single policy library and never calls out. Another reads supplier contracts and posts to the ledger after approval. Each is as narrow or as wide as its version says, and the version is the thing the admin and the operator can read. A reviewer moving between desks reads the bounds of each version to know what the agent in front of them is permitted to do.

Many appliances, more than one posture

A growing estate usually means more than one Czar, and often more than one posture. The plant segment may be fully air-gapped. The finance desk may be connected only to the systems it already secures. A Czar Grid may serve a larger workload at headquarters. Each is Czar, running the same agent layer.

Agents move across that estate as versions. A design that names only systems inside a segment publishes on an air-gapped appliance exactly as it does on a connected one. What differs per appliance is which tools the admin has made available there, and the version either fits that list or it does not.

The record at estate scale

With one desk, the run record answered what the agent did on a given packet. With an estate, it also answers the wider questions: who published this version, who pointed this address, who approved this call, and who changed this reviewer's role. Each of those is written down on the appliance where it happened.

An auditor who asks what agents on this site may do, and what they did, gets the admin's decisions, the bounds of each live version, and the runs. Those three together are the governance of the estate, and they exist because each desk followed the same structure as the first. For the controls themselves, see /governance.