Workspaces and organizations
There are two containers, and they do different jobs. The organization holds the money. The workspace holds the work. Knowing which one a thing belongs to answers most questions about who can see it, who can change it, and who pays for it.
The organization owns billing, the workspace owns the work
An organization carries the Stripe customer, the subscription, the plan tier, and both credit wallets. A workspace carries members, agents, API keys, connections, its database, files and every usage row. One organization can hold several workspaces, and all of them draw on the same balance: spending in one workspace is spending for everyone.
the organization owns
- The Stripe customer and payment method
- The plan, and its seats on the managed plans
- The data credit wallet
- The AI credit wallet
- Auto-reload for each wallet
- The trial
- Organization members and their roles
the workspace owns
- Members and their workspace roles
- API keys
- Agents, their sessions and their approvals
- Schedules and webhooks
- Connections and MCP servers
- The workspace database, files and memory
- Usage attribution for every call
two wallets
Signing up creates an organization and a workspace, both named Personal, and makes you the owner of both. A claim link is an offer of a ready-made agent build (a hire) picked for your company. Claiming it creates an organization and a workspace named after the company, makes you the owner of both, and starts building the hire there. Each claim link works for one account, until it expires.
Workspace access is not billing authority
Roles exist twice, and the duplication is deliberate. A workspace role (owner, admin, member) says what you can do inside that workspace. An organization role (owner, admin, member) says whether you can touch the money. They are stored separately, and being in a workspace never promotes you at the organization.
| Action | Needs |
|---|---|
| Use the workspace: build and run agents, create API keys, connections, schedules and webhooks, call the API, read usage and the balance | workspace member |
| Rename the workspace, manage its members, set tool permissions | workspace owner or admin |
| Delete the workspace, unless it is the organization's last one | workspace owner |
| Buy credits, change the plan, add seats, manage organization members | organization owner or admin |
why it is split
A seat is an authorized identity, not a login
Seats are counted across the whole organization: every distinct person who is a member of any of its workspaces occupies one. A person in three workspaces still holds a single seat. Pending invitations that have not expired are counted too, so capacity cannot be oversubscribed while invites are in flight, and an authorized Slack speaker who has no superagnt account of their own occupies a seat as well.
Each managed plan includes a number of seats and, where the plan offers one, bills extras at a fixed monthly price. Extra seats also add their own monthly credit allowance to both wallets. The builder plans have no seat limit: invite as many people as you like.
- 01
Invite
A workspace owner or admin invites an email address, as an admin or a member, from Invite member on the Workspace tab of Settings. The invitation arrives by email with a link to accept it. If occupied seats plus pending invites already fill the billed capacity, the invite is refused withSEAT_LIMIT_REACHEDand an offer to add a seat. - 02
Accept
The invited person opens the link while signed in as that address and accepts, which opens the workspace. Signed out, the link offers to sign in or sign up and then comes back to the invitation, so someone new can join with a fresh account. Joining this way skips onboarding. A different address is refused withINVITATION_EMAIL_MISMATCHrather than a confusing not-found, so they can switch accounts. - 03
Change a role
A workspace owner or admin moves a member between admin and member; only an owner can hand out owner, or change another owner. Organization roles are managed separately, and only by an organization owner or admin. - 04
Remove
Removing a member revokes their access to that workspace and frees their seat once they hold no membership anywhere in the organization. Reducing billed seats never shrinks capacity below the people currently occupying it.
your personal workspace
What each plan allows
Limits are organization-wide and counted across every workspace. When creating something would cross one, the request fails with HTTP 402 PLAN_LIMIT_REACHED, naming the resource and what is in use against the limit, with an upgrade offer naming the next plan. Through MCP the same refusal arrives as a requires_upgrade tool result. Nothing is created, and nothing is charged.
Builder plans
| Plan | Price / mo | Workspaces | Agents | Webhook events / mo | rpm |
|---|---|---|---|---|---|
| Starter | $49 | 1 | 3 | 25,000 | 60 |
| Growth | $149 | 3 | 15 | 150,000 | 300 |
| Scale | $399 | 10 | 50 | 750,000 | 600 |
Managed plans
| Plan | Price / mo | Seats | Workspaces | Agents | Databases | Webhook events / mo |
|---|---|---|---|---|---|---|
| Solo | $99 | 1 · no add-on | 1 | 5 | 1 | 5,000 |
| Team | $199 | 3 · +$49/seat | 1 | 15 | 3 | 25,000 |
| Business | $499 | 5 · +$99/person | 1 + 1 per seat | 50 | 10 | 100,000 |
- Every plan gets every capability. The builder plans also cap schedules, queues, pipelines, knowledge, the workspace database, inboxes and messaging lines; each capability page has its own table, and the plans and limits page has them all.
- The no-card trial runs on Growth limits.
- The builder plans rate-limit the whole organization at once, REST and MCP together. The managed plans rate-limit REST calls per workspace.
- Business is the plan that scales workspaces with people: one shared workspace plus one more per seat, so everyone can have their own.
- Agency and Enterprise are sales-led and priced per account, so they are not in these tables.
- Everything here is monthly. There is no annual billing.
See plans and limits for every limit and what each plan includes.
What never crosses a workspace boundary
API keys, agents and their sessions, connections, the workspace database, files and memory all belong to exactly one workspace. A key minted in one workspace cannot read another's data, and a record from a workspace you are not a member of reads as missing rather than forbidden. The only thing shared across workspaces in an organization is the balance.
In the dashboard the workspace is in the path: app.superagnt.com/dashboard/<workspaceId>/<section>. That segment is the source of truth for which workspace you are acting in: switching workspaces changes the URL, and a link you paste to a teammate lands them in the same one you were looking at.
Switch from the workspace menu at the right end of the top bar, which shows the current workspace's name. It lists every workspace you belong to, grouped by organization, with a check beside the current one. A switch keeps you in the same section; a page for one item, such as a chat session, falls back to the top of its section, because the item belongs to the workspace you left. Organization owners and admins also get New workspace there, within the plan's workspace limit.
one key, one workspace
Related: tools and tool families for what a workspace serves to an agent, and errors and rate limits for the codes named above.