Concepts

Workspaces

A workspace is where work lives. Every conversation, run, agent, skill and knowledge collection belongs to one — and workspaces are first-class: named, shared, and governed, not just a personal scratch area.

Default and named workspaces

Every user has a default Personal workspace, and every org a default Organization one. On top of those, anyone can create named workspaces — a project space, a team space — with their own membership.

Default is implicit, named is explicit — at every altitude You are always a member of your default workspaces. A named workspace is reached only through an explicit membership row (contributor or maintainer), resolved per request — so removing someone takes effect immediately, not at token expiry.

Nothing is unscoped

There is no "no workspace". A conversation or run with no explicit choice lands in your Personal default; picking a workspace in the switcher scopes what you are viewing and pre-fills where new things are created. Crucially, a workspace is never ambient on a write: every creation surface shows the destination as a visible, editable field, so you always know where an agent or a collection is about to be created.

Collaboration surfaces

Activity — what has happened in the workspace.
Board — shared items the members are working on.
Knowledge — collections scoped to the workspace.
Memory pool — a shared memory written by the remember_for_workspace tool: a team decision or glossary term, visible to every member, distinct from personal memory.
Members — who is in, and at what role.

Blueprints and guardrail floors

An org can stamp a new workspace from a blueprint — a manifest of starter agents, skills, seed policies, settings and member roles — so a new team space starts governed on day one. A blueprint can set a policy floor: a minimum strictness a narrower scope may tighten past but never loosen. Setting a floor is org-admin-only, and there is deliberately no break-glass bypass.

A workspace home — activity, board, members and knowledge.

Stage-gated processes

A workspace can declare an ordered list of stages (for example draft → review → live); entities inside it carry a stage, and a transition runs the gates that already exist — a scan, an eval, an approval — chosen per stage. Absence of a process is the single implicit stage, so untouched workspaces behave exactly as before.