Bounds written into the version

Limits on an automated system are only as good as their permanence. A limit that lives in a settings panel can be changed by whoever has the panel open, and nobody may remember that it was. On Czar, an agent's limits live in the version. They are published with the design, frozen with it, and read with it.

The five bounds

Every version carries five kinds of bound. Which models the agent may use. Which material it may read. Which outside systems it may name as tools. Where approval is required. What it may never do.

These are not an afterthought attached to the agent. They are drawn into the design in Agency Studio and held in the file. When the operator publishes, the bounds are frozen along with the step sequence. A reviewer opening the version sees the bounds and the steps together, because they are one thing.

Models. The admin decides which models are available on the appliance. The operator chooses, for a particular agent, which of those it may use. A version names its models, and the agent uses no others. If the admin later makes a new model available, no existing version starts using it. An operator would have to draw that in and publish.

This keeps a change in the site's model inventory from silently changing how a live agent behaves. The agent behind an address does exactly what its version says until someone points the address at a different version.

Material. The version names which material the agent may read. Retrieval runs on the appliance over that material and no other. The corpus stays where the customer put it. Material outside the bound is not available to the agent during a run, regardless of what the packet asks for. The article Reading only what the agent may read describes this in depth.

Tools. The version names which outside systems the agent may call, chosen from the systems the admin has declared as tools for the site. An unnamed system is unreachable. Naming the tools an agent may call covers how the list is built and why it cannot grow at run time.

Approval points. The version records where the agent must wait for a person. The operator draws the waiting steps directly before any step that sends, spends, or changes a record. Once published, the pauses are fixed. No run skips one, and no packet moves one.

Prohibitions. The version can also name what the agent may never do. These are actions that are off limits regardless of input or draft. On each run, policy is checked, and the run record notes whether policy allowed each step. A prohibited action does not occur, and the fact that the agent reached a point where it would have is visible in the record.

Why the bounds live in the version

Putting the bounds in the version rather than in a separate configuration has three consequences.

First, the bounds cannot drift. A live agent's limits are exactly what they were when its version was published, and they stay that way until the address is pointed elsewhere. There is no panel where a limit can be loosened without a publication being recorded.

Second, the bounds are reviewable with the design. Someone checking an agent before it goes live reads one version and sees both what the agent does and what it is permitted to do. There is no second document to cross-reference.

Third, the bounds are auditable after the fact. The question "what could this agent have done during that period" is answered by reading the version that was live then. The history of versions is the history of permissions. One live version at a time explains why there is always exactly one such version to read.

Changing a bound

When a desk's needs change, the operator edits the draft, adjusts the bound, and publishes a new version. If the change requires something the site does not yet have, such as a new model or a newly declared system, the admin makes it available first. A new capability is an administrative decision, then a version. The stable address is pointed at the new version, and the change is recorded with who published and who deployed.

The old version is still there. If the new bound turns out to be wrong, the address can be pointed back. The agent returns to its earlier limits exactly, because they were frozen.

What the site gets

A site running agents on Czar can state, for any agent and any period, which models it could use, what it could read, what it could call, where it had to wait, and what it could never do, by reading one published version. That statement is reliable because nothing could have changed those bounds without producing a different version. The governance page describes how bounds fit with roles and the record.