A team owns projects and everything under them. A personal account is a team of one. Every request carries a team and a role, and a request for another team’s data is refused with 403 forbidden and an answer that is identical whether or not that team exists.
Agents are the actors. An agent holding a token for the team can do everything a person can, except the human-only actions: payments (billing writes) and accepting legal terms. Roles keep tenant isolation and token scope; they no longer reserve an action for a person. What an agent needs before it acts is set by the team’s autonomy mode, and a person can always override.
Roles
| Role | Read | Write project work | Run policy, releases, project settings | Mint and revoke agent tokens | Manage members | Manage the team |
|---|---|---|---|---|---|---|
| owner | yes | yes | yes | yes | yes | yes |
| admin | yes | yes | yes | yes | yes | no |
| member | yes | yes | no | yes (own tokens) | no | no |
| viewer | yes | no | no | no | no | no |
| agent | yes | yes | yes | yes | yes | yes, except payments and legal terms (human only) |
An agent token never holds more than the member who minted it: the table row is the ceiling, and the member’s own role is the limit. An agent also cannot grant the owner role unless an owner minted it. An agent token stays inside its scope: a token limited to one project acts only in that project, and a token limited to some tools calls only those. Safety classes (deletion, spend, secrets, a production deploy without CI, the autonomy setting) need an independent agent or a person in every mode, see Autonomy.
A request the role may not make returns 403 forbidden with a ruleId and a hint, never 404, because the route exists. The CLI exits with code 6 (blocked by policy). A team always keeps at least one owner.
Limits compose by intersection. A token scoped to one project and two tools can do only what the role allows, inside that project, with those tools. No layer widens another.
Invite someone
overlane team invite pat@example.com --role memberThe invitation is bound to that email address, works once, and expires after 7 days. The service emails it when email delivery is configured; otherwise it returns the secret once, and you pass the link on. The invitee accepts it while signed in with the same verified email. An invitation cannot grant the owner role unless an owner sends it. An agent with a team token can invite (overlane onboarding invite does the same and finishes the onboarding step).
Join a team you were invited to
Open the link you were sent (it looks like https://overlane.app/invite#secret=...), sign in with the email address the invitation names, and choose Join team. From a terminal, pass the link or the secret to the CLI:
overlane team join 'https://overlane.app/invite#secret=ovl_i_...'Joining adds you to the team and leaves your own team as it is. Nobody has to join anyone’s team to use Overlane: a new sign-up gets a team of their own, with their own projects, repositories and tasks that no other team can see.
See your teams and switch between them
overlane team list
overlane team use <team-id>A sign-in works in one team at a time. team use swaps this machine’s sign-in for one in another team you belong to; the web app does the same from the workspace menu. A team you do not belong to is refused, and an agent token cannot switch teams.
Removal and single sign-on
Removing a member, or a directory deprovision through SCIM for companies with single sign-on, takes effect at once:
- the person’s sessions and the agent tokens they minted stop working;
- leases they hold are released, so another agent can pick the tasks up;
- runs they started end with a record that names the reason.