Skip to main content
A workspace is the top-level team, billing, and memory-pool boundary. A vault is the shared Context Vault container inside a workspace.
workspace_id always identifies the team/account boundary. vault_id identifies a Context Vault inside that workspace. In the dashboard, create workspaces, invite teammates, and manage billing owners from Settings → Workspaces. Context Vault is focused on selecting a workspace, adding knowledge, browsing documents, and searching vault content.

​
Roles

Workspace creators become owner. Invitations can assign admin, member, or viewer; owner is not an invitable role. Invitations are emailed to the teammate and do not create membership until that user accepts the invite from the same email address.

​
Billing owner

Each workspace has one billing owner. By default, the billing owner is the user who created the workspace. The workspace subscription controls the workspace memory pool and Context Vault allowances. Invited admins and members can upload documents when their role allows it, but usage is charged to the workspace, not to the uploader’s personal account. Only workspace owners can change billing state such as checkout, cancellation, or plan changes. Admins can view usage and billing status.

​
Member memories

Member memories are saved inside the selected workspace and belong to the user who created them.
Normal REST, SDK, API-key, OAuth, and MCP memory calls only search the caller’s own member memories within the selected workspace, even for workspace owners and admins. Workspace-wide member-memory visibility is reserved for dashboard-specific owner/admin surfaces. Update and delete operations remain owner-scoped, and viewers cannot create, update, or delete member memories.

​
Vault memories

Context Vault knowledge is saved inside a vault.
If a workspace has one default vault, dashboard and API flows can resolve it automatically. If a workspace has multiple vaults, callers should select the vault they want to search or ingest into.

​
API keys

API keys are bound to one workspace. Existing keys are assigned to the user’s default workspace during migration. The dashboard prompts for a workspace when creating keys; API calls that omit workspaceId use the user’s default workspace. MCP and API-key calls resolve the workspace from the key, so normal memory tools do not need a workspaceId parameter. Context Vault REST endpoints still accept workspaceId for session callers; API-key callers must omit it or pass the same workspace bound to the key.

​
Workspace isolation

Every member memory, vault document, chunk, citation, feedback item, and correction is checked against workspace_id. Vault retrieval additionally checks vault_id. A query for one workspace never returns another workspace’s knowledge. Use separate workspaces when the data belongs to different companies, customers, tenants, or legal entities.