Workspace Model

Workspace is Evose's resource isolation unit · 4 resource categories + independent RBAC + independent observability

Workspace is Evose's resource isolation unit. Every build action takes place inside a Workspace and never leaks across them.

What It Is

A Workspace is a self-governing build sandbox:

Has its own Agents / Workflows / Knowledge bases / Data sources / Tools / Skills
Has its own members and RBAC + ACL settings
Has its own observability view (Logs / Metrics / Traces only see this workspace)
Receives models / global tools / credentials / roles delivered from the Organization (Layer 3)

Why You Need It

Without Workspaces, AI assets across teams in an organization will overwrite and disturb each other:

Without Workspaces	With Workspaces
CS and Marketing Agents mixed together	Isolated and invisible to each other (sharable under control)
A test knowledge base accidentally used by a production Agent	Knowledge base belongs to a workspace; cross-workspace use requires authorization
One role wants to distinguish CS perms vs Marketing perms — only by splitting orgs	Role + Workspace ACL gives a 2D refinement

Four Resource Categories

Each Workspace contains four categories of resources:

Category	Resources	Purpose
Apps	Agent · Workflow	Conversation/flow entry points users can directly call
Data	Knowledge base · Data source	The "facts" layer fed to AI
Capabilities	Tools · Skills	The "actions" and "experience packs" available to AI
Workspace management	Members · Permissions · Observability · Settings	Govern this workspace's metadata

Workspace vs Organization vs Workbench

┌────────────────────────────────────────────────────┐
│  Organization (Layer 3)                            │
│  Global supply: models / tools / credentials /     │
│  roles / member directory                          │
│  ┌──────────────────┐  ┌──────────────────┐        │
│  │ Workspace A      │  │ Workspace B      │        │
│  │ CS team          │  │ Marketing team   │        │
│  │ Agent · WF · KB  │  │ Agent · WF · KB  │        │
│  └────────┬─────────┘  └─────────┬────────┘        │
└───────────│──────────────────────│─────────────────┘
            ↓ publish to Workbench  ↓ publish to Workbench
       ┌────────────────────────────────┐
       │ Workbench (Layer 1)             │
       │ Users use any authorized Agent  │
       └────────────────────────────────┘

Roles

Each Workspace has 4 built-in roles:

Role	What they can do
Workspace admin	Everything — manage members, modify resources, delete workspace
App builder	Create/edit Agent / Workflow / KB / Tool; cannot manage members
Regular user	Use only apps published to the Workbench (equivalent to Layer 1 access)
Read-only	View only, no changes

→ See Members and Roles

Workspace Lifecycle

Stage	Action	Who
Create	Any organization member (when org policy allows)	Per org policy
Configure metadata	Name / description / type (personal/team) / icon / join policy	Owner + admin
Invite members	Add from organization member directory	Admin
Transfer ownership	Hand ownership to someone else	Current owner only
Delete	Permanent deletion; all internal resources invalidated	Owner only

Deletion is irreversible

All Agent / Workflow / Knowledge base / Tool configurations are wiped, and references in published Workbench apps go invalid simultaneously.

By default, resources in a Workspace are only visible inside it. To share:

Publish to Workbench — grant access to other roles / users / departments via resource ACL
Org-level resources — register Tools / Skills as organization resources at Layer 3 and authorize specific workspaces to use them
Copy / templating — turn a mature Agent / Workflow into a template for one-click cloning into other workspaces

Next Steps

Build an Agent → Agent vs Workflow vs Chatflow → Agent
Connect a knowledge base → RAG fundamentals → Knowledge base
Configure permissions → RBAC roles · Resource policy ACL

Workspace Model

On this page