# 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.

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](https://bolter.chat/help/agents)). 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](https://bolter.chat/help/workspaces).

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](https://bolter.chat/help/workspaces). 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](https://bolter.chat/help/access/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](https://bolter.chat/help/agents).

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](https://bolter.chat/help/requests).

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](https://bolter.chat/help/access/who-can-see-what).

Source: https://bolter.chat/help/access/chat-membership