One workspace per system you automate.
Development. Content. A client. Autonomous ops. Each runs as its own workspace with its own workflows, executors, policies, settings and memory. You do not run one of these; you run several, and one recall searches across all of them.
Once the first loop works, you do not build a second tool; you open a second workspace. The pattern that emerges from running autonomous systems in production is one workspace per system: your development flow, your content pipeline, a client engagement, an outbound motion. Each is a complete operating environment with its own task graph, workflow templates, routing, policies, executors, settings, and memory.
The separation is not cosmetic. A client's workspace is isolated at the database layer, its execution can point at different infrastructure than yours, and its policies can be stricter than your internal ones, all without a single shared knob. What stays unified is you: one identity across every membership, and one recall that searches all of them in a single query while every write lands in exactly one.
This is what turns ConvOps from a tool into an operating layer. You are not managing tasks in an app; you are running several governed systems side by side, each cheap enough to spin up that a new automated system starts with creating a workspace, not a project plan.
An operating layer, not a tool.
A workspace owns everything its system needs: the task graph, the workflow templates and their routing, the policies, the executors, the settings, the brain. Nothing leaks between systems by default.
- Self-serve creation: a new system is a new workspace, not a support ticket
- Per-workspace execution config: one system on cloud, another on your own runner
- Behavior tuning is catalog-driven and self-service
Isolated ownership. Unified search.
Recall fans out across every workspace you belong to in one query, so the answer is never siloed. Writes always resolve to exactly one workspace. Memories stay owned by their workspace: one search, never a shared pool.
Invite the humans. Keep the roles plain.
Owner, admin, member. A real invite lifecycle with expiry, revocation and decline. The people governing a system see exactly that system.
Enforced where it cannot be bypassed.
Workspace isolation is Postgres row-level security with FORCE: even the table owner cannot step around it, and a query without tenant context returns nothing. Application-level scoping and tenant middleware sit on top, not instead.
questions
How many workspaces should I run?
One per automated system is the pattern that holds up: development, content, a client, an outbound motion. The boundary follows the system, not the org chart, because workflows, executors, policies, and memory all live at the workspace level.
Is memory shared between workspaces?
Search is unified; ownership is not. One recall fans out across every workspace you belong to, but each memory stays owned by its workspace and isolated at the database layer, and writes always resolve to exactly one workspace.
Who can see what?
Members see the workspaces they belong to, under three plain roles: owner, admin, member. Invites follow a real lifecycle with expiry, revocation, and decline, and isolation is enforced by row-level security the table owner cannot bypass.
Can different workspaces execute on different infrastructure?
Yes. Execution configuration is per workspace: one system can run on ConvOps cloud while another dispatches to your own OpenCode server or a custom runner, without any task definition changing.
What does creating one involve?
It is self-serve: name it and it exists, with its own settings catalog ready to tune. A new automated system starts with a workspace, not a procurement cycle.