Workspaces

A workspace is a logical container inside an org. Every org has at least one (the default, auto-created), and you can add more to separate projects, clients, or environments.

What a workspace contains

• Agents (Assistants and Agents)
• Conversations (workspace-scoped chat threads)
• Pages (the page tree is per-workspace)
• Data tables (user-defined tables and rows)
• Canvases (the saved layouts for each workspace mode)

Provider keys, integrations, and members are org-level, not workspace-level — they apply to every workspace in the org.

Default workspace

When an org is created, a handle_new_org_workspace Postgres trigger inserts a workspace with:

• name: "Default"
• slug: "default"
• icon_name: a default Lucide icon

You land in this workspace the first time you enter an org.

Creating workspaces

From the workspace switcher (next to the org switcher in the breadcrumb) → + New workspace. You can set:

• Name and slug
• Icon (Lucide picker)
• Visibility (planned — see Status)

Auto-save persists your edits to Supabase as you type.

Switching workspaces

Current workspace is persisted to localStorage and reflected in the URL:

/:orgSlug/:wsSlug/home

Switching navigates and reloads the workspace's agents, conversations, pages, and data.

Why use multiple workspaces

• Clients / projects. One workspace per client keeps their conversation history, agents, and data isolated from the rest of the org.
• Environments. Many users run a prod and a staging workspace, or use separate workspaces for development experiments.
• Personas. A "Research" workspace with research agents, a "Sales" workspace with outreach agents.

Limits

There's no hard cap on workspaces per org today. Each workspace is cheap — it's a single row in the workspaces table and a foreign key on the resources above.