Organization and Workspace

Personal First, Team Later

Agent Platform starts by giving each user a personal organization with one default workspace. That makes the first login simple: you have somewhere to connect integrations, create API keys, and start a session right away.

If you later join a team organization, the same user can switch between organizations and then between workspaces inside each organization.

What Belongs to the Organization

The organization is the membership and admin boundary.

It owns:

• Members and roles
• Invitations
• Org-shared integrations
• Org-wide permission grants

What Belongs to the Workspace

The workspace is the execution boundary.

It owns:

• The active session context for new work
• Workspace-shared integrations
• User-private integrations for that workspace
• Workspace-scoped permission grants

Active Context

Two pieces of state matter for human-driven surfaces:

• Active organization: carried in the CLI token or browser session
• Active workspace: stored as a per-user preference inside the control plane

New sessions and action lookups use both values together.

The public API is different. It does not inherit this active state. A workspace API key brings its own explicit workspace scope.

Connection Resolution Order

When AP looks for a connection for an action in the current workspace, it resolves in this order:

1. user_private_workspace
2. workspace_shared
3. org_shared

That lets a user override a shared connection with a narrower private one without changing the organization-wide setup.

Roles

Today the role model is simple:

• admin: can create organizations and workspaces, invite teammates, create shared integrations, and bypass explicit permission grants
• member: can create user-private connections and use actions only when a matching grant exists