Skip to main content

The eight states

deleting is not a step in the flow — it is a lock. While it is held, no other operation touches that agent.

The four actions

Deploy

On a draft or stopped agent. Provisions a container and starts it. The volume from a previous life is reattached, so the agent picks up where it left off.

Stop

On a running agent. Removes the container and keeps the volume. Billing for the seat does not stop — the seat is what you bought.

Start

On a stopped agent that still has its container definition. Faster than a full deploy.

Delete

Destroys the container and the volume. See Deleting an agent — it asks you to type the name.
Stopping an agent does not free a seat and does not refund anything. It stops the agent from thinking, which stops model spend. Freeing a seat is done from Billing, by reducing the seat count.

Waiting for capacity

When the platform has no room for another container, a deploy does not fail — it queues. The agent’s page shows a capacity wait panel with your position, how long you have waited, how long the seat is held for, and a way to stop waiting. When room appears, agents that are waiting start on their own; you get a notification rather than having to come back and check.

When an agent breaks

The failure notice sits above everything on the agent’s page and is classified from what the container actually reported: Configuration failures are the ones you can fix yourself — see The agent’s config file. The others carry a contact-support action with the agent id and the classification already filled in.

Watching a fleet

The agents table refreshes itself. An agent that crashes while you have the page open changes state without a reload — transitional states are polled far more often than settled ones, so a deploy in progress is close to live while a running fleet is not being hammered.
Last modified on August 31, 2026