Skip to main content

​
Your team is your organization

Everyone in your organization can open its workspaces. A person invites teammates, changes their role and removes them in the app, under Settings › Members. Invitations go out by email from there. Settings › Members shows your organization’s members and invitations right in the page, not in a pop-up. There you can:
  • invite someone by email and pick their role,
  • revoke an invitation that hasn’t been accepted,
  • change a member’s role,
  • remove a member.
The page lists what each role may approve above the member list. Once the invitee accepts the email, they are on the team. You can mention them on a change within a minute. If your workspace belongs to no organization yet, the page offers to create one instead. You stay its admin, and the members page replaces the form. No API key, assistant or agent manages members, and none can propose it. Over the API or MCP, POST /v1/invites, DELETE /v1/invites/{id}, PATCH /v1/members/{id} and DELETE /v1/members/{id} always answer 403 forbidden with details.reason members_human_only, whatever scopes the credential holds. The same goes for act on a member (invite, set_role, remove).

​
Roles

Each member has one role. It decides what they may approve, in the app and on every other door (an emailed reply, a Slack button, the API with their session). “Work that can be taken back” is a change whose effect class is pure, reversible or compensable. Irreversible work, such as an email to a person or a post on someone else’s site, is approved only by an admin. A change whose class is not recorded counts as irreversible. See Who can approve what.
  • A viewer who approves gets 403 with the code role_viewer.
  • An approver who approves irreversible work gets 403 forbidden with details.reason role_admin_required.
  • Anyone can decline. A no only ever does less.
A member with the organization’s default role (org:member), including anyone invited before roles existed, is an approver: they cannot approve irreversible work until someone makes them an admin. The owner of a workspace that belongs to no organization is its admin. A yes whose role nobody can confirm, such as one through a reviewer link, is held to an approver’s limit: it never approves irreversible work. API keys and assistants are not members. They are held to their own approve scopes instead, and never approve irreversible work. Nobody can hand a credential more than their own role allows:
  • A viewer cannot share a reviewer link, and cannot mint an API key with approve scopes (write included). Both are refused with role_viewer.
  • An assistant connected by a viewer (an OAuth connection) has no approve scopes. It can still read and steer.

​
Reading the team

GET /v1/members (not on MCP yet) lists the people in the workspace’s organization: user_id, name, handle, role, can_approve and can_approve_irreversible. It is read-only and carries no email addresses. A change to the team shows up within a minute.

​
Comments and mentions

In the app, a change’s review page has a Comments section below the review. Type @ in the box to open a menu of your teammates. The menu matches what you type against their handle and name, and shows each person’s role. Pick one with Enter, Tab or a click, and their @handle is written into the comment. Before you post, a line under the box names who will be told. Comments are listed oldest first, and a comment from an agent is marked as one. When nobody else is on the team yet, the section links to Settings › Members so you can invite someone. Anyone on the team, and any agent with a steer scope, can comment on a change: POST /v1/changes/{id}/comments with {"body": "...", "mentions": ["user_..."]}. GET /v1/changes/{id}/comments lists a change’s comments, oldest first. A comment is a note. It approves, stops and changes nothing. To mention a teammate, write @ and their handle in the body, or put their user_id in mentions. An @word that is no member’s handle stays plain text, so an email address is never a mention. A user_id that is no member’s is a 400. A comment mentions at most 20 people. Each person mentioned gets one email that links to the change, unless their own settings hold it back. It is an Attention message, so it follows that person’s own notification settings. Nobody else on the team is copied. Your integrations also get one comment.mentioned event per comment, listing the user ids it mentioned.

​
Mentions in a chat

A chat message can mention a teammate too. In the app, pick them from the @ menu in the composer. The message then carries their address, attensira://{workspace}/member/{user_id}. Over MCP or REST, put the same address in an ask message (POST /v1/threads or POST /v1/threads/{id}/messages). Each teammate a message names this way gets one email that links to the chat. It is the same Attention message as a comment mention, so it follows their own notification settings, and nobody else is copied. A person who names themselves is not told. At most 20 teammates are told per message. An address that names someone outside your organization, or another workspace, tells nobody, and the message still sends. A typed @handle in a chat is plain text to the agent and tells nobody. A chat mention sends no webhook event.