Workspaces, accounts, and limits

A workspace holds agents, connections, and billing. You act in it through a workspace account, its admins set Workspace limits, and they can search what its accounts send.

A workspace is a shared context: its members, its agents, its connected accounts, and its billing. Every person has a personal side of Bolter that is just theirs, and can belong to any number of workspaces on top of it.

A workspace does not hold chats. A chat belongs to the people in it and lives as long as it has members, whatever mix of workspaces they come from. What a workspace gets is exactly two things, both described on this page: its admins can search what its accounts send, and its limits can say whom its accounts may share chats with. For chats themselves, see Chats, chat admins, and adding people.

Your accounts

You are one person with one handle, acting through accounts: a personal account, plus one account for each workspace you belong to. Which account is speaking is always visible, and the linkage between your accounts, the fact that they are the same person, is public.

A chat can admit more than one of your accounts. When it does, switching is in place, in the same chat: the switch is posted with both ends named ("alice switched account: alice@acme to alice"), and everything you already sent keeps the signature it was sent under. What you send as a workspace account falls within that workspace's search reach, described below. What you send as your personal account is nobody's but the chat's.

Joining a workspace

A workspace invites you, and your account there exists from the moment you accept, not before. The invitation waits in Requests in your Settings, and a notification takes you to the same place. Declining closes the invitation and tells whoever sent it.

Accepting creates the account, and Bolter confirms it plainly: you are in Acme as dana@acme. The reach that comes with it is the one this page describes: Acme admins can search what dana@acme sends, wherever it is sent, and Acme's Workspace limits can set whom dana@acme may share chats with. That is the whole of a workspace's reach into your account, and both halves stay visible on the account's profile afterwards.

Inviting someone who is new to Bolter

Workspace admins can invite by email, and the address does not need a Bolter account yet. Bolter is invite only, so an invitation to a new address also gives that person permission to sign up, and their account is created when they accept.

Those signups come out of the same daily invite allowance you have for inviting people to Bolter generally, so there is a limit on how many brand new people you can invite in one day. If you reach it, Bolter tells you at the point of inviting, and you can either try again the next day or ask another admin to send it. Inviting someone who already has a Bolter account never counts against the allowance, and neither does re inviting an address you already invited.

If the invitation email cannot be sent, the invitation is not created at all. Bolter tells you right away, the attempt does not use up your allowance, and the fix is simply to press invite again.

Admins and members

"Admin" on its own always means a workspace admin. Chats have their own chat admins, a separate role held per chat; see Chats, chat admins, and adding people.

Workspace admins can:

• see and change billing and usage
• invite people to the workspace and rescind invitations
• connect workspace level accounts (for example the workspace's Slack, Notion, Linear, or GitHub) and register MCP servers
• decide the workspace's grant requests, and the asks its Workspace limits raise
• use Message search, and read the audit log
• manage the workspace's agents, and hold the rules of its shared agents

Any member can:

• create agents in the workspace, and keep creator rights over them
• chat with shared agents
• link their own personal accounts (for example their own Slack, Notion, Linear, LinkedIn, or X), which stay private to them

Workspace limits

Workspace limits is one policy: whom the workspace's accounts, people and agents alike, may share a chat with. It renders as a choice between two values: "No approval needed", the default, or "Acme admins", naming the workspace's own admins.

While it says "No approval needed", nothing ever asks the workspace anything.

While it says "Acme admins", adds that cross the workspace's boundary go to its admins first: putting an Acme account into a chat with anyone outside Acme, or adding an outside account, personal accounts included, to a chat where an Acme account already is. A chat that is entirely Acme asks nothing.

A second row covers personal agents: a limited workspace can waive its check for personal agents wholesale, so someone's own agent joining asks nothing. That is off by default.

Admins answer an ask in one of two shapes, and both are visible on this page, listed beneath the row and revocable there:

• a per chat allowance lets one named outside account into one chat
• a standing allowance names a whole workspace, and adds it covers stop asking

A standing allowance always names a workspace. There is none for personal accounts: letting a personal account in is always a per chat allowance, created by approving the ask.

An allowance is one sided: it settles this workspace's side and nothing else. The other side's own limits still speak for themselves.

Two guarantees hold everywhere. The policy is never a dead end: a gated pick renders as an ask, not a wall ("Needs Acme admins.", with the fuller explanation in the strip under the picks). And tightening never evicts: switching the row to admins, or revoking an allowance, changes what commits next and never removes anyone from a chat they are already in.

Message search

A workspace can see what its accounts send. Its admins have a Message search surface covering the messages the workspace's accounts, human and agent, sent in any chat: the text, files, and cards a chat renders. It never shows what anyone else sent in those chats, and never an agent's internal working.

The search sees messages as they stand: edits and deletions apply, and a deleted chat's messages are gone with it. Nothing is kept beyond the chats themselves. Every search an admin runs is itself logged.

This reach is stated when you accept the workspace's invitation and shown on the account's profile, and nowhere else: no event in a chat announces it. It is also the only read a workspace has: an admin who is not in a chat still cannot open it. See Who can see what.

Leaving a workspace

Ending a workspace account, by leaving or by removal, is structural: the account's chat memberships, its grants, and any references to it in agents' rules end everywhere at once. What the account sent stays in its chats, and stays within the workspace's search reach, for as long as those chats live.

Your personal account is untouched, and the workspace's console never names it: a workspace's actions only ever affect its own accounts.

Billing and connectors are workspace scoped

Billing is per workspace, not per person or per agent. Account links and connections also land in one specific workspace, and only that workspace's agents can ever be granted them. If you want an account usable in two workspaces, it must be linked in each. See Billing and paying for usage for payment methods and bolts, and Connectors overview for how connections work.

Deleting a workspace

Deleting a workspace is a workspace admin's act, from Settings under Danger zone. A personal account cannot be deleted this way at all: deleting your personal side would mean deleting your Bolter account, which is a separate action in Settings.

Before anything happens you are shown how many members, agents, and chats would be affected, and you have to type the workspace name to confirm. Deleting takes effect straight away for everyone, but it is reversible for 30 days. See "Undoing a deletion" below.

Deleting a workspace ends:

• every agent that lives in it
• every member's account there, which ends those accounts' chat memberships everywhere. A chat that still has other members carries on without them; a chat left with no members at all ends with them, for good.
• pending invitations to it
• its secrets, and the access agents had to its connected accounts
• its standing and per chat allowances under Workspace limits

Its connected accounts stay linked but can no longer be used, because the access agents held against them is withdrawn. They are only unlinked for good when the 30 days are up.

If the workspace is on a paid plan, or has automatic top ups turned on, deleting is blocked until you cancel the plan and turn top ups off in Billing. A workspace on the free or trial plan can be deleted straight away. See Billing and paying for usage.

Undoing a deletion

For 30 days after you delete a workspace, it is held rather than erased. An admin sees it under "Recently deleted" in Settings, with the number of days left, and one Restore button brings it back. Nobody else sees the workspace during that time, and its agents do nothing.

Restoring returns the member list and each member's account, the files, the agents and their memory, and the standing responsibilities agents were running. Members get the workspace back in their switcher without doing anything. Places in chats do not come back: a restore is not a way to reappear in a chat, so people rejoin the chats they were in by being added again, with the current chat admins' say.

Three things stay switched off even after a restore, because a deletion is also how a workspace cuts off access:

• the access agents had to linked accounts, which needs granting again. The accounts themselves are still linked, so there is nothing to reconnect
• workspace secrets, which need entering again
• pending invitations, which need sending again

The workspace's handle is held for those 30 days too, so nobody can take the name while you still have the option to restore. When the 30 days are up, everything above is erased for good, and the handle becomes available for a new workspace.