Skip to content

The packet the desk already understands

A run on Czar starts with a claim, a request, or a file in the shape the desk already receives. The agent fits the work; the work does not change for the agent.

· 4 min read

IN SHORT

A run begins when a packet arrives in the form the desk already receives, through the front door it already has. The packet might be a claim, a request, or a file with a known structure. The agent is drawn around that packet rather than the desk being reshaped around the agent, so the people and systems feeding the desk do not have to change.

Every desk receives work in a shape it recognizes. A claims desk gets claims. An intake desk gets requests. A records desk gets files with a certain structure, in a certain channel, at a certain cadence. People who have worked that desk for a while can tell at a glance whether a packet is complete, which kind it is, and what has to happen next. An agent on Czar begins from exactly that packet, in exactly that channel.

The run starts where the work already arrives

An agent does not ask the site to build a new intake. It attaches to the front door the desk already has. If the desk works from a queue, the agent reads from that queue. If it works from a shared inbox, the agent reads from that inbox. If it works from a case system that the site already secures, the agent reaches it through a declared route the admin has made available.

The point is to leave the people upstream alone. The field office that sends claims keeps sending them the same way. The customer who submits a request keeps using the same form. The system that drops files into a folder keeps dropping them. The agent is the thing that changes, and it changes to fit.

A packet with a known shape

A packet the desk already understands has structure the agent can rely on. A claim has a claimant, a policy reference, a description of what happened, and attachments. A request has a requester, a thing requested, and a justification. A file of a known type has fields in known places.

The operator who draws the agent in Agency Studio knows this structure because they have worked the desk. They draw the first step as "read the packet" with the fields the desk cares about, and the agent begins its run by extracting those. This is far more reliable than handing the agent an undifferentiated blob and hoping it finds the right parts. The known shape gives the agent a known place to start.

From packet to passages

Once the agent has the packet, it reads only what it may read from the site's corpus. The packet tells it what to look for: the policy that applies, the prior history for this account, the procedure for this kind of request. Retrieval runs on the appliance over material the customer has placed there, and the corpus stays where it was put.

The agent then drafts from the passages it found. The draft is tied to the packet that started it and to the passages it used. When the reviewer sees the draft at the waiting step, they see the packet, the passages, and the draft together. The article Reading only what the agent may read describes the reading step in more depth.

Why fitting the packet matters for adoption

Sites that have tried to introduce automation often discover that the hard part was not the automation. It was persuading everyone upstream to send work in a new format, through a new channel, with new fields filled in. Adoption stalls on the people who have to change their habits before the new thing delivers anything.

An agent drawn around the packet the desk already understands avoids that. On the first day the agent is live, work arrives as it always has. The desk's reviewers see drafts instead of raw packets. Nothing else in the building has moved. If the agent is later stopped or pointed back to an earlier version, the work still arrives the same way, because the front door was never the agent's.

What the agent does not do with the packet

The agent does not forward the packet to a vendor's cloud for processing. It does not copy the packet out of the system it arrived in to an index somewhere else. It reads the packet on the appliance, drafts on the appliance, and records on the appliance. What leaves the building is nothing.

If the packet is incomplete, the agent does not fill in the gaps from imagination. The draft reflects what was there and what was missing, and the reviewer sees that plainly. An agent that invents a policy number or a prior approval is worse than no agent, and the bounds written into the version are there to prevent exactly that.

A desk that adds an agent on Czar still receives the same packets, through the same door, from the same people and systems. What changes is that someone, or something, has read the packet and the relevant material and prepared a draft before the reviewer picks it up. The use cases page describes several desks where this shape fits.

Questions this raises

Does the site have to reformat its documents for the agent?
No. The agent is drawn around the packet as it already arrives, whether that is a structured form, a scanned file, or a message with attachments. If the desk can read it today, the agent is built to read it too.
What counts as a front door?
Whatever channel the desk already receives work through: a queue, a shared inbox, a case system, a folder that fills up. The agent is attached to that channel through a declared route. Nothing new is built for people to send work into.
What if the packet is incomplete or malformed?
The agent can only read what it may read and draft from what is there. A packet that lacks what the desk needs produces a draft that says so, and the reviewer sees that at the waiting step. The run does not invent missing material.

KEEP READING