Tenancy and workspaces

Culvii has three levels of organizational hierarchy:

Tenant → Environment → Workspace → Workflow / Agent

Tenant

A tenant is your organization. It's the top-level unit. Every team using Culvii is a tenant.

When you accept an invite, Culvii provisions a tenant for your organization with three environments — dev, sandbox, and prod — and makes the first user the Owner.

Tenants are isolated from each other. Two tenants share infrastructure but never share data, runs, or audit log.

Owner

The Owner is the person who first logs in to a new tenant. Owners can:

• Access all three environments by default.
• Create workspaces in any environment.
• Invite team members and assign their access.
• Manage tenant-level settings (billing, identity, default policies).

There can be multiple Owners. If the original Owner leaves the company, another Owner can be promoted from a member.

Environment

Each tenant has exactly three environments: dev, sandbox, and prod. They cannot be added, removed, or renamed. See Environments.

Workspace

A workspace is a container for workflows and agents. Inside an environment, workspaces give you a way to scope access and group related work.

Examples of how teams use workspaces:

• One per business domain — procurement, customer-support, data-pipeline.
• One per team — platform, growth, finance.
• One per developer in dev. (culvii dev automatically provisions a dev-{username} workspace if one doesn't exist.)

Workspaces can be created and deleted. Their structure can vary across environments — you might have two workspaces in dev (per-developer scratch spaces), one shared workspace in sandbox, and three production workspaces split by team.

Member access

Team members are invited at the tenant level. Once invited, the Owner grants them access to specific workspaces in specific environments.

A typical developer might have:

• Access to their own dev-{username} workspace in dev.
• Access to the team's growth-uat workspace in sandbox.
• No access to any workspace in prod.

Access changes take effect immediately. There's no key rotation needed when access is changed — the platform resolves permissions per request.

What lives where

Resource	Scope
Tenant	top-level
Owner role	tenant-level
Environment	inside a tenant (always 3)
Workspace	inside an environment
API key	environment-scoped (optionally further scoped to a workspace)
Workflow	inside a workspace
Agent	inside a workspace
Run	belongs to a workflow or agent
Audit event	tenant-level (queryable per workspace)

What's not in v1

• Sub-workspaces or folders inside a workspace. Workspaces are flat.
• Cross-workspace references (e.g., a workflow in procurement calling an agent in support). Each workspace is a closed unit.
• Custom roles beyond the built-in scopes (admin, developer, runner, read-only). On the roadmap.
• Cross-tenant federation. Tenants are fully isolated. Multi-tenant scenarios (a parent organization with subsidiaries) ship later.