Skip to content
intentdocs/ docs
Docs menu
Using the Web App · 2.7

Workspaces and teams

Personal and team workspaces, what each role can do, guests on a single project, who approves plans and stories, and how agents are bound to a workspace.

Every project lives in a workspace. Your personal workspace holds projects only you can see. A team workspace holds projects your team shares, with roles that decide who can edit, comment or only read. Agents are bound to a workspace too, so a team decides which agents can read its projects.

Switching workspace

The workspace chip in the header says which workspace you're in. Use it to switch. A project opened from another workspace offers to switch rather than switching for you.

Create workspace sets up a team workspace: name it, choose the seats, and pay. Nothing is created until payment goes through.

Roles

In a team workspace, each member has one role:

RoleCan
OwnerEverything, including billing. A workspace always keeps at least one owner.
EditorEdit stories and specs.
CommenterView and comment.
ViewerRead only.

Admins manage the workspace: its members, settings and agents. Owners, editors and commenters take a paid seat; viewers don't.

Workspace settings has About, Members, Projects, Plans, Branding, Agents and Billing. Which ones you see depends on your role.

Guests

You can invite someone to a single project without making them a member of the workspace. On the project's Overview, the people card lists who has access; whoever administers the project can invite by email as an Editor, Commenter or Viewer.

A guest sees only that project. Their header says whose project it is, what their role lets them do, and who to ask for more access.

Open and restricted projects

A workspace project is Open to the workspace by default: every member can read it. Restrict this project limits it to the people listed on it. A restricted project names a custodian, a workspace member who looks after it. Owners and editors can restrict a project.

Who approves

Approving is narrower than editing, because approval is what lets an agent build and what accepts its work. The same people approve both plans and built stories:

  • On a personal project, you.
  • In a team workspace, its owners and admins always. An admin can also make any editor an approver, under Workspace settings → Plans → Who can approve plans. Commenters, viewers and guests can't be approvers.

Everyone who can edit can comment on a plan. Approvers send it back or approve it, approve built stories on Review, and close and reopen releases.

Workspace settings → Plans also holds Before agents build for every project in the workspace at once, or one project at a time. See Working with agents.

Agents in a workspace

Every agent token is bound to one workspace for its whole life: your personal workspace or a team one. Switching workspace in the browser doesn't move it. The agent tells you which workspace it's reading in its first answer.

A team workspace can ask admins to approve new agents, and does unless an admin switches it off. Until an agent is approved it reads its holder's personal projects only. An admin's own agents are approved straight away.

Workspace settings → Agents lists every agent bound to the workspace: who holds it, the tool it reports itself as, and when it was last used. Admins approve waiting agents there and revoke any of them. Decisions stay on the list, so you can see who let an agent in or turned it away.

Access is checked on every call. If someone leaves the workspace, their agents stop working on their next request. If someone loses edit rights, so do their agents.

Moving a project into a workspace

A personal project can move into a team workspace from Project settings → Ownership. This can't be undone: a workspace project can't be moved back out.