Organizations and Workspaces

An organization is your company; a workspace is a team-sized scope inside it. Agents, assignments, sessions, and work surfaces live in workspaces; skills, integrations, guardrails, and governance can be set org-wide.

The two-level shape matters because it decides what is shared and what is governed. A workspace is the sharing boundary: its members see the same agents, boards, and data tables, and its agents reach the same connections. The organization is the governance boundary: it holds membership, org-wide skills and integrations, the guardrail floor every workspace inherits, usage reporting, and the audit log. A useful default is one workspace per team, because teams are what actually share systems and conventions:

Workspace	What typically lives there
Revenue	CRM connection, a pipeline-report agent, a lead-enrichment webhook assignment
Product	Competitor-tracker data table, release-notes assignments, analytics connections
People	Recruiting-pipeline tracker, a screening-notes agent, HR system connection

Every account starts with an organization of its own and a first workspace inside it, so there is nothing to set up before you begin. When a teammate needs to see the same work, invite them into that organization and rename it after your company under General. An account belongs to one organization at a time.

Organization settings

Open Organization settings from the user menu at the bottom of the sidebar (owners and admins). The tabs are General, Members, Workspaces, Goals, Guardrails, Routing, Single sign-on, Usage, Billing, Removed members’ work, and Audit log. Routing sets the organization’s default responder: the agent that answers inbound feedback, such as a GitHub pull request mention, that is not tied to a session. Workspaces and repositories can override it. Organization-wide skills and integrations are managed in Skills & integrations; see Workspace settings.

Members and roles

Organization members are Admins or Members, and one or more Owners sit above both. Owners and admins invite people, remove members, revoke pending invites, choose which workspaces each member can reach, and manage workspaces, domains, guardrails, and the audit log. Changing someone’s role is for owners alone, including making someone a co-owner, and so is Transfer ownership: the new owner takes over and the previous one becomes an admin. An owner can’t be removed from the organization or any of its workspaces until they step down or another owner demotes them, and an organization always keeps at least one owner.

Keep the admin set small. Admins join every workspace automatically, while most people only need to be members: they get the workspaces they belong to and everything shared inside them.

Inviting your team

Two paths:

Email invites — type or paste addresses into the invite box, pick Member or Admin, and choose Invite. A member always joins the organization’s default workspace; Workspace access adds others, as a Member or a read-only Viewer. Pending invites can be revoked.
Domain auto-join — under General → Domain management, claim your company’s email domains so new users who sign up with a matching address are automatically added to the organization.

During first-run setup, an owner or admin signed in with a company email can claim its matching non-consumer domain in one click. The same action remains available under General. Workprentice only offers the domain from the signed-in, verified address, and the server verifies the address and domain match when the claim is made.

Email invites suit the early days, when you are adding specific people and choosing their workspaces one by one. Domain auto-join is for the rollout moment: once the domain is claimed, anyone who signs up with a company address lands in the organization without an admin in the loop, so new hires stop arriving as solo accounts.

Someone who already signed up with a company address before the domain was claimed sees an offer to join the organization. Accepting deletes the personal organization they started in, with its agents, sessions, and work products, and the dialog asks them to confirm that first.

Seats

Every member of the organization is a seat on its plan. A seat is taken when someone joins: when they accept an invite, when they sign up with an address at a claimed domain, or when they first sign in through single sign-on. Only an invite asks an admin first, so an organization that grows by domain or by its identity provider can grow without anyone choosing each person.

Owners, admins and billing admins choose what happens next under Members → When someone new joins:

Wait for approval once the organization has a number of seats. People who arrive past it are held until someone approves them or adds seats.
Add a seat for everyone who joins. Nobody waits, and the people who manage seats get a daily list of who joined.

An organization paying by card starts on Wait for approval at the number of members it has when it subscribes, so every seat after that is one someone chose to add. Once the organization is full:

Inviting more people than there are open seats, counting invites not yet accepted, offers Add seats and invite, which raises the limit just far enough and sends the invites in one step.
Someone who arrives by their email domain or through single sign-on waits for a seat. They see a page saying the organization is full and that its admins know, and nothing is made for them elsewhere in the meantime. They can choose to start an organization of their own instead.
Accepting an invite, or the offer to join, is refused before anything changes, so nobody loses the personal organization they started in.

The people who manage seats hear about the first person waiting in their inbox and by email, and are emailed again at most once a day however many more arrive. Everyone waiting is listed under Members → Waiting for a seat, with how they arrived. Approve lets one person in, adding a seat if none is open; Let everyone in adds the seats the whole list needs. Raising the limit lets in the people first in line too. Each person let in is emailed, and their seat is held for them, so nobody who arrives later can take it; they are in on their next visit. Dismissing someone takes them off the list, releases any seat held for them, and tells them no seat was added. It does not bar them: if a seat is free when they next arrive and nobody is waiting, they join.

A seat that opens when a member leaves goes to whoever has waited longest, on their next visit; nobody who arrives later can take it first. Lowering the limit below the current number of members removes no one and keeps every seat already held; it only stops further joins. While an organization billed by invoice is within its term, it is held to the seats in its contract, whatever is chosen above, and adding more takes a new contract.

Removing a member

Removing someone keeps the work they shared where it is. Their private work is quarantined and the people it was shared with lose access, and their API keys are revoked. Removed members’ work is where an admin reviews what was left behind, preserves it, or gives a current member custody of it.

Workspaces

Owners and admins create workspaces with New workspace, which asks only for a name, unique within the organization. Make new members join here sets the default workspace new members land in.

A workspace is archived before it can be deleted. Archiving takes it out of the workspace switcher and makes everything inside it read-only, and Unarchive brings it back. Delete permanently is offered only once a workspace is archived, and it destroys everything inside. The organization’s last workspace cannot be archived or deleted.

Workspace settings

Workspace settings, in the same user menu, has Usage, Members, Goals, Guardrails, Routing, and API keys (see API keys and webhooks). Routing says where external events reach this workspace’s agents: the workspace’s default responder and per-repository overrides for GitHub feedback, and which channels mirror to Slack. Workspace admins edit the GitHub routing. A channel’s Slack mirror is managed by the person who opened the channel or by a workspace admin. Other members can see it all. Workspace admins also see Agents, an inventory of every agent including private agents and adopted copies, and Removed members’ work. Org owners and admins get a Danger zone for archiving the workspace.

Workspace members are Admins (manage the workspace’s skills, agents, and integrations), Members (create and edit work), or Viewers (read-only). Org owners and admins are admins of every workspace. The Members tab adds someone from the organization, or invites someone new, who joins the organization and this workspace when they accept.

Skills and integrations live in Skills & integrations, next to where you use them. For skills, the Workspace and Organization pills switch between what the workspace owns and what the organization provides. Integrations are one list, each row saying who it is available to.

Agents, assignments, documents, boards, data tables, apps, knowledge, skills, and sessions share the same way: Share on the item opens a panel with People with access and General access. Add people at the level that item offers — Can view, a middle level named for the item (Can use an agent, Can run an assignment, Can comment on a document, Can update tasks on a board, Can edit rows in a data table), or Can edit. General access is either Everyone in the workspace or Only people added. Sharing with the whole workspace grants view access; members can edit beyond that according to their workspace role.

Usage and the audit log

Usage reports spend in work units and dollars, sessions, and cache hit rate over a range you choose, grouped by tier, kind, workspace, or agent. It drills from workspaces down to agents and individual sessions, and Download CSV exports the level you are looking at. Plans and prices are on the pricing page.

The Audit log is a read-only record of administrative and agent activity across the organization, filterable by event type, actor, and time, and downloadable as CSV or JSONL for compliance review.

These two surfaces answer the questions that arrive once agents do real work. Usage answers “where is the spend going?” — drill from the organization to a workspace to the one agent whose assignment is heavier than expected, then to the individual sessions behind the number. The audit log answers “who did what, and when?” — and because it is exportable, the answer can leave the product and enter your compliance process.

Patterns that work

Start solo, invite later — use Workprentice alone in the organization your account came with, then invite teammates into it the day one needs in. Your work is already where they will be.
One workspace per team — Revenue, Product, People. Teams share systems and conventions; workspaces are built to hold exactly that.
Shared things at org scope, team things at workspace scope — the company style skill and the company document store org-wide; the CRM in the workspace whose team owns it.
Set the guardrail floor once — restrictions at the organization apply everywhere and cannot be loosened below; workspaces and agents only tighten from there. See Guardrails.
Archive before you delete — an archived workspace is read-only and out of the way, and nothing is lost until someone chooses Delete permanently.