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 workspace switcher keeps the active organization visible and lists only that organization's workspaces. Use Switch organization once when you need another organization's workspace; the organization list does not repeat workspace actions. In Settings, the organization and workspace selectors show the same hierarchy without expanding every workspace into the navigation. Organization-scoped pages appear before workspace-scoped pages.

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.

Organization Owners and Admins create and govern workspaces from Settings → Organization · organization name → Workspaces. Select a different organization from that section heading before opening Workspaces when needed. Select a workspace under Workspace · workspace name for workspace-specific settings such as models, network access, API keys, and credentials.

Billing, usage, and audit administration are organization-scoped today. They require an organization Owner or Admin. The shared catalog marks a billing-only workspace role as future, so it is not shown above as current access.

The organization Usage view combines model spend, model activity, successful skill loads, per-member trends and totals, per-agent trends and totals, and a sortable, filterable activity ledger. User stats can be filtered to one member and intentionally exclude unattributed internal work. Agent stats include the agent's eternal session and all of its nested sub-agent runs, can be filtered to one agent, and intentionally exclude non-agent work. These views answer different questions—who initiated the spend and which agent executed it—so the same run can appear in both. Team totals remain the complete organization view. Skill usage records a successful skill load, not a skill listing or failed load.

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.

• A workspace model policy determines which models people may select.
• Installed skills become candidates that a project can pin and activate.
• Connector credentials live in the workspace vault; projects activate only the credentials they need.
• When a provider offers multiple connection methods, each method creates its own credential so administrators can choose the appropriate authorization and action boundary.
• Workspace API keys authenticate server and CLI integrations within that workspace.

Availability is not activation. Adding a connector or skill to the workspace does not silently expand the capabilities of existing projects or agents.