Bringing in engineers to build the first version

Some sites want to build their first agent themselves. Others would rather have someone who has done it before sit with the desk for the first version. E31 Consulting engineers can do that, forward-deployed or as an in-house project. What matters about the arrangement is less who does the building than what is left behind when they go.

Building in the site's own tools

The engineers work in Agency Studio on the site's appliance, or in the agent file, the same two forms of the same design the site's operator and developer will use. There is no separate build environment and no intermediate artifact that later has to be translated into something the site can run.

This is deliberate. An agent built in a tool the site's team does not have is an agent the site cannot change. Building in the canvas and the file means that on handback day, the operator opens the same design the engineers were working on an hour before.

Scoping with the desk, not for it

The first conversation is about the desk. Which packet arrives, what the desk drafts from, who approves, and which systems the agent might eventually call. The engineers bring the shape of a first agent; the desk brings the particulars that make it correct.

The admin's decisions remain the admin's. The engineers do not decide which models the agent may use or which systems are available as tools. They ask, the admin decides, the decision is recorded, and the design proceeds inside it. The same holds for the reviewer: the person who already approves on that desk stays the reviewer, and the engineers place the approval step where that person's decision already happens.

What gets handed back

The deliverable is a published version. Not a specification of one, not a prototype on someone's laptop, but a version frozen on the site's appliance with a stable address pointed at it and the desk's own application calling that address.

Alongside it, the site has the design on the canvas and the file, both opening to the same thing. The operator can see every step the engineers drew: what it reads, what it decides, where it waits, which tools it names. The bounds of the version are readable in the same place. Nothing is hidden in a build the site cannot inspect.

The engineers also leave the desk's reviewer with a few weeks of run records to learn from, if the build included running the version against real packets before handback. Those records show the reviewer what the agent drafts and what it draws on, which is the fastest way for a reviewer to calibrate how closely to read each draft.

The operator owns it afterward

From handback, the operator can change the agent the way they would change one they built. They edit the design, publish a new version, and point the address at it. If the new version is wrong, they point the address back. The engineers' version remains on the appliance as an earlier published version, available to return to.

The record shows the transition cleanly. The engineers' publishing actions are written down with their names. The operator's subsequent publishing actions are written down with theirs. An auditor reading the version history sees who built what and when the site's own people took over.

When to bring engineers in, and when not to

Engineers help most on a first agent at a site that has never published a version, or on an agent that touches a system nobody on the desk has integrated before. They help least when the desk already has an operator who has drawn and published an agent, because that operator can usually draw the next one faster than they can explain it.

Either way, the thing that runs is a version on the customer's appliance, within bounds the admin set, approved by the desk's own reviewer. Who drew the first one is a detail the record keeps. For the shape of a first agent, see /resources/a-first-agent-for-a-desk.