How to Design CloudThinker Workspaces for Your Organization
This guide explains what a CloudThinker workspace is and how to plan, create and govern several of them across teams and environments. It's written for the people who set CloudThinker up for a company: platform leads, security owners and organization Admins.
Each step covers the decision to make and the recommended value, then links to the CloudThinker documentation for the exact setup steps. Product details are current as of November 2026.
01Plan
Boundaries and layout
Decide what must be separated, then pick a layout and names.
02Create
Workspaces
Create each workspace with a clear name and owner.
03Connect
Systems and people
Add connections, credentials and members with the least access that works.
04Govern
Budgets and review
Cap spend, route channels, lock guardrails and review usage monthly.
What is a CloudThinker workspace?
A workspace is an isolated area inside your CloudThinker organization. It has its own connections, credentials, agents, skills, knowledge, memory, approvals, conversations and members. Agents and members in one workspace can't use another workspace's connections, data or conversations.
The organization sits above every workspace. It owns the plan and billing, the member list, single sign-on, your own model keys (BYOK) and the audit log. Signing up creates one organization with one workspace.
Governance at scale.
- Agents
- Sandboxed, and scoped to their own workspace.
- Workspaces
- An isolated sandbox per team and environment.
- Organization
- SSO, SCIM, roles and audit logs, set once.
Approval mode
Per workspace, run type and chat.
Certified
Deploy
* Early access.
| Managed in the organization | Managed in each workspace |
|---|---|
| Plan, billing and the shared credit pool | Connections and credentials |
| Members and organization roles: Owner, Admin, Developer, Viewer | Custom agents, skills, knowledge and memory |
| SSO and SCIM provisioning | Approvals, through Auto Mode |
| The organization's BYOK key | Which key the workspace runs on: the organization's, its own, or none |
| Audit logs and usage across all workspaces | Conversations, artifacts, Automations, and Resolve, Review, Cyber and Optimize data |
| Credit limits, one cap per workspace | Workspace members and roles, notifications and branding |
Two rules shape every design decision in this guide:
- Nothing crosses between workspaces unless you set it up. A connection, runbook or memory item in one workspace isn't available in another.
- Organization Owners and Admins are Admins in every workspace. This can't be lowered per workspace. Workspaces restrict access for Developers and Viewers only.
Before you start
| Requirement | Details |
|---|---|
| Role | Organization Owner or Admin to create workspaces, assign access and set credit limits. The Owner configures SSO, SCIM and BYOK. |
| Plan | Team includes 3 workspaces, Scale 10 and Enterprise unlimited. Credit limits, SSO and SCIM, audit logs, BYOK and workspace branding require Scale or Enterprise. |
| Inventory | A list of the systems agents will use (cloud accounts, clusters, repositories, observability and alerting tools), the teams that own them, and your on-call rotation. |
Step 1: Decide which boundaries you need
A workspace sets four boundaries at once. Before you choose a layout, decide which of them must differ between parts of your organization.
01Reach
Connections and credentials
Every workspace credential reaches every command an agent runs there.
02Rules
Approvals
Configured per workspace, so production is only as strict as its workspace.
03Budget
Credit limits
One monthly cap per workspace, drawn from the shared pool.
04Memory
What agents learn
Stays in the workspace, so a new workspace starts with less context.
Use this table to decide whether a requirement needs a separate workspace or can be met inside one:
| Requirement | Recommended approach | Reason |
|---|---|---|
| Stricter approvals for production | Separate workspace | Approvals are configured per workspace |
| Keep a secret away from some work | Separate workspace | Every workspace credential is passed to every command in that workspace |
| A separate budget for a team | Separate workspace | Credit limits apply per workspace |
| Keep a client's or business unit's data apart | Separate workspace | Conversations and findings don't cross workspaces |
| Keep a team's conversations from other teams | Separate workspace | Memory and conversation search cover every member, and a conversation can't be made private |
| Limit which systems some people can see | Separate workspace | Developers and Viewers only see workspaces they're added to |
| Organize many cloud accounts | Same workspace | Add one connection per account and set its Environment label |
| An agent that only touches certain systems | Same workspace | Create a custom agent and attach only those connections |
| A personal space for each engineer | Same workspace | Memory, skills and knowledge would fragment; personal preferences are already kept per member |
Start with one workspace, and add another only when a requirement in the first six rows applies.
Step 2: Choose a layout and naming convention
Three layouts cover most organizations. You can combine them.
| Layout | Split by | Use it when | Consider |
|---|---|---|---|
| Environment | Production, non-production | Production needs stricter approvals, fewer people with write access, or its own budget | Shared skills and runbooks must be added to both |
| Team | Platform, Security, application teams | Teams connect different tools and follow different procedures | A system two teams investigate needs a connection in each workspace |
| Customer or business unit | One workspace per client or unit | You operate systems for several clients, or units whose data must stay separate | Your plan's workspace limit, and keeping settings consistent across workspaces |
The reference design below combines the environment and team layouts for an organization with a platform team and a security team. Its 3 workspaces fit every paid plan, and the credit limits in it need Scale or Enterprise.
| Setting | platform-prod | shared-nonprod | security |
|---|---|---|---|
| Purpose | Production systems the platform team runs | Staging, development and sandboxes | Security monitoring and investigations |
| Connections | Production accounts and clusters, read-only to start | Staging, development and sandbox accounts | Wazuh, GitGuardian, cloud accounts read-only |
| Approvals | The strictest setting | A standard setting | The security team's own setting |
| Credit limit | High cap, Notify only | Sized from usage, Throttle | Its own cap |
| Members | Platform team as Developer, on-call engineers as workspace Admin | All engineers as Developer | Security team only |
Names and limits are examples. Adjust them to your teams and plan. For a rollout where DevOps, Security and product squads each own a workspace, see How to Set Up CloudThinker for DevOps, Security and Product Teams.
Choose a naming convention before you create anything, because the name is what people see in the workspace switcher. A <team>-<environment> pattern, such as platform-prod, payments-prod and shared-nonprod, stays readable as the list grows. Use the workspace Description to record the owning team and the workspace's purpose.
Step 3: Create the workspaces
Create one workspace for each row of your layout, using the names and descriptions from Step 2.
- A new workspace starts empty, and only organization Owners and Admins can see it until you add members.
- To evaluate CloudThinker inside an organization that already does real work, create an
evalworkspace. Deleting it later removes the trial's connections and conversations in one step.
Docs: Create a workspace
Step 4: Add connections, credentials and custom agents
Connections decide what agents can reach, and the credential behind each connection is the upper limit of what they can do.
- Add one connection per account, and set its Environment label right after you connect it. The connect dialog doesn't ask.
- Use a read-only credential for every production connection. Widen access only when there's a specific change you want agents to make.
- Turn off Allow writes on connections that must stay read-only. It starts on for AWS and most other connections.
- Place each credential in the narrowest workspace that needs it. You can't limit a workspace credential to one agent, run type or Automation, so a secret only some work should see belongs in its own workspace.
- Scope agents with custom agents. For work that should only touch certain systems, create a custom agent and attach only those connections.
Docs: Add a connection, Set the environment, Credentials, Custom agents. Where Your Keys Live covers how credentials are stored and injected.
Step 5: Assign members and roles
A member's organization role sets their default access to workspaces.
| Organization role | Workspace access | Can it change per workspace? |
|---|---|---|
| Owner | Admin in every workspace | No |
| Admin | Admin in every workspace | No |
| Developer | Only workspaces they're added to, as Developer | Yes, with a role override |
| Viewer | Only workspaces they're added to, as Viewer | Yes, with a role override |
Recommended assignments:
- Keep organization Admins to a small group. They hold Admin in every workspace, including production.
- Make Developer the default. Developers can chat, run commands, and create custom agents. They can't change connections or approvals, and the Credentials tab is locked for them. They can still create or overwrite a workspace credential through the secure form an agent shows in chat, so keep production membership to people you'd trust with that.
- Grant workspace Admin sparingly on production. A workspace Admin can add, edit and remove connections and credentials, and manage approvals. On-call engineers who work incidents in Resolve need workspace Admin in that workspace, so keep them on a named list and review it when the rotation changes.
- Use role overrides for team leads. A Developer can be Admin of their team's workspace without organization-wide control.
- Map identity provider groups to workspaces (Scale and above) so new hires land in the right workspaces. People who join through SSO sign-in get Viewer by default.
Docs: Workspace members, Roles, Map groups to workspaces
Step 6: Set a credit limit for each workspace
Credits come from one pool for the whole organization. Credit limits (Scale and above) cap each workspace's monthly share.
Check each workspace's spend for the last 30 days on the Usage page first, then set the default limit about 20% above a typical workspace's monthly spend. Override the workspaces that need a different cap:
| Workspace type | Limit | On limit |
|---|---|---|
| Production | High cap or Unlimited | Notify only |
| Non-production | Based on usage | Throttle or Notify only |
| Sandbox and evaluation | Low cap | Throttle |
Once a workspace reaches its limit, Throttle blocks every new paid run there, including an investigation during an incident, so don't use it on production. The limit is checked when a run starts, so a run in progress finishes. Limit alerts go to the Owner only, and only Owners and Admins can open the meters, so share them with workspace leads in the monthly review.
Docs: Credit limits, Usage
Step 7: Route chat channels and notifications
Each chat channel sends requests to exactly one workspace, so a channel mapping is an access decision. Map every channel the bot is in to a workspace, and check the mapping each time the bot joins a new channel.
Two behaviors to plan for in Slack:
- A channel the bot is in but that has no mapping still runs requests, in the Owner's default workspace with that workspace's connections.
- Requests from regular Slack channels run as one account (the workspace's creator, or the Owner), not as the person who asked. Map a channel only to a workspace that everyone in the channel may use.
Microsoft Teams maps each team to one workspace, and requests from people who haven't linked an account run as one account. Google Chat runs each request as the sender.
For alerts, choose each workspace's default notification channel, so production notifications go to a production channel.
Docs: Slack, Microsoft Teams, Google Chat, Notifications
Step 8: Standardize organization-wide guardrails
Some protections should never vary by workspace. The API keys and Cloud credentials Guardrails start at the organization level. Lock them there, so workspace Admins can't turn them off.
The Owner can also require the organization's BYOK key in every workspace, and set the Capabilities switches (Advisor, Blind Spot and Conversation recaps) for every workspace. What Never Reaches the Model explains what Guardrails protects.
Docs: Guardrails, BYOK, Capabilities
Step 9: Carry context into each new workspace
Skills, knowledge, approval policy and memory don't transfer between workspaces on their own. When you create a workspace for systems that agents already know, move the context deliberately:
| Item | How to move it | Docs |
|---|---|---|
| Skills | Reinstall the Skills Hub skills you use. Download each custom skill as a .zip and upload it to the new workspace | Custom skills |
| Knowledge | Upload the relevant runbooks and policies | Knowledge |
| Approvals | Export active Rules as a policy file, then import it. The file holds Rules, approver groups, Approval modes and the two-person setting | Export and import your policy |
| Credentials | Import a .env file with only the keys this workspace needs | Import a .env file |
Memory doesn't copy, and it has no export. Put what agents must know from day one into knowledge, and memory builds up from the new workspace's own work.
Every new workspace needs this setup and its upkeep. Keep the number of workspaces to what your boundaries in Step 1 require.
Operate and review
| Task | When | Docs |
|---|---|---|
| Review spend per workspace | Monthly | Usage |
| Review agent and user actions, and export a CSV | Monthly, since events are kept 90 days, and after incidents | Audit logs |
| Review workspace Admins | When the on-call rotation changes | Workspace members |
| Review chat mappings | When the bot joins a channel | Slack |
| Update your list of Automation owners | When an Automation is created | Ownership |
When a member loses access to a workspace, the Automations they own turn off and stay off until a workspace Admin takes ownership and turns them back on. Ownership can't be moved ahead of time, and the Automations page doesn't show owners, so keep your own list. Then someone can take ownership the same day.
Deleting a workspace removes its connections, conversations and settings for every member, and can't be undone in the app. Docs: Delete a workspace
Reference designs by organization type
| Organization | Workspaces | Plan |
|---|---|---|
| One platform team, one product | prod, nonprod, and eval during a trial | Team (3), or Scale for credit limits and SSO |
| Several teams sharing production | One production workspace per team that owns production systems, security, and shared-nonprod | Scale (up to 10) or Enterprise |
| Managed service provider | One workspace per customer, each with its own chat channel and workspace branding on reports and shared links | Enterprise (unlimited) |
Every workspace, including an eval workspace, counts toward your plan's limit until it's deleted.
Design checklist
- Each workspace exists because of a requirement from Step 1.
- Workspace names follow one convention, and each description names the owning team.
- Every production connection uses a read-only credential.
- Every connection that supports it has its Environment set.
- Each credential sits in the narrowest workspace that needs it.
- Organization Admins and production workspace Admins are named, short lists.
- Production uses Notify only or a high cap; sandboxes use Throttle.
- Every chat channel the bot is in maps to the intended workspace.
- The API keys and Cloud credentials Guardrails are locked at the organization.
- Usage and Audit Logs are reviewed every month.
Limitations
- Most configuration doesn't copy between workspaces. Credentials import from
.env, approval policy from an exported file and custom skills from a.zip. Connections, custom agents, knowledge bases and memory are set up in each workspace. - The Environment label is informational. It tells people and agents which account is production. Approval Rules don't read it, so isolation comes from workspaces and credentials.
- Organization Owners and Admins can access every workspace. Their access can't be restricted per workspace.
- Audit Logs has no workspace filter. Read the Workspace column. The CSV export doesn't include that column, so record the workspace when you share an export.
- Unmapped Slack channels don't refuse requests. They run in the Owner's default workspace.
- Workspace deletion is permanent. The dialog doesn't ask you to type the name, so check the card before you confirm.
Frequently asked questions
Can two workspaces share a connection?
No. Connections belong to one workspace. Add the connection in each workspace that needs it, ideally with a credential scoped to what that workspace does.
Can one person work in several workspaces?
Yes. A Developer or Viewer can be added to several workspaces, with a different role in each through a role override. They switch from the account menu.
Can a workspace Admin open Admin Settings?
No. A workspace Admin manages their workspace in More → Workspace settings. The one Admin Settings page they can open, from a direct link, is Guardrails.
How many custom agents can each workspace have?
Team allows up to 5 per workspace, Scale up to 10 and Enterprise unlimited. Free allows 1.
Where do I start if we already run everything in one workspace?
Use the table in Step 1. Production usually moves first, when it needs stricter approvals or its own credit limit. Follow Steps 3 to 9 for the new workspace, then remove the production connections from the original one.
