Why agents run on the appliance, not in a cloud
An agent that reads a site's documents and drafts from them handles the site's most sensitive material. On Czar that work stays in the rack, and nothing leaves the building.
· 4 min read
IN SHORT
Agents run on the Czar appliance because the work they do touches the site's own documents, decisions, and records. Running on hardware the site controls means the corpus is read in place, the drafts and the run record never leave the building, and the site can be fully air-gapped or connected only to systems it already secures. What leaves the building is nothing.
An agent that reads a site's policies, account histories, and procedures, and drafts decisions from them, is handling the material the site would least like to see anywhere else. The question of where the agent runs is therefore the question of where that material goes. On Czar, the answer is that it goes nowhere. The agent runs on the appliance in the customer's rack.
What an agent touches
Consider what passes through a single run. A packet arrives with a claimant's details and a description of what happened. The agent retrieves the policy clauses that apply and the account's prior history. It drafts a response. A reviewer sees the draft and the passages. An allowed call updates a record or sends a letter. The record keeps all of it.
Every one of those items is something the site would normally keep inside its own systems. A cloud-hosted agent would carry each of them out of the building to be processed, and the site would be left trusting a vendor's handling of material it never meant to share. Running the agent on the appliance keeps the material where the site's existing controls already apply.
The appliance does the whole job
Czar is not a gateway that forwards work to a model elsewhere. The models run on the appliance. Retrieval over the site's documents runs on the appliance through Substrate. Drafting, the waiting step, the allowed call, and the record all happen on the appliance. The corpus stays wherever the customer put it and is read in place.
This is why a site can be fully air-gapped and still run agents. There is no step in a run that requires an outside connection. A site that chooses to be connected does so only to systems it already secures, through declared routes the admin has made available as tools. The agent is the same either way. The posture is the site's decision.
Control stays with the site
Where the agent runs also decides who controls it. On Czar, the admin decides which models an agent may use, who may publish, and which outside systems are available as tools. The operator composes the agent, publishes a version, and turns the live address on or off. A new capability is an administrative decision at the site, then a version.
A cloud-hosted agent platform makes those decisions at the vendor. Models change under the customer. Capabilities appear and disappear. The customer discovers the change when a run behaves differently. On the appliance, nothing about an agent changes unless someone at the site publishes a new version and points the address at it, and that act is written down. The article What the admin decides describes these decisions.
The record stays local
Each run leaves a record of what went in, what each step did, whether policy allowed it, and who approved. That record is itself sensitive. It contains the packet, the passages, the draft, and the decision. On Czar it stays on the appliance, readable by the site's reviewers and by an auditor the site chooses to admit.
A site that needs to answer a question about a past run opens the record on its own hardware. It does not file a request with a vendor or wait for an export. The run record and what it holds describes what is in it.
Sovereignty as a property of the building
Some sites must be air-gapped because of what they handle. Others are connected but have strict rules about which systems may talk to which. Still others are ordinary facilities that simply prefer their documents to stay in their own building. Czar serves all of these with the same appliance and the same agent, because sovereignty on Czar is a property of where the hardware sits, not a tier of service.
For a mixed estate, where some sites are air-gapped and others are connected, the same published version can run on each appliance with that site's admin deciding what is available there. The agent does not need to know which posture it is in. It reads what it may read, drafts, waits, and calls, on the appliance in front of it.
An agent on Czar runs where the data already lives, under the control of the people who already own that data, and leaves a record on the same hardware. That is the reason it runs on the appliance rather than in a cloud. The platform page describes the appliance and the platform the agent uses.
Questions this raises
- Does an agent on Czar ever call an outside model?
- Only if the admin has made that model available and the version names it. By default the models an agent uses run on the appliance through Substrate. On an air-gapped site there is no outside model to call, and the agent works entirely from what is in the rack.
- What does a connected site give up compared with an air-gapped one?
- Nothing about where the agent runs. A connected site reaches the systems it already secures through declared routes the admin has made available as tools. The agent still runs on the appliance and the corpus still stays in place.
- Can the same agent run at several sites?
- A published version is a file and a canvas, so it can be published on more than one appliance. Each site's admin decides which models and tools are available there, and each site keeps its own run records on its own appliance.
KEEP READING