Workspaces

A workspace is the closed perimeter one team works in. Everything else in Bounc lives inside one: issues and projects, members, agents, workflows, Assets tables, and credentials.

The isolation is not a setting but the shape of the platform: every record belongs to exactly one workspace, and access follows your membership in it. One workspace's data is invisible from another — to a person and to an agent alike. Which is why switching workspaces replaces everything you see: the issue list, the roster, the agents, the tables.

What a workspace owns

• The work — issues with their statuses, priorities, labels, and threads; the projects and initiatives above them.
• The people — members, their roles, and invitations.
• The agents — the agents themselves, their instructions, skills, and teams.
• The automation — autopilots, workflows, and the Assetflows on tables.
• Assets — the workspace's own tables: registers, reference lists, pipelines.
• Files — attachments on issues and comments.
• The access — credentials, connected integrations, and the machine the agents run on.

One workspace or several

One, by default: the more people and agents share a perimeter, the less work is lost at the seams. A second workspace is for isolation that is real:

• Separate legal entities or data perimeters — when access to one unit's data should not come down to trust.
• Working with outsiders — contractors and partners see their workspace and nothing else.
• A pilot next to live work — try out a process and its agents without mixing them into the current board.

One person can belong to any number of workspaces on a single account. Switching happens in the interface; in each workspace they have their own role, their own assigned work, and their own set of available agents.

Creating a workspace

• Name — what members see. Changeable at any time.
• Workspace code — the short lowercase abbreviation the address is built from: …/acme/issues. The creation form calls the field URL, the settings page calls it Slug. It cannot be changed after creation, so take a short, recognizable abbreviation of the name; if it is taken or reserved, the form asks for another.
• Issue prefix — the two or three letters every issue id starts with (ACME-1). It seeds the default team's identifier, and can be changed later in that team's settings.

Issue numbers

An issue id is a team identifier plus a number: ACME-1, ACME-2. The rules worth knowing up front:

• Each team has its own counter. A new team starts at one, and numbers within a team are sequential and unique.
• The system assigns the number. You write a title; the number appears on its own.
• Deleted numbers are never reused. Delete ACME-5 and the next issue is still ACME-6.
• Moving an issue to another team renumbers it, but the old id keeps working: links and CLI commands resolve by any id the issue has ever carried.

An admin can change a team's identifier on the team's page. Existing issues start showing the new identifier, and old links keep opening.

Workspace settings

Admins and owners can change them; members see them read-only.

• General — the logo, name, description, and context (background on what this workspace is for). The slug is shown but not editable.
• Features — sections not every team needs. Today that is Initiatives: turning it off only hides the section and deletes nothing, so it can be turned back on at any time.
• Members, Labels, Runtimes, Credentials — the roster, the reference lists, and the access, each on its own page. Connectors live in Agents → Connectors.

Leaving and deleting a workspace

• Any member can leave a workspace — access is gone until they are invited again.
• A sole owner cannot leave: somebody else has to be promoted to owner first. Every workspace has at least one owner at all times.
• Only an owner can delete a workspace. It is permanent: the issues, projects, agents, and data go with it.
• Deleting closes the workspace at once. Nobody can open it any more and its agents stop; its threads, files, sandboxes and data are then deleted in the background, and a screen shows how far the deletion has gone. The organization's journal keeps a record of who deleted it and when.

Next

• Members and roles — who to invite, and with which role.
• Issues — the core unit of work inside a workspace.
• Projects and initiatives — grouping work above the issue level.