Workspaces

Workspaces are the main collaboration boundary inside an organization. They group projects, control who can see them, and determine the default execution context across the app, TUI, and CLI.

If you only need the hierarchy and boundary model, start with the Manage overview. This page is the workspace deep dive.

What a workspace is

A workspace lives inside an organization and provides:

• A boundary for grouping related projects (e.g. by team, engagement, or client)
• Fine-grained access control via user and team permissions
• A unique key (URL slug) within the organization

If the organization answers “who owns this work,” the workspace answers “who should collaborate on this slice of it?”

Each user gets a default workspace that is private to them. Additional workspaces can be created and shared with other members.

Workflow: how workspaces shape execution

Workspaces are not just folders in the App. They drive context resolution across the product.

1. Onboarding or first login gives you a default workspace.
2. The App settings area is where operators create and share additional workspaces.
3. The TUI and CLI resolve the workspace from the saved profile unless you override it.
4. Projects, runtimes, evaluations, and traces then inherit that workspace context.

That is why switching workspaces changes what “current project,” “current runtime,” and “current data” mean downstream.

How workspaces show up across surfaces

Surface	What you use it for
App	create shared work areas, manage access, review workspace details
TUI	/workspace <key>, /workspaces, /projects [workspace], or Ctrl+W to switch context
CLI	--workspace and --project overrides on top of the active profile
API	/org/{org}/ws/... routes for create, update, delete, sharing, and storage access

Permissions

Workspace access is controlled separately from organization roles. Permissions can be granted to individual users or to teams.

Permission	What it allows
Owner	Full access — manage permissions, delete
Contributor	Create and manage projects within workspace
Reader	View projects and traces

User permissions

Individual users can be added to a workspace with a specific permission level. The workspace creator is automatically assigned the owner permission.

Team permissions

Teams (groups of users within the organization) can also be granted workspace access. All members of the team inherit the team’s permission level for that workspace.

Default workspaces

When a user joins an organization, they receive a default workspace that is private to them. Default workspaces:

• Are automatically created and cannot be deleted
• Are not shared with other members unless explicitly configured
• Provide a personal space for individual projects

The exact default workspace key depends on deployment mode, but the public behavior is the same: every user gets a private starting place and the platform treats it as special.

Managing workspaces

• Create and manage: Create, update, and delete workspaces from the organization settings or via the API.
• Plan requirement: In SaaS mode, creating or updating workspaces requires a Pro plan or higher. Enterprise deployments bypass plan checks.
• Sharing: Add users and manage their permissions from the workspace settings.
• Storage credentials: Request temporary storage credentials for programmatic access to workspace data.

Nuances that matter

• Workspace permission is narrower than organization role. Org membership alone does not guarantee access to every workspace.
• TUI workspace switching restarts the runtime because runtime state is workspace-scoped.
• CLI validation will auto-resolve the default workspace when possible, but explicit automation should still set --workspace when reproducibility matters.
• Default workspaces cannot be deleted, even by owners.