Who decides, who approves, who reviews

An agent on Czar does not run itself. People decide what it may do, people publish it, and people approve the steps that matter. The agent layer names four roles for those people. A site adopting agents has to put names against them, and the choice of names is a governance decision as much as a staffing one.

The operator owns the outcome

The operator is the person the desk holds responsible for what the agent does. They compose the agent in Agency Studio, drawing it as the work actually happens. They publish a design as a version. They point the stable address at a version and turn it on or off.

On most desks the operator is the person who already owns the process: the claims supervisor, the procurement lead, the records manager. They know what the packet looks like, what the draft should say, and where a person has to approve. Giving the operator role to someone further from the desk tends to produce agents that are correct in principle and wrong in the particulars.

The developer keeps the same agent as a file

A developer describes the agent as a file, for review, source control, or generation. Canvas and file are one design; a developer's file and an operator's canvas publish as one version. The developer does not build a different agent from the operator's. They work on the same one in a form that fits their tools.

On a small desk, the operator and developer may be the same person. On a larger site, a central team of developers often supports several desks, each with its own operator. Either way, the version is published once, and the record shows who published it.

The reviewer approves or stops

The reviewer sits on the steps that wait: the step that would send, spend, or change a record. They see the draft and what it used, and they approve or stop. Their decision stays on the record under their name.

This should be the person who already signs off on that desk's work. The approval step is placed where their decision was already happening, so adopting the agent does not move the decision to someone new. It moves the draft in front of the person who was going to decide anyway, with its sources attached.

A site should resist making the operator the reviewer of their own agent. The operator designed the version and chose what it reads and drafts. A second person clearing the action is what makes the record worth reading.

The admin decides what is possible

The admin decides which models an agent may use, who may publish, and which outside systems are available as tools. A new capability is an administrative decision, then a version. The admin does not design agents and does not approve runs. They set the edges inside which operators and reviewers work.

The admin role usually sits with whoever already governs the site's systems: the people who decide what may connect to the records system or the ledger. That keeps the agent layer's capability decisions aligned with the site's existing controls, because the same people are making both. When a desk asks for a new tool, the admin weighs it the way they would weigh any new connection to that system, and the decision is recorded with their name before any version can use it.

Putting names against the roles

Adopting agents means writing down, for each desk, who is operator, who is developer, who reviews, and who the admin is for the site. Those assignments are themselves written to the record, and changing one leaves a trace with who changed it.

The payoff comes later, when someone opens a finished run. The record shows a version published by a named operator, within bounds set by a named admin, with the action approved by a named reviewer. Three people, three decisions, each on the record. For the full set of controls, see /governance.