Workspaces: keeping work separate

A workspace is a complete, self-contained tenancy: its own API keys, pools, workflows, runs, Library, members, settings and spend ceiling. Nothing crosses between them.

Switching

If you belong to more than one, your account menu (bottom of the sidebar) grows a picker with a tick beside the current one. Switching changes everything you see. If you only belong to one, no picker appears.

What is genuinely isolated

• Keys and pools. A flow in one workspace cannot spend another workspace's keys, in the app or in the engine. This is enforced at the point a step acquires a key, not just in the interface.
• Flows, runs, Library and usage. Separate lists, separate history.
• Members and roles. You can be an admin in one and a viewer in another; each membership is independent.
• Spend ceilings. See the warning below.

The one thing to watch: ceilings do not add up

Each workspace has its own daily spend limit and neither knows about the other. Two workspaces at "$50/day" is $100/day against one real provider bill. Set each with the total in mind.

If the same underlying provider account serves both, also give the copied keys the same Shared account name in each workspace (API keys), so both draw on one rate bucket rather than each assuming full capacity.

Getting a second workspace

Provisioning one is an owner-level operation rather than a self-service button — ask whoever administers your FlowArray. When a workspace is created from an existing one, keys are copied as ciphertext, pools and their memberships are rebuilt, and flows come across with their pool references remapped.

Deliberately not copied: schedules, triggers, the spend ceiling, authorised MCP connections and run history — all of which should be set up consciously in the new workspace rather than inherited by surprise.

Related

• Inviting your team — an invite is per workspace.
• Roles — your role can differ per workspace.