Multi-workspace

Switching workspaces, organizations, and the personal-workspace lifecycle.

agntdata accounts can belong to multiple workspaces, and most teams end up with at least two (one personal sandbox, one shared team workspace). This page covers how the switcher works, what’s scoped to a workspace vs. shared at the organization level, and how the “personal workspace” lifecycle handles invites.

The model

Organization
├── Billing (subscription, credits, auto-reload)
├── Workspace A
│   ├── Members
│   ├── API keys
│   ├── Deployed agents
│   ├── Connections + integrations
│   └── Workspace database
├── Workspace B
│   ├── …
└── …

• Organization owns billing, the credit wallets, the active feature plan, and the trial. Credits are shared by every workspace in the organization.
• Workspace owns the things you actually build with: API keys, deployed agents, schedules, webhooks, connections, the workspace database, and audit logs.
• Member is a row in workspace_members per workspace; the same user can be a member of many workspaces.

Your plan controls how many workspaces an organization can hold:

Plan	Workspace limit
Build	1
Launch	3
Scale	Unlimited

Switching workspaces

The workspace switcher lives in the dashboard header — click the workspace name (top-left, next to the logo). The dropdown lists every workspace you’re a member of across every organization, with the active one marked.

Switching reloads the dashboard with the new workspace context:

• API keys, agents, connections, and the database tab show the new workspace’s data.
• The credit balance + billing tabs show the organization’s numbers (shared across this workspace and its siblings).
• The URL stays the same — workspace context is held in client state, not the URL.

API requests are scoped automatically by the API key you use — each key belongs to exactly one workspace, so you don’t pass a workspace id on the request.

Personal workspaces

When you sign up, agntdata’s handle_new_user trigger creates a Personal workspace and makes you its owner. It’s a real workspace — you can build agents in it, install connections, and burn through your signup bonus credits there.

If you later accept an invite to a team workspace, agntdata cleans up the personal workspace if it has no meaningful state (no API keys you’ve used, no deployed agents, no custom connections). Empty personal workspaces are deleted on invite acceptance so the switcher doesn’t accumulate dead “Personal” entries every time you join a new team. If the personal workspace has any state, it’s left alone.

You can always delete a personal workspace later from Settings → Workspace.

Inviting members

From Settings → Members, invite a teammate by email. The invitation lands in workspace_invitations and the recipient gets a one-time accept link.

• Existing agntdata accounts — the link adds them to the workspace immediately and they land in /dashboard with the new workspace selected.
• New accounts — the link sends them through signup with the invitation already attached. They skip the experience-level question and onboarding form, since the team has already onboarded.

Every member of a workspace can:

• View and create API keys, agents, schedules, webhooks, connections, and database rows.
• See the organization’s credit balance and usage history.

Member-level role distinctions (admin / member) are read from workspace_members.role and enforced where the API matters (e.g. only owners can delete the workspace).

Workspace claim tokens

Some flows — the DFY (done-for-you) setup, internal demos, partner installs — provision a workspace before the end user has signed up. The provisioning code creates the workspace with a one-time claim token instead of an owner.

When the recipient signs up and visits the claim URL, agntdata attaches the workspace to their organization, fires a post-claim greet so the Builder can re-introduce the agents already in there, and pops a welcome modal with what’s been pre-built.

You don’t normally interact with claim tokens directly; they’re plumbing under the invite + DFY surfaces.

Next steps

Workspaces

The basics — what a workspace owns, how credits are shared.

API keys

How keys are scoped to a single workspace.

Credits

Org-level data and AI wallets.

Trial

The trial is org-scoped and works across all workspaces.