Workspaces

A workspace is where work happens: one team, client or business line, with its own agents, teams, knowledge, records, rules and apps. A person can belong to many.

Shared and personal

See Your assistant for what the personal workspace does.

Members, roles and groups

• Roles are admin and member. Admins manage members, plugins, tokens and workspace settings.
• Invite people from Members with a link (valid 14 days, opened at /sign-up?invite=<token>). There is no mail server requirement.
• Groups (Members → Groups) grant access to workspaces. With VOCION_ENFORCE_WORKSPACE_ACCESS=1, membership and groups decide who can open each shared workspace.

Workspace as code

Everything a workspace runs on is authored as YAML and markdown in a git directory outside the vocion-core checkout (by default ../workspace/<name>), then applied to Postgres:

npm run workspace:apply -- ../workspace/northwind --project northwind

• WORKSPACE_PATH tells the app where the files are; unset means no workspace is configured.
• Every apply writes a workspace_version row (git commit, files, counts, who applied it).
• Every tool call, workflow run, mission run, eval run and worker run records the workspace_sha it ran on, with the base pack and plugin versions appended.
• When files and database drift, a banner offers a diff and Apply now to admins.
• Editing a mission, playbook or skill in the app writes the file and applies it; it doesn't commit.

The authoring reference is Workspace YAML.

Pausing

One switch stops everything a workspace does by itself: POST /api/v1/workspace/pause with a { "note": "why" } (or the MCP tool workspace_pause). Automation fires are recorded as skipped, mission runs and queued worker runs stop, and gated actions wait. Chat stays open, and a worker already holding a lease finishes and reports. The note is required; everyone in the workspace sees it on a banner until someone resumes.