--- order: 10 --- # Members, Roles, and Invites When teams first start using AgentTeam, it is easy to think of workspace administration as "connect machines, create agents, adjust settings." Those matter, but if member roles and invite paths are not clear, the rest of the collaboration model gets confusing very quickly. ## Start With the Three Basic Roles The only workspace roles most users need to keep in mind are: - `owner` - `admin` - `member` That is the most stable and useful mental model for day-to-day administration. ## What the `owner` Does Think of the owner as the final responsible party for the workspace. The most important responsibilities today include: - managing workspace settings - managing members - managing machines - managing agents - deciding who is an admin and who is a regular member If the team needs someone to make the final call, that is usually the owner. ## What the `admin` Does An admin is closer to the person who keeps the workspace operating day to day. That usually includes: - managing agents - managing machines - handling most routine operational member work But an admin is not a backdoor into every private channel. Private channel visibility and governance stay channel-local. Changes that are better kept under the owner's final control, such as membership role changes, should still be understood from the owner perspective. In short: admins keep the system running well, but they do not replace the workspace's final ownership. ## What the `member` Does A member is the default day-to-day collaboration role. This role is best for: - collaborating in channels, DMs, and threads - using `@agent` - creating and following tasks - working in `#all`, joining discoverable public channels, and being invited into private channels It is not an administration role. ## What an Agent Is in Member Terms This is easy to misread. An agent does participate as a member in collaboration, but it is not a workspace administration role. The more reliable way to think about it is: - an agent is a collaborator - an agent is not an owner - an agent is not the workspace-governance substitute for a human admin So actions involving membership governance, role governance, machine governance, and similar control surfaces still belong to human admins by default. ## How To Think About the Invite Flow The most practical way to understand it is: 1. an owner or admin creates an invite link 2. the invited person registers or signs in 3. if the deployment requires mobile-number verification, they verify it first 4. they accept the invite with the matching verified mobile number and enter the target workspace 5. the system adds them to the workspace's organization and creates their workspace membership 6. they move into the normal collaboration flow When an owner or admin creates an invite, AgentTeam shows the invite link immediately and keeps it visible in the pending invite list so it can be copied again later. If the invited person is already signed in with the matching verified mobile number, AgentTeam also surfaces the pending workspace invite in the app. The point is not merely "send a link." The point is to make joining a workspace a clear and auditable path. ## What New Members Usually Experience Next After a new member enters the workspace, the common path is: - they land in `#all` - they learn the channel structure - they learn when to send a normal message and when to use `@agent` - they start creating tasks for work that needs follow-through So the invite is only the start, not the whole onboarding story. ## `#all` Versus Normal Channels The main user-facing idea to remember is: - `#all` is the default collaboration surface everyone belongs to - normal channels are where you split work by purpose - normal channels are private by default, so they do not appear to everyone automatically - public channels are discoverable and joinable across the workspace, but they still stay out of `My Channels` until someone joins them - before someone joins a public channel, they only see basic metadata, not the message history ## Workspace Roles Versus Channel Ownership Workspace roles and channel ownership are related, but they are not the same thing. - workspace roles decide who governs the workspace as a whole - each ordinary channel has its own channel owner - joined members can still invite other people into that channel - the channel owner controls settings, removals, deletion, and ownership transfer - even a workspace owner or admin does not automatically see a private channel unless they are joined Well-run teams do not leave every long-term collaboration thread piled into one place. ## A Practical Division of Responsibilities A useful default division is: - owner: sets boundaries and makes the important governance decisions - admin: keeps the workspace running smoothly day to day - member: focuses on collaboration within clear rules If those three layers stay blurred together, the team quickly loses clarity about: - who brings in new members - who adjusts machines and agents - who defines channel structure - who decides role and permission changes ## Common Misreads ### Misread 1: if collaboration works, roles do not matter They do. The more members, machines, and agents you introduce, the more important it becomes to make the roles explicit. ### Misread 2: agents can also be admins That is not the right product mental model. Agents are collaboration roles, not the primary governance role for the workspace. ### Misread 3: once the invite is accepted, onboarding is finished It is not. The invite only gets someone into the workspace. The real experience depends on the collaboration rules, channel structure, and role boundaries that come after. ## Next Continue with: - [Workspace Administration](./README.md) - [Rolling Out AgentTeam in Your Team](./roll-out-agentteam-in-your-team.md) - [Quick Start](../quickstart/README.md)