What an agent is on the appliance

The word "agent" carries a lot of baggage. On the Czar appliance it means something narrow and checkable: a piece of desk work, drawn as a sequence of steps, frozen into a version, and run on hardware the site owns and controls. This article describes that thing without the baggage.

A desk, a packet, a sequence

Start with a desk. A claims desk, an intake desk, a procurement desk, any desk where work arrives in a recognizable shape and leaves in another. Work arrives as a packet: a claim, a request, a file the desk already knows how to read. The desk reads it, looks things up, drafts a response or a decision, and then does something that matters, like sending a letter, approving a payment, or changing a record.

An agent on Czar is that sequence, written down. It has a front door, which is whatever channel the desk already uses to receive work. It has a reading step, in which the agent pulls only the passages it is allowed to read from the site's own corpus. It has a drafting step, in which the agent produces a proposed answer from those passages. It has a waiting step, where a person looks at the draft and what it used. And it has a final step, where an allowed call is made or the run simply ends.

That is the whole shape. There is no open prompt, no general purpose window, and no capability the version did not name.

Bounded by a version

An agent does not exist as a loose set of behaviors. It exists as a version. An operator draws the agent in Agency Studio, and a developer can hold the same design as a file. When the design is right, it is published, and publishing freezes it. The version carries its bounds: which models the agent may use, which material it may read, which outside systems it may name as tools, where it must wait for approval, and what it may never do.

Deploying points a stable address at that version. The site's own applications call the address. Only one version is live behind an address at a time, so there is never a question of which agent is running. When a version turns out to be wrong, the address is pointed back at an earlier published one. More on that in One live version at a time.

It waits where it matters

The step that sends, spends, or changes a record waits for a person. This is not a configuration option that a site has to remember to turn on. It is how an agent on Czar is built. The reviewer sees the draft and the passages it was drawn from, and the run continues on their decision, either forward to the allowed call or to a stop.

This is what separates an agent from an automation script. A script does what it was told until someone notices it was told the wrong thing. An agent on Czar drafts, then pauses, and the pause is recorded along with who ended it. The article An agent that waits before it acts goes into the waiting step in more detail.

It runs where the data already lives

Everything above happens on the Czar appliance, in the customer's rack. The models run there. Retrieval over the site's documents runs there, using Substrate's capabilities for inference, retrieval, and memory. The record of each run is written there. The corpus stays wherever the customer put it and is read in place.

A site can run fully air-gapped, with no outside connection at all. Or it can be connected only to systems the site already secures, through declared routes that the admin has made available as tools. In either case, what leaves the building is nothing. The agent does not call a vendor's cloud to think, and it does not send the site's documents anywhere to be indexed.

Each run keeps what went in, what each step did, whether policy allowed it, and who approved when a person had to. Inputs, draft, decision, and call are one sequence that someone can open tomorrow. A reviewer can follow a live run as it happens or open a finished one later. Publishing a version, deploying it, and changing a role are also written down, with who did them.

The record stays on the appliance. It is something an auditor can read without the site having to reconstruct what happened from logs scattered across several systems.

Who is involved

Four roles touch an agent. The operator owns the outcome: they compose the agent, publish a version, and turn the live address on or off. The developer describes the same agent as a file, and file and canvas publish as one version. The reviewer sits on the steps that wait and approves or stops. The admin decides which models an agent may use, who may publish, and which outside systems are available as tools.

None of these roles is a vendor. They are people at the site. That is the simplest way to say what an agent on the appliance is: desk work, drawn by the people who do it, run on hardware they control, with a record they keep. The platform page describes the appliance it runs on.