Administer d5s

Administer d5s by separating who may enter the workspace, what context they may access, and what actions their agents may perform. A controlled rollout can begin with one project and one connector rather than configuring the entire organization at once.

1. Establish membership and ownership

Confirm the organization owner and workspace owner before inviting a broader group. Organization ownership carries billing and destructive powers that ordinary workspace administration does not.

An organization Owner or Admin can open Settings, choose the organization in Organization · organization name, and select Workspaces to create or govern its workspaces. The workspace switcher is reserved for changing context: it shows one organization at a time and provides a single Switch organization action when you belong to more than one.

The workspace creator becomes its sole Owner. Add users or groups explicitly from organization settings; organization membership alone does not grant access to workspace content. The new workspace starts with its own projects, model policy, skills, connector credentials, and API keys; secrets and project content are not copied from an existing workspace.

Assign the narrowest current workspace role that lets each person do their job:

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.

Use project sharing for access to a particular body of work instead of elevating the person's workspace role.

2. Choose a pilot project

Create one listed project with a clear owner, representative files, and a small group of participants. Decide whether it is available to everyone in the workspace or restricted through explicit people and group grants.

Keep project instructions short and operational: identify the purpose, approved evidence, review expectations, and actions that always require a person.

3. Connect capabilities deliberately

Open Connectors and add only the credentials needed for the pilot. Prefer an external account with the narrowest useful provider permissions. A connected credential remains a workspace resource until it is explicitly activated on a project or agent.

After activation, review the controls shown for that credential. MCP tools normally allow reads while writes and unknown actions ask. API operation controls are not available for every connector, so do not rely on an approval boundary unless the credential displays and enforces it.

4. Prove one workflow

Ask a member to complete the workflow interactively and review its sources, tool activity, approvals, generated files, and usage. Only then turn the pattern into an agent or automation.

For autonomous work, start with a budget or conservative schedule and a clear destination. Keep a named person responsible for reviewing failures and external actions.

5. Review the boundary regularly

Remove unused project grants, archive credentials that should no longer be activated, and investigate repeated approval or authorization failures. Use run history to distinguish an agent execution problem from a connector or external-account permission problem.

Organization Owners and Admins can open Settings, confirm the organization shown in Organization · organization name, and select Usage to review model spend, model usage over time, successful skill loads over time, per-member usage, per-agent usage, and the activity ledger. The charts share the selected date range. User stats shows member-attributed spend, tokens, and runs over time; use the member picker to filter both the chart and totals table. User avatars follow the member's current profile. Unattributed internal work remains included in Team totals and the Activity log but is excluded from User stats.

Agent stats shows only agent-attributed spend, tokens, and runs over time; use the agent picker to filter both the chart and totals table. Agent usage includes nested sub-agent runs and uses the agent's current name and avatar. Once attribution has been recorded, deleted agents remain as separate historical rows with a generated fallback identity. Ordinary chat, other non-agent work, and legacy rows without agent attribution remain included in Team totals but are excluded from Agent stats. User stats and Agent stats are complementary attribution views: one run can be counted under the member who initiated it and the agent that executed it. Use an activity table column menu to sort the complete date-range result or search and filter values in that column. The Member column includes unattributed internal usage when it exists.

Under Workspace · workspace name, select Models. The catalog is grouped into one card per provider, each showing how many of that provider's models are enabled. The most widely used providers are listed first and the rest follow alphabetically. A provider with more than six models shows the first six and a Show all control that expands the card in place. The All / Enabled / Disabled filter above the grid carries the same counts for the whole catalog; filtering to Enabled hides providers that have nothing turned on. A provider card's own count and its bulk control always describe the whole provider, not the filtered rows.

Use Enable all or Disable all in a provider card's header to turn that whole provider on or off in one step; the control is omitted for a provider with a single model. Set the workspace default from the control in the page header, which lists only enabled models. The default model and the last remaining enabled model cannot be turned off, because either would leave the workspace with no model to run. Disable all always spares the workspace default for the same reason, so a provider holding the default keeps that one model enabled.

Continue with Sharing and permissions, Connect and activate a connector, and Security and trust.