Agents as employees

An agent on your site is closer to a hire than a feature flag. It has a job, a place to work, and a person who reviews the output. That is why we talk about a worker on this site, not a mascot in the dashboard.

Named, in a lane

Give the worker a name you would put on a seat. Keep it in the Requests lane for that site. Do not publish model or bot brand names in the dashboard. In product copy it is a worker or an agent.

Supervised first

The first versions stay supervised. A person reviews the preview. Ship to live is a separate ask. That is the product, not a temporary training mode we plan to skip.

• The worker builds on a Request, not by chatting the live site into a new shape.
• Looks good is a person. Ship to live is a person who is allowed.
• The worker cannot mark a Request live before promote was requested.

How this shows up today

Today the worker is a key on the site, not a public directory of agents. One key family per site. Admin or developer mints and revokes it under Settings, Requests. Owners never see that form.

1. Admin or developer opens Settings, Requests.
2. Mint a worker key. Copy it now. The full key is shown once.
3. Give that key to the worker that should act on this site only.

What owners do

Owners file Requests, read the thread they are allowed to see, and use the review card. They do not hire a model by brand name, and they do not paste a key. If several people help, they still join as Team members with a rank.

What this is not

Not an unsupervised publisher. Not a prompt box that emits a new site. Not a shared robot that wanders every site you own. See Agent on your site.

Read Docs first

When you connect a worker, point it at How xTerminal works, Servicing requests, Gateway, APIs, and MCP, and Portfolio vs Client Ops. Do not dump this handbook into memory and hope it stays true.