Skip to content
AlumiaDocs

Search docs

Find pages, headings, and concepts. Press ⌘K or Ctrl+K to toggle.

Workspaces

Optional sub-org grouping for agents, projects, and members. Ala stays visible everywhere.

Open in ChatGPTOpen in Claude

Workspaces partition an org into smaller groups — typically one per team or department. They are opt-in: an org has them only if workspacesEnabled is set, and most orgs run fine with the implicit default.

When workspaces are enabled

Once enabled, almost every read and write carries a workspace condition. The runtime resolves a WorkspaceScope from the authenticated user:

FieldMeaning
enabledWhether the org has workspaces on.
workspaceIdThe active workspace for this request, or null if the user has no access.

A null workspace ID with enabled: true denies access — queries add false to the condition. With workspaces off, all rows are visible to org members per their normal RLS scope.

Org-wide vs project-scoped

ResourceScope
Workspaces themselvesOrg-wide table; one row per workspace.
AgentsworkspaceId column; agents are workspace-scoped, except Ala.
ProjectsA primary workspaceId plus optional shares via project_workspaces.
SessionsInherit workspaceId from the project or agent.
MemoriesFiltered through the workspace scope when enabled.

A project can be shared into multiple workspaces through the project_workspaces join table — useful when one project genuinely belongs to two teams.

Why Ala is special

Ala is the org's default agent. It's intentionally workspace-agnostic:

  • workspaceId is null.
  • The runtime adds an OR slug = 'ala' to every workspace agent filter, so Ala always shows up.
  • It's active by default and can't be deleted.
  • One row per org, deduped on creation.

This means every member, in every workspace, can talk to the same agent and share memories with it. Create new agents when you want behavior or tools scoped to a single workspace; use Ala when you want one collaborator that knows the whole org.

Defaults

A new org has one workspace marked isDefault: true. Members join workspaces with a role (owner, admin, member); the role gates membership listings, not row-level reads — RLS still does the heavy lifting.