Multi-Project Workspaces

Documentation Index

Fetch the complete documentation index at: https://docs.overcut.ai/llms.txt

Use this file to discover all available pages before exploring further.

A workspace can contain one project or many. Each project is a self-contained scope of work with its own agent harness: the set of Agent Roles, Skills, MCP Servers, repositories, and vault secrets that defines what the agents inside this project can do, see, and call. The surrounding workspace is what stays shared: billing, integrations, LLM models, teams, and workspace-level secrets. Multi-project workspaces exist so a single team or org can run automation against several distinct codebases, products, or initiatives, each with its own bounded harness, without workflows, credentials, or permissions bleeding into each other.

​

Why projects

Projects exist to keep agent runs focused on a narrow harness, give each team ownership of its own scope, and isolate work that should not share credentials, repos, or audit trails.

​

Bounded scopes produce better agent results

An agent that can see ten MCP servers, fifty skills, and every repository in the workspace has to decide which of them are relevant on every call. The wider the harness, the more often it picks the wrong tool, opens the wrong repo, or pulls in irrelevant context. A project deliberately narrows the harness to the MCP servers, skills, agent roles, and repositories that actually apply to one scope of work. Inside that boundary the agent has fewer choices, and the choices it does have are all relevant, which is what makes agent runs sharper, faster, and more predictable.

​

Team-owned harnesses

Projects are the unit of ownership. The team that does the work in a project is the team that edits its harness (its agents, skills, MCP servers, repositories, and vault) without needing access to anyone else’s. Workspace administrators still control the shared substrate (integrations, models, workspace secrets, team membership), but the day-to-day changes belong to the team that runs that project.

​

Isolation by default

A project’s vault, repositories, MCP servers, and run history are not visible from other projects. That makes projects the right boundary when work needs separate credentials, separate codebase access, or separate auditability, for different products, different environments, different customers, or different business units sharing one Overcut workspace.

​

When to use multiple projects

Create a new project, instead of adding more workflows to an existing one, when any of the following are true:

• The work targets a different codebase or product surface that should not share repositories, workflows, or vault secrets with anything else.
• A different team should own the project. Each team edits its own project’s settings; cross-project edits are blocked by permissions.
• It needs a different set of credentials (for example, separate API keys, separate database connection strings, separate cloud accounts) that should not be visible to other workflows in the workspace.
• You want separate auditability: runs, history, and feedback that don’t mix with unrelated work.

If two areas of work share the same repos, the same secrets, and the same team, one project is usually enough.

​

What lives where

The boundary between workspace and project is the most important thing to understand. Anything that should be set once for the whole organization lives at the workspace level. Anything tied to a specific scope of work lives in a project. The rule of thumb: shared infrastructure stays at the workspace; each project’s harness, and the team that owns it, stays in the project.

​

Workspace-level navigation

From the workspace sidebar (no project selected), you have access to:

• General: workspace name, timezone, default LLM model, and the Auto-Improve Workflows toggle. See Workspace Settings.
• Projects: the list of all projects in this workspace. From here you can create new projects, rename them inline, assign a color, and delete them.
• LLM Models: manage which LLM models are available to projects in this workspace.
• Integrations: connect Git providers and ticket trackers.
• Context Map: a workspace-wide view of repository correlations. See Context Map.
• Security: Users, Teams, Roles, Workspace Secrets, API Tokens.
• Usage & Billing.

​

Project-level navigation

When you select a project from the sidebar’s project picker, the URL becomes project-scoped (/:workspace/:project/...) and the sidebar changes to show the work that happens inside that project:

• Dashboard: project-level overview.
• Playground and Executions: run and review work inside this project.
• MCP Servers, Skills, Agent Roles: the agent harness for this project. Each belongs to a single project and cannot be referenced from another.
• Use Cases: workflows that orchestrate those agents.
• Project Map: orchestration view scoped to this project’s workflows, agents, and resources. Distinct from the workspace Context Map.
• Project Settings: repositories, vault, and permissions for this project. Covered below.

​

Switching and managing projects

Projects are managed in two places:

• Sidebar project picker: at the top of the workspace sidebar. Use it to switch between projects, jump to a project’s settings, or create a new project inline. It also links to the workspace Projects page for full management.
• Workspace → Projects: the management page where you create, rename (inline), assign colors, and delete projects.

​

Project deletion

Deleting a project is destructive. It removes the project’s entire harness (agent roles, skills, MCP servers, vault secrets), its workflows, and its run history. To prevent accidents, the delete dialog requires you to type the project’s name before the action is allowed.

​

Project Settings

Project Settings are where the team that owns the project shapes its harness: which repositories it can see, which secrets it can use, and who’s allowed to edit it. Each project has its own settings page at Project → Project Settings with four tabs:

​

Project Repositories

Each project either uses every repository connected to the workspace, or only a chosen subset. The toggle is Allow access to all repositories on the Project Repositories tab.

• Allow all on: workflows, agents, and triggers in this project can run against any repository connected to the workspace. Use this when projects share the same codebase pool and the project boundary is about workflows and people, not repos.
• Allow all off: pick specific repositories. Workflows, triggers, and repository-aware steps in this project will only see those repositories. Use this when a project should be hard-isolated from unrelated codebases, common when one workspace serves multiple products or business units.

​

Project Vault

The Project Vault is where you store credentials that the project’s workflows, agents, and MCP servers need at execution time: API keys, tokens, database passwords. Secrets are encrypted at rest and injected as environment variables into the execution sandbox; they are never sent to the LLM. See Vault for the full reference. The Project Vault is distinct from Workspace Secrets (under workspace Security → Workspace Secrets), which holds platform-wide credentials such as the Claude API key used by the Claude Agent SDK.

​

Permissions

Each project is owned by the teams granted access to it. Permissions are layered: a user must be a member of the workspace, and that membership must include access to the project. On the Permissions tab you assign workspace teams to the project and pick the role each team gets here, typically letting a team edit its own project without touching anyone else’s. A project-level team assignment does not automatically grant access to another project.

​

Common patterns

• One product, one project. Smallest setup. One team, one set of secrets, one set of agents and skills.
• One product, multiple environments. Use separate projects per environment (e.g. staging, production) when each environment needs different credentials, different repository scopes, or different teams reviewing runs, even when the setup is otherwise similar.
• Platform team + product teams. Workspace administrators manage the shared substrate (integrations, models, workspace secrets). Each product team owns its own project, with its own MCP servers, skills, agent roles, repos, and vault.
• Agency / multi-tenant. One project per client, each isolated: separate repositories, separate vault, separate permissions. Workspace-level integrations stay shared.

​

Related

• Workspace Settings: workspace-level configuration.
• Vault: Project Vault reference.
• Context Map: workspace-wide repository correlations.
• Repositories: connect repositories to the workspace.