Connecting an agent to the systems you already secure

Most desks already run on a handful of systems: the ticketing queue, the records system, the document store, the ledger. An agent earns its place by working with those systems, not beside them. On Czar, that connection is built in a particular order, and the order is the point.

Nothing is connected until someone says so

A new agent on the appliance can call nothing outside itself. There is no default list of systems it may reach and no discovery step where it finds what is on the network. The admin decides which outside systems are available as tools at all. That decision is made once, for the site, and written down with who made it.

Only after a system is available can a version name it. The operator drawing the agent in Agency Studio chooses the tool for the step that needs it, and the bounds of that version say which tools the agent may use and under what conditions. A tool that the admin has not made available cannot appear in a version. A tool the version does not name cannot be called in a run.

This is a different posture from an agent that is handed broad credentials and asked to be careful. Here the agent cannot be careless, because the capability does not exist in the version.

Declared routes to the systems on site

Substrate, the platform on the appliance, carries the connection through Local Bridge: declared routes to on-premise systems. A route is declared, not discovered. It names the system the agent may reach and the shape of what it may do there. The route runs from the rack to the system inside the building, over the network the site already operates.

For a connected site, that means the agent reaches the records system the same way the desk's own applications reach it, through the paths and controls the site has already put in place. The appliance does not open a new path out of the building to make the connection work. What leaves the building: nothing.

A site that is air-gapped can still declare routes, as long as the system sits inside the same isolated segment. The agent's reach is defined by the routes, not by whether the site has an internet connection.

The step that calls is the step that waits

Connecting a system is not the same as letting the agent act on it. The bounds separate reading from changing. An agent may read a record from the ticketing queue to draft a reply, and that read can happen without a person in the loop. The step that sends the reply, posts to the ledger, or changes the record is the step that waits for a reviewer.

The reviewer sees the draft, sees which passages and which system reads the agent used, and approves or stops. Then the allowed call is made, or the run ends. So the integration has two halves: the route that makes the call possible and the approval that lets it happen in a given run.

What the record shows about each call

Every call to an outside system lands on the run record: which tool was called, what was sent, whether policy allowed it, and who approved when a person had to. The record is kept on the appliance alongside the inputs and the draft. A reviewer can open a finished run and see the call in its place in the sequence.

This matters for the people who own the connected system. They can see, from the appliance side, exactly what an agent did to their system and under whose approval, without asking the agent's team to reconstruct it. The record is something an auditor can read.

Adding a system later

When the desk wants an agent to reach a second system, the sequence repeats. The admin makes the system available as a tool. An operator or developer draws or writes the step that uses it. The new design is published as a version, and the stable address is pointed at it. A new capability is an administrative decision first and a version second.

If the new version behaves badly against the new system, the address is pointed back at the earlier published version and the new system is unreachable again. The route can stay declared; the version that used it is simply no longer live.

See /platform for how Substrate carries the routes, and /governance for how the admin's decisions are recorded.