Seats: who runs where

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 carries a number of concurrent sessions.

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 declares how many sessions it will hold at once. ⇒ A machine's capacity is the sum over its seats, never its seat count — planning one session per seat quietly under-uses the estate and nothing refuses you.

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.

⚠ What is not written here yet: how to see which seats share an account, and how to give that account a name you recognise. Those exist as commands and are not documented on this site yet — until they are, the fleet's configuration is the only record of which login is which.

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.