Seats: who runs where
A seat is one agent identity on one machine, with a vendor login of its own. Why a role reserves a seat, and what refuses when the wrong role is dispatched onto it.
A seat is one agent identity on one machine: its own profile home, its own credential, its own usage window. A machine carries several seats, and a seat runs one session at a time.
Why a seat, and not just a machine
- Isolation. Two agents sharing a machine but not a seat cannot read each other's sessions or credentials.
- Accounting. Usage and limits are read and enforced per seat. ⚠ A machine is never "out of quota" — a seat is, and the difference decides where you route work next. ⛔ Do not read that as "a seat is an account" — see below.
- Concurrency. A seat is one run at a time. ⇒ A machine's capacity is the number of its seats — to run more at once on one machine, seat more identities on it.
A seat is a login, and several seats can share one account
A seat carries a vendor login of its own. Whether two seats are signed in to two different vendor accounts or to the same one is a choice made when the fleet is configured, and both are ordinary.
⇒ Per seat and per account are therefore not the same number, and that matters most in the place it is least visible:
- a personal subscription behind one seat: the seat's reading is the account's reading;
- one account shared by several seats: what the limit applies to depends on the subscription — it can sit on the account as a whole, or on each member inside it. ⚠ Where it sits per member, a reading taken from one seat says nothing about another, even though both seats are on the same account.
⛔ So a reading is never generalised. Ask each seat you intend to use, and route on that seat's own answer.
Which seats share an account is declared per seat with saphan machine set-account, and the
accounts the product has measured are listed with saphan account list and given a name you
recognise with saphan account label — see the command reference.
A role can reserve a seat
A seat may be registered for a role. The rule is deliberately asymmetric:
- a seat registered for the executor role is unreserved — it accepts every declared role;
- a seat registered for any other role is reserved for that role, and a dispatch declaring a different role — or none — is refused at placement, by name, before anything spawns and at no cost.
What that buys you. "The reviewer's seat" becomes a fact of the registry rather than a convention. A review dispatched by mistake onto the seat that is meant to hold something else does not quietly consume it — it is refused, and the refusal names the reason.
⚠ A refusal at placement is free. It happens before a session starts, so the honest way to find out whether a seat will take your work is to ask, not to reason about it.
What a seat does not decide
- It does not decide what the session may run — that is the permission class.
- It does not decide what the session may reach — that is egress.
- It does not decide what may land — that is a human gate.
⇒ Seats, classes, egress and gates are four independent controls; see Agent security: the whole set.