Workspaces

A workspace is an isolated container for everything in Studio: agents, models, MCP servers, embeddings, and sentinels. Think of it as a project or environment.

​

Why workspaces exist

Different teams, clients, or use cases need separate configurations. A customer support team and a finance team shouldn’t share the same agents, models, or API keys. Workspaces enforce this separation cleanly.

​

Switching workspaces

Use the workspace switcher at the top of the sidebar to switch between workspaces. Everything you see in Studio — agents, settings, the Discover feed — is scoped to the active workspace. Switching workspaces is like switching projects.

​

OCI addressing

Workspaces use OCI (Open Container Initiative) addressing — the same convention used by container registries like Docker Hub. Each workspace has:

• Namespace — your organization scope (e.g., alquimia, set by NEXT_PUBLIC_DEFAULT_NAMESPACE)
• Name — workspace identifier (e.g., customer-support)
• Full address — namespace/name (e.g., alquimia/customer-support)

This addressing enables the Discover & Publish feature — workspaces can be published to an OCI registry and installed by others, just like container images.

​

Workspace naming rules

Workspace names are sanitized to OCI format automatically:

• Lowercase only
• Letters, numbers, hyphens, dots, and underscores allowed
• Spaces become hyphens

The display name is restored to title case in the UI. The raw name stored in the registry is always OCI-compliant.

​

Roles within a workspace

Access to a workspace is controlled by your RBAC role. If your deployment uses Keycloak, roles are assigned there. See Roles & Permissions for the full breakdown.

​

Next steps