Workspaces

A workspace is the day-to-day operating boundary in d5s. It contains projects, chats, agents, automations, dashboards, and the capability catalogs those resources can use.

Every workspace belongs to an organization, and an organization can contain multiple workspaces. The organization is the broader administrative boundary for people, invitations, groups, billing, entitlements, usage, and audit history.

The organization is also the residency boundary. When an organization is created, its region is selected from the cells currently open to new organizations. Its workspaces inherit that region and do not have a separate selector. One account can join or create organizations in multiple regions. Moving an existing organization is a data-migration operation, not a workspace or organization setting.

Workspaces you create for yourself live in a personal organization. During first-login setup, choose an available region and a name for your personal workspace before it is created. Retrying setup reuses the workspace and preserves its existing name. It carries your own name, so the switcher marks it Personal to tell it apart from a team; when it is not the organization you are in, it is listed first in the Switch organization list. Your personal organization has exactly one organization manager: you, its owner. People who collaborate in its workspaces join as plain members — admin invitations and promotions are rejected, and a previously sent admin invitation is accepted as a plain membership. To those members, your personal organization shows up as Shared workspaces in their organization list and workspace switcher — they reach the workspaces you shared, but the owner-derived organization name, its link slug, and your owner identity stay hidden, and the organization's link address does not resolve for them.

A team organization is created, never converted. From a personal organization's Settings → Organization → Billing page, select Set up a team, choose the region first, give the new team a name, and review its seats before checkout. If your team uses seats on joining, it starts with one standard owner seat and adds colleagues after setup. Otherwise, choose the initial standard and premium seat mix. Review any offer and its renewal terms before continuing to payment. A remote choice continues setup in that destination before any draft or Checkout session is created. Your personal organization and its workspaces are untouched, so they keep everything they had, and the people who collaborate in them stay guests there.

An existing team organization without an active Team subscription has a second entry on its own Billing page: Choose seats and start Team. That path chooses the same initial seat mix and checks out the existing organization instead of creating another one. It also works when the owner has no personal organization. Once the subscription activates, d5s opens the team's existing first workspace or creates one when the team has none. If workspace setup does not finish, the Billing page says so and offers Retry rather than sending you nowhere.

Leaving checkout without paying keeps one empty, unsubscribed team. Re-entering team setup resumes that same team — you may rename it — instead of creating a second one, so an abandoned attempt never leaves duplicates behind. Teams cannot be deleted in-app.

The sidebar switcher opens on the organization you are in and lists its workspaces; a single Switch organization row below them opens the list of your other organizations in your current region. Each organization row names the workspace it opens, the one you last used there on this device or else its first, so switching organization is one selection. Other active cells appear underneath in a smaller Other regions section. Available destinations link to their regional app without claiming that your account has an organization there; an unavailable destination says Coming soon and has no link. A region switch asks you to choose an account on the destination's hosted sign-in screen; it does not transfer your current regional session. If a workspace link opens in a regional app where it cannot be found, d5s offers the other active regions while preserving the requested page path. Query parameters and fragments are not carried across regions. That recovery is still neutral: it does not claim that the workspace exists at a destination, and the destination may require sign-in. The workspaces of the organization you are already in are the first rows of the menu, so each of them is a single selection. On a narrow screen Switch organization expands in place when you tap it, because a side panel does not fit there. In Settings, the sidebar contains account and organization administration plus a single Workspace settings entry; the individual workspace sections live in the page body, so multiple workspaces do not expand into repeated sidebar groups.

Organization Owners and Admins can change the organization display name from Settings > Organization > General > Organization details. Renaming changes the label shown throughout d5s without changing the organization slug or existing links. A personal organization still has only one organization manager, so only its owner can rename it.

Before first sign-in, choose the region where you want to use d5s. Signing in to another region does not transfer your current session or credentials.

Where dedicated Microsoft Teams identities are available, an organization Owner or Admin also needs workspace administration access to manage an agent's Teams setup. Organization-level provisioning consent and each agent's channel activation are separate steps. See Teams agent setup.

Membership and policy

Workspace roles describe the maximum set of actions a person can take:

Workspace roles

Role	Main access
Owner	Full workspace control, including members, settings, capabilities, and deletion.
Admin	Manage workspace members, settings, skills, and connectors.
Member	Create and use workspace resources.
Viewer	Read-only workspace access.

Organization membership and workspace access are separate. A new workspace starts with its creator as the sole Owner; organization Owners or Admins then grant Admin, Member, or Viewer access to individual organization users or groups. Group assignments follow current group membership. Organization admins can govern this portfolio without automatically receiving access to workspace content.

Workspace Owners and Admins, plus organization Owners and Admins, can invite someone directly to a non-personal workspace. Accepting grants the selected Member or Admin role in that exact workspace. A new collaborator joins the organization as a plain member, while an existing organization role is preserved. Invitations are independent per workspace, so the same address can have pending invitations to multiple workspaces in one organization. The personal workspace cannot be shared by invitation; Invite people there creates a new workspace in your personal organization and opens its invitation form, so you invite people to that workspace instead.

Organization Owners and Admins create workspaces from two places. The workspace switcher at the top of the sidebar lists the current organization's workspaces; select the Create workspace plus button in its header, and the new workspace is created in the organization you are in. An organization that has no workspace yet offers Create first workspace in the Switch organization list instead. The same action, with the full portfolio and access controls beside it, lives at Settings → Organization · organization name → Workspaces. The switcher shows these create controls only for organizations where you hold the Owner or Admin role. Access is governed either from that Workspaces section or from a single workspace's own Members section. Select a different organization from that section heading before opening Workspaces when needed. For workspace-specific settings, open Workspace settings in the sidebar — on a narrow screen, from the Settings index — then choose a section such as Members, Models, Network, or API Keys from the row across the top of the page, or from the section dropdown on a narrow screen. Search settings at the top of the sidebar reaches those same sections directly: a matching section is listed by name under the workspace group and opens on selection.

Workspace Owners and Admins can change the workspace display name from Workspace settings → General → Workspace details. The slug is a separate, permanent identifier used in workspace URLs, so renaming leaves the slug and existing links unchanged. Portfolio-level organization administration does not provide a second rename control or bypass the need for workspace access.

Deleting a non-personal workspace is deliberately slower. An explicit workspace Owner or Admin can open Workspace settings → General → Danger zone and inspect the readiness check, which lists every remaining project, agent, conversation, automation, dashboard, custom skill, active API key, active integration, trusted network host, or pending provider revocation. Cleanup happens in each resource's normal product area. Only the workspace Owner can request the short-lived email code, enter the exact case-sensitive workspace name, and schedule deletion once every count is zero. The workspace remains available for 48 hours; its Owner or any explicit workspace Admin can cancel. d5s checks readiness again immediately before deletion and cancels automatically if a dependency returned. Personal workspaces cannot be deleted.

After the final check, the workspace becomes unavailable. The completion email arrives after deletion finishes. If the workspace has disappeared but the email remains absent, contact support.

Billing, usage, and audit administration are organization-scoped today. They require an organization Owner or Admin. Paid subscription seat quantities are reported from Stripe; see Plans and credits. For teams that purchase seats upfront, an invitation to the organization or one of its workspaces claims capacity and is refused when active members plus pending invitations fill the seat quantity. If your team uses seats on joining, an organization Owner or Admin reviews and authorizes any additional seat before sending. Pending authorized invitations carry no charge; acceptance adds needed capacity after successful payment or the displayed waiver. An existing active team member needs no extra seat. A personal organization's shared-workspace guests never become billable seats.

The organization Usage view combines model spend, model activity, successful skill loads, per-member trends and totals, per-agent trends and totals, per-workspace trends and totals, and a sortable, filterable activity ledger. An available activity row can open its run evidence only when the administrator also has access to the source conversation. User stats can be filtered to one member and exclude usage without member attribution. Agent stats include the agent's eternal session and all of its nested sub-agent runs, can be filtered to one agent, and exclude non-agent work. Workspace stats group usage by the workspace recorded on the ledger and can be filtered to one workspace; current workspaces show their current metadata, while entries without current metadata keep separate historical rows. These views answer different questions: who initiated the spend, which agent executed it, and where it ran. The same run can appear in all three. Team totals remain the complete organization view. Skill usage records a successful skill load, not a skill listing or failed load.

Credits and spend controls

Credits are enforced at the organization boundary before model work is dispatched. Paid plans use short and weekly pace windows against charged usage, while the Community plan uses its daily grant without additional pace windows. Plan allowances, grant cadence, and per-run ceilings come from the shared billing catalog.

An organization Owner can assign or clear a non-negative spend limit for any member. An organization Admin can do the same for ordinary members, but cannot change their own limit or another manager's limit. The limit measures that member's charged usage during the organization's current credit period and blocks new work they initiate after the limit is reached. It does not change their workspace or project permissions.

Projects can then inherit access from the workspace or be restricted to explicit user and group grants. Workspace administration and project sharing are therefore related, but not interchangeable.

Shared catalogs

Models, skills, connector credentials, and API keys are managed separately in each workspace. Adding a workspace does not copy another workspace's credentials, secrets, projects, or conversations.

New Free workspaces start with GPT-5.6 Luna as their only enabled model and default. The rest of the catalog stays visible on the Models page but cannot be enabled while the organization is on Free. New paid workspaces initially enable GPT-5.6 Luna, GPT-5.6 Terra, Gemini 3.7 Flash, Grok 4.5, and DeepSeek V4 Pro. Paid EU cloud workspaces with Bedrock access also enable the production Claude models served through Amazon Bedrock in the EU. A downgrade to Free makes only Luna available without deleting the saved paid-plan policy, so upgrading restores the previously enabled catalog automatically.

• A workspace model policy determines which models people may select under the organization's plan and privacy requirements. Newly cataloged models start disabled until an administrator enables them. Models marked as training on prompts require explicit confirmation, cannot be the workspace default, and are unavailable when the organization requires no-training routing. An organization Owner or Admin manages that requirement from Privacy; a personal no-training selection protects that user's work without changing the shared catalog. The Models page lists models by publisher, marks the most expensive models with $$$, and names where each model runs, with an EU flag for models served through Amazon Bedrock or Azure OpenAI in the EU.
• Built-in platform skills are available to every project. Installed workspace skills become candidates that a project can pin and activate.
• Connector credentials live in the workspace vault and attach to projects by default; each project can remove credentials it should not use.
• A Gmail or Microsoft credential bound as an agent mailbox is reserved for that agent's email channel; it is not automatically exposed to the agent as a general project connector.
• When a provider offers multiple connection methods, administrators choose the appropriate authorization and action boundary.
• Workspace API keys authenticate server and CLI integrations within that workspace.

Skills still require project activation. Connectors follow the workspace default instead: adding one expands connector availability to existing and future projects, chats, automations, dashboards, and agents unless a project removes it.