// concepts

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.

01// org vs workspace

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, its seats and any Toolkit modules
  • The data credit wallet
  • The AI credit wallet
  • The one free trial
  • Organization members and their roles

the workspace owns

  • Members and their workspace roles
  • API keys
  • Agents, their sessions and their approvals
  • Connections and MCP servers
  • The workspace database, files and memory
  • Usage attribution for every call

two wallets

The data wallet funds curated data calls — your-credential connections are recorded at zero and never draw on it. The AI wallet funds model tokens and managed agent runtime. They are separate on purpose: an agent burning tokens can never quietly drain the budget you set aside for data.
02// roles

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.

ActionNeeds
Use the workspace: run agents, call the API, read usageworkspace member
Rename the workspace, manage its members, set tool permissionsworkspace owner or admin
Buy credits, change the plan, add seats, manage organization membersorganization owner or admin

why it is split

Accepting an invitation makes you a member of someone else's workspace. If organization authority were inferred from that, every teammate you invited could change the plan. It is not, so they cannot.
03// members and seats

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 plan includes a number of seats and, where the plan offers one, bills extras at a fixed monthly price. Extra seats on the team-shaped plans also add their own monthly credit allowance to both wallets.

  1. 01

    Invite

    A workspace owner or admin invites an email address. If occupied seats plus pending invites already fill the billed capacity, the invite is refused with SEAT_LIMIT_REACHED and an offer to add a seat.
  2. 02

    Accept

    The invited person opens the link while signed in as that address. A different address is refused with INVITATION_EMAIL_MISMATCH rather than a confusing not-found, so they can switch accounts.
  3. 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.
  4. 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.
04// limits per plan

What each plan allows

Limits are organization-wide and counted across every workspace. When creating something would cross one, the request fails with PLAN_LIMIT_REACHED (402) naming the resource and the used-over-limit pair — nothing is created, and nothing is charged.

PlanPrice / moSeatsWorkspacesAgentsDatabasesWebhook events / mo
Toolkit$191 · +$9/seat1with modulewith module0
Toolkit All-Access$1391 · +$9/seat151750,000
Solo$991 · no add-on1515,000
Team$1993 · +$49/seat115325,000
Business$4995 · +$99/person1 + 1 per seat5010100,000
  • Toolkit buys its caps as modules: holding Agent Runtime grants 5 agents and holding Database grants 1 database. Without the module, the cap is zero.
  • 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 this table.
  • Everything here is monthly. There is no annual billing.
05// workspace-scoped

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.

one key, one workspace

If an agent needs data from two workspaces, it needs two keys. There is no cross-workspace key, and no way to widen one.

Related: tools and tool families for what a workspace serves to an agent, and errors and rate limits for the codes named above.