A first agent for a desk

The best first agent is a modest one. It takes one kind of packet from one desk, reads a bounded set of material, drafts, and waits for the person who was already going to decide. That is enough to learn what the desk needs and enough to show the site what the record looks like. Ambition belongs in the second version.

Choosing the desk

Look for a desk where three things are already true. Work arrives as a packet the desk recognizes: a claim, a request, a file in a known form. The answer is drafted from documents the desk already keeps: a policy library, a contract set, prior decisions. And someone already approves before the answer goes out.

A desk like that gains an agent without changing how it works. The packet still comes through the same intake. The reviewer still decides. What changes is that the reviewer opens a draft with its sources instead of a blank form. A desk whose work has no settled shape, or where nobody currently approves, will make the agent carry decisions it should not carry yet.

Drawing the first version

In Agency Studio, the operator draws the agent as the work happens on that desk: what it reads when the packet arrives, what it decides, where a person has to approve, and which systems, if any, it may call. For a first agent, keep each of those narrow.

Read one body of material, the one the desk actually uses. Decide one thing, such as which category the packet falls in and what the draft reply should say. Place the approval step before the only action that sends, spends, or changes a record. Name no tools, or one. The bounds that come out of this drawing are the ones the version will carry.

The admin has a part here. Which models the agent may use and which systems are available as tools are the admin's decisions, made before the operator can finish the design. On a first agent, those decisions tend to be quick, because the scope is small.

Publishing and pointing

A design on the canvas is not yet something the desk can call. Publishing freezes it into a version. Deploying points a stable address at that version, and the application behind the desk's intake calls that address with each packet. From that point the desk is running on the agent, and the operator can turn the address off if something is wrong.

It helps to publish early, while the version is still simple, rather than refining the design on the canvas for weeks. A published version run against real packets teaches more than a draft reviewed in the abstract.

The first weeks

The run record is the point of the first weeks. Each run holds what came in, what the agent read, what it drafted, and what the reviewer decided. Reading those records tells the operator which drafts the reviewer accepted as written, which they corrected, and which they stopped.

That reading drives the second version. Perhaps the agent should read a second document set. Perhaps the draft needs to carry a field the reviewer kept adding. Perhaps the reviewer has stopped correcting and the version can now make the allowed call itself, still after approval. Each of those is a change to the design, published as a new version, with the earlier one still there to point back to.

What the site has after a first agent

By the end, the site has one desk running on a published version, a reviewer who trusts the drafts because they have read the sources, an admin who has made and recorded the first capability decisions, and a run record that shows every decision taken. It also has an operator who knows how to change the agent without calling anyone.

That is the base the second desk builds on. See /use-cases for the kinds of desk work that fit, and /resources/from-one-desk-to-a-governed-estate for what comes after.