Skip to content
ELEMENT 31

Glossary: bounds

Bounds are the limits written into an agent version on Czar: which models, which material, which tools, where approval is required, and what it may never do.

· 2 min read

IN SHORT

Bounds are the limits written into an agent version: which models the agent may use, which material it may read, which outside systems may be named as tools, where a person must approve, and what the agent may never do. They are fixed when the version is published and cannot be widened by a run. The admin sets what is possible; the version's bounds select from that.

Bounds are the limits written into an agent version on Czar: which models the agent may use, which material it may read, which outside systems may be named as tools, where a person has to approve, and what the agent may never do.

Why it matters

An agent is only as trustworthy as the clearest statement of what it cannot do. Bounds are that statement, and they live in the version rather than in a policy document somewhere else. Anyone who can read the version can read its bounds, and a run of that version cannot go beyond them.

This is what lets a site run several agents with very different reach on the same appliance. Each version's bounds are its own. A narrow agent and a wide one sit side by side without the narrow one inheriting anything.

How it works here

The admin decides, for the site, which models agents may use and which outside systems are available as tools. Those decisions are recorded with the admin's name. In Agency Studio, the operator or developer designs within them: choosing the models and tools this agent needs, naming the material it reads, placing the step that waits for a reviewer, and stating what it may never do.

Publishing freezes those choices into the version as its bounds. During a run, each step records whether policy allowed it, and the step that sends, spends, or changes a record waits for the reviewer regardless of how confident the draft looks. To give an agent more reach, the design is changed and a new version published. If the new reach requires a system the admin has not made available, the admin's decision comes first and the version second.

  • Version: where bounds are written and frozen.
  • Reviewer: the role that sits on the steps the bounds mark as waiting.
  • Run record: where each step's policy check is kept.

Questions this raises

Who sets the bounds?
The admin decides which models and systems are available on the site at all. The operator or developer, designing in Agency Studio, chooses from those and places the approval steps. Publishing freezes the result as the version's bounds.
Can a reviewer widen the bounds during a run?
No. The reviewer approves or stops the step that waits; they cannot grant the agent a model, a document set, or a tool the version does not name. Widening is a design change, published as a new version.
Are bounds the same as the admin's decisions?
They are related but not identical. The admin's decisions define what any agent on the site may possibly use. A version's bounds are the subset that one agent actually uses, plus where it waits and what it is forbidden to do.

KEEP READING

Related.