What the admin decides
The admin sets the outer limits for every agent at the site: which models exist, who may publish, which systems are tools. A new capability is an administrative decision first.
· 4 min read
IN SHORT
The admin decides, for the whole site, which models an agent may use, who may publish versions, and which outside systems are available as tools. Operators choose from within those decisions when drawing an agent. A new capability on the appliance is an administrative decision first, then a version, and each administrative act is recorded with who made it.
Someone at the site has to decide what the appliance may talk to, which models may run on it, and who is trusted to put an agent in front of the site's applications. On Czar that someone is the admin. The admin does not draw agents. The admin decides the limits every agent at the site must work within.
Three decisions
The admin's role comes down to three kinds of decision.
Which models an agent may use. The admin decides which models are available on the appliance. An operator drawing an agent chooses from that set. A model the admin has not made available cannot appear in any version.
Who may publish. The admin decides which operators may publish versions, and for which agents. Publishing is the act that turns a draft into something that can go live, so controlling who may publish is controlling who may change what the site runs.
Which outside systems are available as tools. The admin declares the routes the appliance may use to reach systems the site already secures. Each declared route becomes a tool operators can name. A system without a declared route does not exist as far as any agent is concerned.
Nothing new becomes possible for an agent on Czar without passing through the admin first. If a desk wants its agent to call a system it has not called before, the admin declares the route. If a desk wants a model the appliance does not yet offer, the admin makes it available. Only then does the operator draw the change and publish a version.
This two-step sequence is deliberate. It means that the set of things any agent at the site could possibly do is bounded by a short list the admin controls, and that list changes only by a recorded administrative act. Operators have wide freedom inside the list and none outside it.
The admin, the operator, and the reviewer
The operator owns the outcome of a desk. They compose the agent, publish versions, and turn the live address on or off. The admin owns the boundary. They decide what the operator may choose from and who the operator is.
The two roles are separate so that the person closest to the work is not also the person deciding what the work may touch. An operator who wants a new tool asks the admin. The admin, who can see the site as a whole, decides whether that system should be reachable by agents at all. The article Naming the tools an agent may call describes how the two roles divide the tool list.
The admin also assigns the reviewer role. For each agent, the admin decides which people may sit on the waiting steps and approve or stop runs. This is the admin deciding who is trusted to say yes to a consequential act. Changing the assignment is recorded with who did it. Approvals by named roles covers the reviewer's side.
What is written down
Every administrative act is recorded. Making a model available. Declaring a route. Granting or removing the right to publish. Assigning or removing a reviewer. Each entry names the admin who did it and when. Together with the publication and deployment records, this gives the site a complete account of how any agent came to be able to do what it does.
An auditor asking how an agent gained access to a system reads two entries: the admin's declaration of the route, and the operator's publication of the version that named it. Changing a role and leaving a trace describes the role changes in particular.
The admin on an air-gapped site
On a fully air-gapped site, the admin's decisions are about what lives inside the air gap. The models are those on the appliance. The tools are systems within the isolated network. The mechanism is unchanged. The admin declares what the appliance may reach, and only that is reachable. For a mixed estate, each site's admin makes these decisions for that site, and a version published at one site runs within the admin's limits at any other site where it is deployed.
Why the role is small
The admin role on Czar is deliberately limited to boundary decisions. The admin does not see into runs the way a reviewer does, and does not draw agents the way an operator does. Keeping the role small makes it easier to assign carefully. A site can give the admin role to someone whose job is governance rather than operations, and that person controls what every agent may do without having to understand how any particular agent works. The governance page describes the four roles together.
Questions this raises
- Does the admin design agents?
- No. The admin decides what is available at the site and who may do what. Operators draw agents and publish versions. The admin's decisions are the outer boundary; the operator's design sits inside it. One person can hold both roles if the site is small, and that assignment is recorded.
- How does a new outside system become available to agents?
- The admin declares a route to it, through Substrate's Local Bridge for on-premise systems the site already secures. The system is then a tool operators can name in a version. Until the admin declares it, no agent can reach it.
- Can an admin change a live agent?
- Not directly. Changing an agent means publishing a new version and pointing the address at it, which are operator acts. The admin can change what is available, who may publish, and who holds the reviewer role. Those changes are recorded, and they affect future versions rather than the one that is live.
KEEP READING