Members and inboxes

What a member is

A member is an AI team member: the one who does the work. Each has a name, a picture, a persona, and an email address with a mailbox behind it. Members hold roles, sit on teams, and carry out tasks as runs.

A member is not a person. Members never sign in to the portal; the humans who do are people.

Creating a member

Members → Create, in the portal:

The address is the member's name on the enterprise's domain: lower case, accents dropped, and spaces and dashes turned into dots. Jules at Northstar is [email protected]; Mary-Jane van Dyke would be [email protected]. A name long enough to make more than 64 characters before the @ is cut to 64. A name that leaves nothing for the address, such as one written only in Chinese characters, is refused (invalid_member_name).

The address names the member, not the job, and no two members in an enterprise can share one. A second member with the same name is refused, so give them a name that tells them apart, such as a middle initial.

The persona

The persona tells the member who it is. A member reads it whenever you talk to it in chat, alongside its roles and what it can do. Give members on different teams different voices: two members should read as two people.

Change it any time on the member's page, under Persona. An empty persona means none.

Who does the work

A task is given to a role, never to one member. Each run goes to a member who holds that role on the task's team and is free, the one who has waited longest first. A role with no team is enterprise-wide, and its holders take its tasks wherever they sit. If nobody can take the role, the task cannot start. The OS's own tasks need no role, and run with no member.

A member does one run at a time. Work that reaches a busy member through a handoff, a retry, a webhook or a chat waits, and starts when they are free. A start from the task's page, or a scheduled start, is refused instead and recorded as skipped. A run waiting on your decision at a gate does not keep its member busy.

A member's page shows their Active run and their Tasks: the tasks of the roles they hold on each task's team. Members who hold the same role list the same tasks.

The inbox

Every member receives mail at their address. Mail sent to their address with a + tag, such as [email protected], reaches them too. Mail to an address that belongs to no member is not kept.

Inbox, on the member's page, lists what has arrived, newest first, with unread messages marked. Open one to read it and download its attachments. Opening a message marks it read.

The mailbox is shown in tabs, and each count is for the whole mailbox:

• Inbox is open mail that no task has labelled yet.
• A tab per label is open mail carrying that label. Labels are whatever the member's tasks give a message; the OS has no fixed list. A label with no open mail has no tab.
• Archive is everything closed, whatever its label: mail that was answered, mail a task left on purpose, and the member's own sent copies.

A message is open while it is unhandled, waiting on a decision, or snoozed. It is closed once it is replied to or skipped. When a decision about a message is rejected, times out, or its run is cancelled, the OS closes the message, so it moves to Archive instead of staying under its label.

A member's tasks read the same mailbox with two of the OS's built-in tools: os.mail_list lists messages and os.mail_read opens one (Built-in tools). A run can only ever read the mailbox of the member doing it; the OS's own tasks have no member, and so no mailbox.

A task records what it decided about a message with os.mail_set_label and os.mail_set_handled, or about many messages at once with os.mail_set_many: by id, or every unhandled message from one sender.

A member's tasks answer from that mailbox too: os.mail_reply replies to a message in it and os.mail_send sends a new one. Every send waits for approval on the exact message first, and a run can only ever send from an address that delivers to its own member's mailbox.

This is how a member gets on with the outside world: signing up for an account in its own name, receiving the confirmation code, accepting an invitation. See GitHub for a member joining GitHub with its own address.

Sending

A member sends from their own mailbox with os.mail_reply and os.mail_send: a reply goes out from the address the message it answers arrived at, and threads under it, so the person reading it sees one conversation. The sent copy is filed in the member's mailbox, under Archive. Both are gated: nothing leaves until the exact message is approved, and a rejected or expired gate sends nothing.

Mail that is not from a member's own mailbox — a product notice, a newsletter — goes through a mail tool you connect and give the task, like any other system (tool directory).

An address is not an account

A member's address is an identity you can invite into other systems. It is not, by itself, an account anywhere else, a login to a vendor, or a quota of its own. A member gets its own account in a system only when someone creates one for it there and binds that account's credentials to the member.

Its own tools and models

A member's page has two sections for what is theirs alone:

• Agents: a model connection for this member's own account, used for their work before the enterprise's (Spend and models).
• Tools: tools bound to this member, with their own credentials. A binding here replaces the same tool bound on the member's team or the enterprise (tool directory).

Changing a member

On the member's page you can rename them, change their picture, persona, teams and roles, and change their address. A changed address has to stay on the enterprise's domain, and stay unique.