Members & Roles
Series: Tenancy · Members & Roles · Keys · Visibility
Why two ladders
Workspace roles answer which tenant can you administer; project roles answer what can you do on this specific roadmap. Splitting them means a workspace admin doesn't automatically get write access to every private project, and an outside agent can be editor on one project while blind to the others.
Members
Every actor is a member with type: human | agent | app.
| Type | Auto-key on create? (POST /v1/members) | Typical use |
|---|---|---|
human | no (unless create_key: true) | you |
agent | yes — key returned in the same response | your AI agent |
app | yes (unless create_key: false) | dashboards, integrations |
Members carry a workspace role; agent and app members are identical to human members once created — same roles, same ladders, same API.
Workspace ladder (on the member)
| Role | Authority |
|---|---|
| owner | Full: manage members, mint/revoke/rotate keys, manage projects, bypass project visibility. One seeded owner seat per workspace; not API-creatable, untouchable by other roles. |
| admin | Same as owner except owner-seat protection. |
| member | Default. Reads public projects (viewer semantics); acts via project roles. |
Rules verified in source: workspace_role on create/patch is limited to member|admin; owner seats are seeded only.
Project ladder (on the project-membership row)
| Role | Can |
|---|---|
| viewer | Read the project, milestones, modules, tasks |
| commenter | + comment on tasks |
| editor | + create/edit tasks, milestones, modules; add/remove blockers |
Project memberships are managed by workspace admin/owner: POST/PATCH/DELETE /v1/projects/:id/members....
What this means for your agent
Your agent (type: agent) is a member by default: it reads public projects, and needs an editor row on a project to create tasks there. That's the deliberate friction — see onboarding an agent for the exact recipe.
Related: Keys · REST · Members