Seats, roles, and a console that decides what each role can reach.
What a Team workspace includes.
- SeatsFrom 2
- RolesOwner, admin, member, viewer
- ComputeCloud · hosted by us
What an admin can change about a teammate.
A seat is occupied before anyone accepts
An active member holds a seat and so does a pending invitation, so the count an admin sees is the count that is actually spoken for. Revoking an invitation or removing a member frees its seat straight away, and leaving a workspace releases your own.
Owner and admin are the two that administer
Owner and admin invite, revoke, change another member’s role and edit workspace policy. Member and viewer do none of it. An owner who wants out nominates a successor first, and the handover and the departure run as one operation so the workspace is never left without an owner.
A private link you send yourself
No transactional email provider is wired up, and the product states that plainly: you create the invitation, copy the private link, and pass it on. The token is hashed, expires after seven days, and opens only for someone signing in with the address it was issued to.
Projects and connectors the workspace can open
Share a project and members read its instructions and knowledge files while each member’s own conversations stay private; you can withdraw any single member’s access without unsharing it from everyone. Share a remote MCP connector once and every member can call it, while its stored credential stays out of their reach.
Every control has a page, and the page says whether it binds.
- EnforcedA server-side check refuses the request, whichever client it came from.
- Stated positionRecorded for this workspace, with nothing acting on it at runtime yet.
- Not configuredNo row has been saved here, so the shipped default applies.
Read each row below for which of those three currently holds: a recorded position is never described the same way as an enforced one, which is the difference a security reviewer is there to find.
- OverviewThe posture view for the whole workspace, listing every control and which of the three states above it currently carries.
- MembersRoles, invitations and seats, available from the Team plan up. Removing someone cuts their live sessions, device refresh tokens and API keys along with the membership row, records anything it could not reach, and leaves their personal account intact.
- PolicyWhich privacy modes the workspace allows, whether AGI managed cloud may be used at all, and which client surfaces may sync. A refusal comes back from the server before the turn runs and is written to the audit trail.
- ModelsAllowed and blocked providers and models, picked from the shipped catalog so a typo cannot become a rule that governs nothing. The check runs after auto-routing has resolved, so asking for Auto cannot reach a blocked model, and every failover candidate answers to the same saved policy the first choice answered to.
- ConnectorsWhich integrations members may use, and whether they may add their own. The list is read while a member’s tool set is assembled, so a blocked connector never appears in it.
- Usage and billingSpend broken down by member, model and provider, alongside the plan, the seat count and invoices. An owner or admin can also set a monthly cap for the workspace and choose whether crossing it notifies or blocks.
- Identity, audit and dataSSO, SCIM directory sync, the audit trail and its JSONL export, legal holds and retention sweeps. These sit behind the enterprise entitlement, one step above the Team plan, and /enterprise states which of them are built and which are commitments.
Start at 2 seats and add people as the work needs them.
The seat count is the only thing anyone has to settle up front, and it moves from the billing page whenever it needs to. Roles, shared projects, approved models and approved connectors are all set afterwards, from the console, by whoever holds owner or admin. Work a member runs locally, or on their own provider keys, never reaches AGI’s servers at all, so it sits outside what this console can govern.