The front door the desk already has

Every desk has a place where work arrives. A claims desk has its queue. A procurement desk has the request form in its system. A records desk has the inbox its software already watches. That place is the front door, and the people on the desk have spent years shaping what comes through it. An agent on Czar does not replace the door. It stands behind it.

Why the door stays where it is

An agent that needs its own intake creates a second front door, and a second door is a second set of problems. Someone has to teach the floor where to send which kind of work. Someone has to extend the controls that already govern intake to the new channel. And when the two doors disagree about what arrived, someone has to reconcile them.

Keeping the existing door avoids all of that. The packet, whether it is a claim, a request, or a file the desk already understands, comes in the way it always has. The system behind the door, which the site already secures, hands the packet to the agent. The controls that apply to incoming work, from access rules to retention, keep applying because the intake has not changed.

From the door to the stable address

Deploying a version gives the agent a stable address. The customer's own application calls that address with the packet. The address does not move when a new version is published; the application keeps calling the same place and the operator decides which version answers.

So the integration between the front door and the agent is a single call from an application the site already runs to an address the site already controls. The desk's software does not need to know anything about how the agent is designed, which models it uses, or where its approval steps are. It knows the address and the shape of the packet.

What happens behind the door

Once the packet arrives, the run proceeds on the appliance. The agent reads only what it may read, drafts from those passages, and stops at the step that would send, spend, or change a record. A reviewer sees the draft and what it used, and the run continues on that decision.

The reviewer does not have to leave the desk to do this. The draft and the decision can surface in the same system that received the packet, because the application that called the address is the one that receives the result. The person who would have handled the packet by hand now sees a draft and a trail instead of a blank form.

Where the reply goes out

The front door usually has a back door: the place a finished reply, a posted entry, or a changed record goes. On a connected site, the agent reaches that system through a declared route that the admin has made available as a tool and the version has named. The call is made only after the approval step clears.

That means the outbound path is also one the site already secures. The reply leaves through the desk's messaging system, the entry posts through the ledger the desk already uses, the record changes in the records system under the same controls as a change made by hand. The agent did not add a new way out of the building, and what leaves the building, as always, is nothing.

The sequence someone can open tomorrow

Because the packet entered through the existing door and the result left through the existing systems, the run record on the appliance fits between two things the site already keeps. The inputs, the draft, the decision, and the call are one sequence. The ticket in the queue and the posted entry in the ledger are the bookends. A reviewer, or an auditor, can read all three together.

For how the packet itself is shaped, see /resources/the-packet-the-desk-already-understands. For the outbound half, see /resources/where-the-call-lands.