The three levels
- An organization is the billing and membership boundary. It owns people and, uniquely, the infrastructure registry.
- A workspace belongs to an organization and holds the work: products, decisions, documents, logs, the board, the timeline.
- Products live in a workspace.
Signing up creates your organization and a workspace called Personal, seeded and ready. You do not have to think about any of this until you invite someone.
Roles
Membership is per organization, with a role - owner, admin, member - and that role decides what you can do in its workspaces. Invitations are by email and are accepted explicitly; an agent principal cannot invite, revoke or accept, because changing who can reach the tenant is a human act.
Read that sentence literally: an invitation grants a role in every workspace the organization holds, not in the one you were looking at when you sent it. A workspace is the boundary of the WORK; the organization is the boundary of ACCESS. If you need a person on one project and not the others, put that project in its own organization - membership, billing and infrastructure are all separated there. This is a decision rather than an accident, and the alternatives (per-workspace membership, or narrowing a person the way a token is narrowed) were weighed and left open for the day a contractor needs one project.
There is one asymmetry worth knowing: a TOKEN can be narrowed to a workspace with an allow-list, and a PERSON cannot.
Everything at once
Because your work can span several workspaces, Across everything (/overview, or get_org_overview) reads the organization as a whole: every workspace with its counts, every product ranked by what needs attention, and one merged queue of what is waiting on a human. It is assembled from the same per-workspace reads the Command Center uses, so it can never disagree with the board you open from it, and every row says which workspace it belongs to. Workspaces are read most-recently-active first and the list is capped - when it is, the response says so.
Infrastructure is the exception
Everything above belongs to one workspace. The infrastructure registry - hosts, platforms, datastores, databases - belongs to the organization, because a server is the one shared thing: several products run on it, and pretending it belongs to one of them makes the blast radius of a change unknowable.
That is why infra:read is its own scope and is deliberately not implied by any product scope. Holding it lets you enumerate every server the organization runs, which is strictly more than any product-level read.
Moving and exporting
A product can move between workspaces, and the move takes its history with it. A whole workspace can be exported as a bundle, and an organization as a wider one that includes the infrastructure a single workspace bundle cannot represent. Export is a scope of its own - workspace:export - because a bundle is everything at once.