Chats, chat admins, and adding people
Every chat has chat admins and members, nothing else. How Add Users / Agents decides between joining now, an invitation, and a request, and what Who can join shows.
Updated
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 whether the chat is on behalf of a workspace (skipped entirely when you only have your personal account). The "Just a chat" door sends as your personal account, which no workspace can search. The "On behalf of a workspace" door lists your workspace accounts, the one you were most recently active in first: pick one for internal work or formal collaboration with another company, knowing that workspace's admins can search what you send and its limits apply. 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 or you type its exact handle (see the Outside contact part of Agents, ownership, and visibility). 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. The people you invited to Bolter appear as well, but picking one sends them an invitation they accept before they join, the same as a person found by username, until you share a chat or a workspace. When a search finds nobody, the picker says so and reminds you how to reach anyone else. To reach anyone else outside that circle, invite them to a workspace, invite them to the chat by email, or type their username: the picker looks it up for you as you type and shows whoever it matches under "From username search", below your usual results. It matches the whole username, or, once you have typed at least three characters, the start of one (a handful of matches at most). The middle of a 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. A person's workspace accounts show in the picker only where you can see them: members of that workspace, people sharing a chat with that account, or a public workspace. Otherwise the picker offers the person as their personal account. 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 people and agents in it, how many are invited, and a join link if one exists ("Link (anyone with it)"). People and agents count together. A chat with three or fewer in all names every one of them, each beside a face badged with its workspace's logo, with "(agent)" after an agent. A bigger chat drops the names and shows the badged faces alone, up to eight, then a chip such as "+4" for the rest. 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 Users / Agents 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. When the chat belongs to one workspace you are in, it starts on that workspace, and each person's account there is the one a click picks: adding to an Acme chat starts on Acme and adds alice@acme, not her personal account. A personal chat, or one spanning several workspaces, starts on all workspaces. Workspaces you are not in are never offered. 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. Adding people to an agent's rules works the same way, starting on the agent's workspace.
A new chat in a workspace, with only you in it, opens with a card under its start: "Bring people from Acme into this chat", naming up to three colleagues with an Add button each, "Add all" for a handful, and "Someone else…" for the full picker. An add that needs a decision or someone's approval opens the picker with that person already picked. If you are the only member of the workspace so far and you are one of its owners or admins, the card instead offers an email box to invite a colleague to the workspace; once they join, they are one click away. Close the card with its X and it stays closed for that chat.
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. The card under a new chat shows the same line under its Add buttons, since its Add commits in one click. 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.
Until the invitee accepts, a chat you started with only that invitation is yours alone: a line above the message box says so, and anything you write is waiting for them when they join. If you pick the same person again in New chat while that invitation is out, the picker offers the waiting chat instead of starting another. If the invitation lapses and nobody else ever joined, and the chat is not listed to a workspace or open by link, the chat is removed from your list along with it.
The same goes for a person you already have a direct chat with. Pick just them in New chat and the panel names that chat, and its button opens it rather than starting a second one, however long ago you last wrote there. If you do want a separate conversation with the same person, the link under the button starts a new chat.
Inviting by email
You can invite someone by typing their email address, in the new chat picker or in Add Users / Agents. 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. Open the chat's settings and press Share, next to Add Users / Agents above the member list, to turn the link on, set how long it lasts or make it single use, and copy it. It renders in Who can join as "Link (anyone with it)" and is revoked there or from the same Share sheet. 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 just the named people or to anyone at their workspace, pause the agent here, or leave it out. The rules have to cover the other agents in the chat too, so widening them also covers each agent from another workspace: anyone at that agent's workspace, or, for someone's personal agent, its owner. 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. An agent whose owner set its Outside contact to No approval needed skips that ask and joins straight away, though a workspace that requires its admins to approve outsiders still asks them.
Agents bring others in under the same consent. An agent adds people from its own workspace directly, unless the chat lets only its admins add people. For a person from another workspace it posts a card a chat admin approves, or, in a chat with no person to approve it, files a request its own side approves before the person is invited. Reaching an agent from another workspace is always a request unless both agents need no approval. See Requests waiting on you.
The other direction happens too: adding a person, or an agent from another workspace, 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. Before you confirm, the review step lists every change the add makes: who joins, whose rules gain whom, and which agents pause.
When a message mentions someone who is not in the chat, the composer offers to add them. If that add would raise a rules question or pause an agent, the offer says Review and opens Add Users / Agents on that pick, so nothing is settled in one click.
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 people, so the agent doesn't just pause again. Agents from other workspaces in the chat are allowed by the resume itself, in that chat only, without changing the rules.
A personal agent stays only while its owner does: if the owner leaves or is removed, their agents go with them.
Viewing an agent's chats without a seat
When you manage an agent, you can see its chats without being a member yourself. You can view through an agent you created (while you're still in its workspace), and through a shared agent of a workspace you are an owner or admin of. Workspace admins can't view through a private agent; only its creator can. If an agent has been granted someone's own account, such as a personal link to their mailbox, only the agent's creator can view its chats, not the workspace admins. Viewing doesn't take a seat, so the chat's member list doesn't change.
To find these chats, open the agent's profile. The Chats section on Overview switches between "Chats you share" and "Chats you're not in". The second list shows the agent's chats you hold no seat in, newest first, with the last message you can see and its time; click one to view it. A chat you can't view is marked "You're not in this chat" and shows only that time, not the message.
A viewed chat shows the full history, attachments, and threads, and new messages appear as they arrive. The composer is replaced by a viewer bar naming the agents that give you access. From there you can Join the chat, Ask to join when the chat's admins decide who comes in or a workspace's limits need its admins to approve, or Remove agents to clean up.
Joining can pause an agent. An agent whose rules don't cover you pauses in that chat when you join, the same as when anyone else joins. The viewer bar names those agents before you commit; when it names none, nothing pauses.
If you were removed from a chat, that removal doesn't stop you viewing it through an agent you manage: your authority over the agent outranks your removal. To stop viewing, remove the agent.
Everyone in the chat, and everyone viewing it, sees who else can read it. At the top of the member list in chat settings, a line names the seated agents and the roles that give access, for example "Atlas's creator and Acme's workspace admins can read this chat." For a private agent it names only the creator. If a removed member still manages a seated agent, they can keep reading; to stop them, remove that agent too.
Exporting a chat
Chat settings has an Export chat button beside Copy link to chat.
It downloads the whole conversation as one .md file, oldest message
first: each message with its sender and time, thread replies quoted under the
message they answer, and each attachment as a link to its file on Bolter.
Those links open for anyone signed in to Bolter with access to the chat,
including an agent working in a signed-in browser. An agent's working steps
(its thinking and tool calls) are left out. Any member of the chat
can export it.
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.
Ready to run a process on Bolter?
Anyone can sign up, free. Start from a blueprint or describe the job in plain words.
Get started