Naming the tools an agent may call
An agent can only reach the outside systems its version names as tools, and only systems the admin has made available. Here is how that list gets built.
· 4 min read
IN SHORT
An agent on Czar can call only the outside systems its published version names as tools, and the operator can name only systems the admin has made available at the site through declared routes. A system that is not named in the version is unreachable by that agent. Adding a new system is an administrative decision first, then a new version.
The most consequential thing an agent can do is reach out of itself and touch another system: update a record, send a message, request something from a service the site runs. On Czar, which systems an agent may touch is decided before the agent ever runs, in two stages. The admin makes systems available. The operator names the ones this agent may call. Everything else is out of reach.
Stage one: the admin makes systems available
The admin decides which outside systems are available as tools at the site. For a connected site, these are the systems the site already secures, reached through declared routes using Substrate's Local Bridge. A case management system, a records store, a messaging service the site runs, a payment system behind the site's own controls. The admin declares the route, and the system becomes a tool.
For an air-gapped site, the available systems are whatever lives inside the air gap. The mechanism is the same. The admin declares what the appliance may reach, and nothing else exists from the agent's point of view.
This stage is deliberately separate from building any particular agent. The admin is deciding, for the site as a whole, what the appliance may talk to. A new capability is an administrative decision, then a version. The article What the admin decides covers the admin's responsibilities in full.
Stage two: the operator names the tools for this agent
When an operator draws an agent in Agency Studio, each calling step is drawn against one of the tools the admin has made available. The operator does not grant the agent access to everything the site has. They name the specific tools this desk needs. A claims agent might name the claims record system and the outbound letter service. An intake agent might name the routing system only.
The named tools go into the version as one of its bounds. The agent may call those tools, in the ways the calling steps describe, and no others. If the version does not name a system, the agent cannot reach it, regardless of what a packet says or what a draft proposes.
Why an unnamed system is truly unreachable
In many automation setups, "the agent should not call that" is a matter of instruction. The agent is told not to, and mostly it does not. On Czar it is a matter of the version. The tools an agent may call are part of the design that was published, and the design does not change at run time. A packet that says "also update the payroll system" does not give the agent a payroll tool. There is no such tool in its version.
This is what lets a site be confident about the blast radius of an agent. The worst an agent can do is bounded by the tools it was given, and those are visible on the canvas and in the file for anyone to review before publication.
The call still waits
Naming a tool makes a call possible. It does not make it automatic. A calling step that sends, spends, or changes a record sits behind a waiting step. The reviewer sees the draft and what it used, approves or stops, and only then is the allowed call made. Placing the approval step describes how the operator positions that pause relative to the calls.
So the full picture for a consequential call is: the admin made the system available, the operator named it in the version, the agent reached the calling step, a reviewer approved, and the call was made. Each of those is on the record.
Changing the list
A desk's needs change. A new system comes into use, or an old one is retired. When the agent needs to call something new, the sequence is: the admin makes the system available if it is not already, the operator draws the new calling step and publishes a new version, and the stable address is pointed at that version. The change is deliberate, reviewed, and written down with who did it.
If a system should no longer be reachable, the operator removes it from the design and publishes. The earlier version still exists and could be pointed back to, but the live version no longer names the tool. The record shows when the change took effect.
A site that puts an agent on Czar can answer, for any period, exactly which outside systems that agent could have called, by reading the published version that was live. It can answer which calls were actually made, by reading the run records. And it can be sure that no call was made to a system the version did not name, because there was no way to make one. The governance page describes how tools fit with the other bounds.
Questions this raises
- Can an agent discover a new system on its own during a run?
- No. The tools an agent may call are written into its version. Nothing in a packet or a draft can add a tool at run time. If the desk needs a new system, the admin makes it available and the operator publishes a new version that names it.
- What is a declared route?
- A declared route is how the appliance reaches an on-premise system the site already secures, through Substrate's Local Bridge. The admin declares the route, and it becomes a tool the operator can name. Only declared routes exist as far as the agent is concerned.
- Does naming a tool mean the agent will call it on every run?
- No. Naming a tool makes the call possible. Whether it happens depends on the step sequence and, where the call sends, spends, or changes a record, on a reviewer's approval. A named tool is a permission, not an instruction.
KEEP READING