# Teams, members & roles

Every Koo account is a shared workspace. A member is a user with a role in the account, and every action — viewing logs, deploying, changing billing — is gated by that role. You manage members through the [accounts API](/api/accounts); each entry is a [member object](/api/objects/member).

## Roles

Each member holds exactly one of four roles. Roles are cumulative: every role can do everything the roles below it can.

> **Note:**
>
> An account always has exactly one owner. You can't demote or remove the current owner directly — transfer ownership to another member first, then change or remove the old owner like any other member.

## Manage members

Any member can list an account's members. Changing roles and removing members requires the owner role.

### Change a role

Set the member's new role on their membership. The change takes effect on the member's next request — there's no re-invite or re-login step.

### Transfer ownership

To hand over the account, assign the `owner` role to another member. The transfer is atomic: that member becomes the owner and the previous owner becomes an `admin` in the same operation, so the account never has zero or two owners.

### Remove a member

Removing a member revokes their access to the account immediately. It doesn't delete their Koo account or their other memberships — they just lose access to this one.

## Invite a member (Coming soon)

Invitations will work by link, not by direct add — joining an account always requires the invitee's consent.

1. 
2. 
3.

Accepting will be refused if the account is already at its plan's seat limit; the owner will need to add seats or upgrade first. Until invitations ship, there is no way to add a member to an existing account.

## Seats & plans

Each plan includes a number of member seats, and members beyond the included count add a per-seat charge to your subscription. See [Billing](/docs/account/billing) for the seat counts and per-seat pricing on each plan.

## Service accounts are different (Coming soon)

A service account will be a non-human principal for CI and automation: it will belong to one account, hold a role of its own — `reader`, `editor`, or `admin`, never `owner` — and authenticate with `kc_…` tokens — see [API tokens](/docs/developers/api-tokens).