Roles and capabilities
What each role gets by default, and what to grant individually.
Three roles, around forty capabilities. Roles are defaults; capabilities are the truth.
Defaults
Owner — every capability, including deleting the workspace and transferring ownership.
Admin — everything except those two.
Member — day-to-day work: chat and sharing threads, editing their own agent, resolving escalations and human handoffs, selecting copy voice, creating and editing routines and automations, reading the workspace.
What members deliberately do not get
Each of these is withheld for a stated reason, not by oversight:
| Capability | Why it is owner/admin |
|---|---|
| Billing read and manage | Financial data is as sensitive as billing itself |
| Finance read | Same |
| CRM manage | Reshapes the CRM schema for everyone |
| Integration sync admin | Repoints where records sync to |
| Memory manage | Memories reach every agent's prompt |
| Studio manage | Creates and destroys working directories, binds git credentials |
| BYODB manage | Moves where the workspace's data lives |
| Device manage | Relocates local data on someone's machine |
| Hub manage | Controls routing for everyone's inbound |
Overrides
Any capability can be granted or revoked per member without changing their role. That is the right tool when someone needs exactly one extra power.
Gotchas
- Capabilities hide surfaces rather than disabling them. A member without one does not see a greyed button — the surface is not there.
- Approval capabilities are per type, so delegating escalations does not delegate budgets.