Chats, chat admins, and adding people

Every chat has chat admins and members, nothing else. How Add People decides between joining now, an invitation, and a request, and what Who can join shows.

There is one kind of chat. A chat belongs to the people in it, no workspace holds one, and it lives exactly as long as it has members. Nothing about a chat is fixed at birth: whoever starts it is simply its first member and its first chat admin, and everything after that is governed from inside the chat.

A direct message is not a separate kind. It is a two person chat, with the same admins, settings, and events as any group, and a group that shrinks to two people is a direct message by arithmetic. Nothing converts in either direction. The one special default: a chat born with exactly two people makes both of them chat admins. "Message" on a person or an agent opens your most recent chat containing exactly you and them, or composes one.

Chat admins and members

Role is chat admin or member, and that is the only axis: a roster row reads "Chat admin" or nothing. Chat admins promote and demote admins, add and remove anyone, and hold the chat's settings. Members see everything, can add people when the settings say so, and can always leave.

A chat is never without an admin. If the last chat admin leaves, steps down, or their account ends, someone already in the chat is promoted automatically, and the promotion posts with its trigger: "alice@acme's account ended. dana@acme is now a chat admin (Acme admin)." No workspace is ever installed as a chat admin.

Starting a chat asks no governance questions. The compose flow runs in stages: if you hold more than one account it first asks who you want to chat as (skipped entirely when you only have your personal account), then you pick the people and agents. If a picked agent's rules don't cover the picks and you hold those rules, a decisions stage appears next, the same choice adding to an existing chat offers: update the agent's rules to include the named people (or anyone at their workspace), add it paused, or leave it out. A final stage then shows your picks, offers an optional chat name, and creates the chat. The creator is the first chat admin (both people are, in a chat born with two), and picks that need someone's decision do not block creation: the chat is created immediately with the eligible picks, and the gated ones ride as one request attached to it. The button says so: "Create chat and send request", with the strip above it naming who decides.

The picker offers people and agents you already share something with: a chat, or a workspace. Someone you have never met and share no workspace with does not appear, and nor does an agent whose workspace you are not in unless you already share a chat with it. A private agent is offered only to whoever can actually place it, so sharing one chat with someone else's private agent does not put it in your picker. The person who invited you to Bolter is always there too, even if you share nothing else yet, so the first chat you start can be with them. To reach anyone else outside that circle, invite them to a workspace, invite them to the chat by email, or type their exact username: the picker looks it up for you as you type and shows whoever it matches under "From username search", below your usual results. The match has to be exact, a partial username finds nobody, and a person found that way joins when they accept, never directly. Someone who has set themselves unlisted is not found by username search at all. See Workspaces, accounts, and limits.

Starting a chat straight from an agent (the "New chat" button on its profile, or the new-chat icon in an existing chat with it) skips those stages and chats as your account in that agent's workspace, so the chat stays inside the workspace the agent can speak in. If you want to start it as a different account, use the full compose flow instead.

Who can join

Every chat carries a "Who can join" bar and roster: the accounts in it (up to three names, then a count such as "12 people"), how many are invited, a join link if one exists ("Link (anyone with it)"), and its agents. A chat whose members are a whole workspace says so instead: "Everyone at Acme", with several workspaces joined by "+". Pending invitations and pending asks render there too ("1 invited"; "asked; with Acme admins"), rescindable by whoever made them.

The three settings

A chat has exactly three governance settings, held by its chat admins:

• Who can add people: chat admins only, or everyone. The default is everyone.
• People can be added from: off by default. When set, it names the workspaces members may add people from. A member's pick from anywhere else, personal accounts included, is not refused: it rides as a proposal to the chat's admins. The setting never binds chat admins' own adds.
• Open to everyone at a workspace ("Open to everyone at Acme"): a two step setting, one row per workspace. The first step lists the chat: anyone at that workspace can find it on the workspace's Chats tab and join. Nobody is added automatically, and every join is checked like any other add: workspace limits still apply, and a gated join rides as a request. Joining shows the chat's history and connected apps. Turning it off stops new joins and removes nobody. From a listed workspace, a chat admin can take the explicit second step: add everyone automatically. That adds everyone at the workspace now, and people who join the workspace later are added automatically. The confirm says how many people it adds before anything commits, history and connected apps become visible to the added people, and leaving still sticks: nobody who left is swept back in. It is offered by the chat's admins and committed by the workspace's admins; until committed the row reads "Offered.". The second step is never reachable directly from off. An active second step reads "Everyone at Acme is added now, and on joining the workspace." Ending it removes nobody, and if the chat is still listed to that workspace it simply stays findable there.

Adding people

Adding is direct by default: pick someone and they are in, with a loud arrival in the chat and a one tap way out on their side. Every add flow is the same Add People surface, and each pick carries a tag saying exactly what will happen:

• "Already here", "Already invited", "Already asked": facts, and the only things that ever disable a pick.
• "Joins now": a direct add.
• "Joins when they accept.": an invitation, described below.
• "Needs this chat's admins.": your pick goes to the chat's admins, because adding is set to chat admins only, or your pick falls outside "People can be added from".
• "Needs Acme admins.": a workspace's limits gate the pick; see Workspaces, accounts, and limits. It is an ask, never a wall, and the strip under your picks explains it in full: "Acme limits who can share chats with its accounts. Adding alice@acme goes to Acme admins as a request."

A pick can touch several gates at once; it still goes as one request, and the tag names everyone who will decide, in order. Each pick keeps its own tag: picks that need nobody's approval join right away, even when another pick in the same act goes as a request.

Beside the search box, a workspace filter narrows the suggestions, the same filter the New chat picker has. It offers every workspace you are in, and it starts with the ones already represented in the chat selected: if you are in Acme, Betacorp and Compinc, and the chat's members and agents come from Acme, Betacorp and Deltabrand, then Acme and Betacorp start selected, Compinc is one press away, and Deltabrand is not offered because you are not in it. Choose "All workspaces (no filter)" to search everyone. When a search finds nobody, the results space says which workspaces it looked in and offers a "Search all workspaces" button that lifts the filter for you, so you do not have to go back to the chip.

Before anything commits, the confirm shows who can join afterwards and the line "History and connected apps become visible to the people added.", because joiners can read everything that came before. See Who can see what.

Invitations

An add becomes an invitation, addressed to the exact account that was picked, in two cases: the picked account is set to require approval before joining chats (a per account setting, off by default), or the person is outside your circle (no shared chat, no shared workspace). The picker never lists people outside your circle, so the second case only happens when you type their exact handle; they join when they accept, never before. Either way it renders to you as "Joins when they accept."

An invitation waits 14 days, then lapses on its own. It can be rescinded from Who can join, and it dies early if the chat is narrowed in a way that would no longer admit it. A decline reports to whoever sent the invitation; beyond that, delivery is never disclosed, and sending always reports "sent" identically.

Inviting by email

You can invite someone by typing their email address, in the new chat picker or in Add People. If the address belongs to someone in your circle, it simply resolves to them. Otherwise it becomes an invitation labeled by the email, shown in Who can join like any other pending invitation and rescindable the same way. Whether an address belongs to an account is never disclosed: an email invitation looks the same either way.

If the address has no account behind it, Bolter emails an invitation. The recipient signs up with that email address, finds the invitation waiting, and joins when they accept. The email itself grants nothing; proving ownership of the mailbox at sign-up is what makes the invitation theirs. Email invitations count against your daily invite limit, and if the invitation email cannot be sent the invitation is not created.

In a chat where only chat admins can add people, email invites are for chat admins too: a member typing an address is told to ask a chat admin to send it. The same refusal applies in a chat restricted to a workspace when your pick would need someone's approval: an email invite cannot ride a request, so ask one of the people named in the message to send it.

Requests

When a pick needs someone's decision, the whole act goes as one request, however many gates it touches. The strip says exactly two things: "These picks need <audience>. They go as one request." and "They will see this chat's name and your picks."

While it rides, you see a pinned line in the chat, "Your request is with Acme admins.", and the picks show in Who can join with their audience. The same pick cannot be asked twice. The rest of the room sees that something is pending and with whom; only the deciding audience sees the chat's name and the full picks.

Deciders see every pick individually and can let some in while striking others. The resolution posts as one event naming who acted and who asked ("dana@acme let in priya@skunkworks, after alice@acme's ask."). Admins Deny; a denial goes quietly to you, naming the decider and any reason. The room never sees a denial: the pick simply leaves Who can join, indistinguishable from a lapse.

Requests keep up with reality on their own. One whose reason disappears, say the setting changed or an allowance now covers it, is satisfied by that alone and commits with nobody clicking anything. One that a narrowing no longer admits dies quietly. One whose pick has already come true resolves itself.

Join links and listings

A chat admin can mint a join link: a standing invitation to whoever holds it. It renders in Who can join as "Link (anyone with it)" and is revoked there. A claim counts as that admin's own add of the claimant, checked at the moment of claiming: the same facts and the same workspace limits apply, and a gated claim rides as a request. Someone with several accounts picks which one joins. A link dies on its own when the chat is narrowed so that nobody new could claim it.

A chat admin can instead scope a standing invitation to one workspace: a listing, which is what the "Open to everyone at a workspace" setting above mints. It surfaces the chat on that workspace's Chats tab so its members can join themselves. A listing commits nobody and adds nobody automatically, and every claim is checked like any other add. Listing and revoking both post a line in the chat, so the room has a record of when it became findable.

Agents in a chat

Agents appear in Who can join like everyone else, and a chat admin can remove one at any time. Each agent has rules naming whom it may work among, held by whoever owns it; see Agents, ownership, and visibility.

Adding your own agent is immediate when its rules cover the chat, and the add states plainly what it means: the agent "reads this chat as alice does", history included. When the chat is outside its rules, whoever holds the rules settles it. If that is you, you settle it in the same add: widen the rules to the named account or to anyone at their workspace, pause the agent here, or leave it out. If not, the pick rides to the rules holder ("scout@acme needs Acme admins."). A workspace's agents belong to its admins, so picking one from outside that workspace also rides to them as a request ("Needs Acme admins."). A person's own agents ride the same way, to that person ("Needs alice."): they alone decide, and their request row says plainly that this is their private agent being placed by someone else.

The other direction happens too: adding a person can push an agent already in the chat outside its rules. If you hold the agent's rules, the same add settles it. If you do not, the pick warns you plainly ("Adding maya pauses Atlas.") and the agent pauses: badged, not reading, not acting.

A paused agent never resumes by itself, even if the chat shrinks back inside its rules. Its owner chooses between "Resume and catch up" and "Resume from now"; resuming from now permanently leaves the paused stretch out of what the agent ever sees. The fix is reachable where the problem is stated: the pause line in the chat and the agent's row in Chat settings both carry a Resume action for whoever holds the rules (everyone else sees who does), and when the chat is still outside the rules, resuming also updates the rules to cover its members, so the agent doesn't just pause again.

A personal agent stays only while its owner does: if the owner leaves or is removed, their agents go with them.

Leaving, removal, and the end of a chat

Leaving loses the chat and its history, removal comes with a receipt you keep, and a chat ends for good when its last member goes. All three are covered in Who can see what.