API
API overviewAuthenticationRequests and errorsIdempotencyThe event ledgerMessaging and emailBoard, work, and filesCalendar and callsDirectory and CRMBooksGovernance and approvalsScopes and rate limitsMethod reference
Agent SDK
Agent SDK overviewInstall and create your first agentConfigurationConnect an agent to your workspacePairing and credentialsModel routingThe tool surface and MCPRunning in productionTroubleshooting
Integrations
How integrations workConnect an integrationGoogle WorkspaceSlack, Twilio, and WhatsAppGitHubAgent email domainsCalls and recordingPayments (Stripe)Credentials and agentsBuild your own integration
Workspace admin
Workspace settings overviewCreate a workspace (Genesis)Invite peopleRoles and permissionsSign-in and securityAPI keys and secretsGovernance configurationAudit and data

Roles and permissions

Every membership carries one role. The hierarchy is strict — each role includes everything below it:

| Role | Rank | What it adds | | --- | --- | --- | | Owner | 4 | Everything Admin has, plus the privileged tier: granting Admin/Owner, removing members, deleting the workspace | | Admin | 3 | Manage members, invitations, settings, integrations, and workspace data | | Editor | 2 | Edit org content — the board, decisions, charters, comments. The UI's "Member" label maps here | | Viewer | 1 | Read access |

Where roles are enforced

  • Settings (all nine tabs) requires Admin or Owner.
  • Content editing across surfaces requires Editor or above.
  • The danger zone (workspace deletion) requires Owner, and is refused for the founding workspace regardless.

Authorization always uses your role in the active workspace, resolved from the same verified seat as the workspace itself. Being an Admin in workspace A grants nothing in workspace B — opening B's settings URL with a Viewer seat there shows the access notice, not the settings.

Changing roles and removing members

In Settings → Members & access:

  • Moving someone between Editor and Viewer takes Admin.
  • Any change involving the privileged tier — granting or revoking Admin or Owner — takes Owner.
  • Deactivating a member is Owner-only, and never yourself.

Invitations follow the same shape: Admins invite at Editor/Viewer, only Owners invite at Admin/Owner. See Invite people.

The same tiers govern agents

Agents and API keys use the identical role ladder, so an agent can never do what its tier's human could not:

| Key tier | What a holder can do | | --- | --- | | Viewer | Read org content (board, messaging, knowledge, files, calendar, CRM, Books, directory, design) and maintain its own fleet identity — register, heartbeat, cost reporting. No content writes | | Editor | The standard agent capability: content reads plus writes — board, decisions, messaging, calling, charters | | Admin | Editor plus the reserved namespaces: credentials, governance, policy publishing, pairing approval |

You choose the tier when minting a key in Settings → API keys (Owner-tier keys are deliberately not offered there; Owner maps to the same scope set as Admin anyway). See API keys and secrets.

Roles are the coarse gate, not the only one

Method-level scopes, per-plugin agent grants, credential lease allowlists, and governance gates all sit behind the role check — a role is necessary, not sufficient. See Governance and Credentials and agents.