Skip to main content
A workspace can contain one project or many. Each project is a bounded 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, the Workspace Library, and context parameter definitions. 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, the Workspace Library, team membership), but the day-to-day changes belong to the team that runs that project.

​
Isolation by default

A project’s vault, project-owned skills and MCP servers, and run history are not visible from other projects. Resources in the Workspace Library are the deliberate exception: projects reuse them by reference without making copies. 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), the navigation is split into Workspace and Account groups:
  • Workspace: Integrations, LLM Models, Context Parameters, and Context Map. These pages manage shared connections, shared values, and workspace-wide visibility.
  • Account: Settings, Projects, Security, and Usage & Billing. These pages manage workspace defaults, project administration, access controls, and billing.
Within those groups, you have access to:
  • Settings: 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 Parameters: workspace-level parameter definitions and the values set on any scope. See Context Parameters.
  • Context Map: a workspace-wide view of repository correlations. See Context Map.
  • Security: Users, Teams, Roles, and API Tokens.
  • Usage & Billing: view usage and manage billing details.

​
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 Logs: run work and review runs inside this project.
  • MCP Servers, Skills, Agent Roles: the project-owned part of this project’s agent harness. Agents can also attach MCP servers and skills from the Workspace Library, and workflows can run Library agents.
  • Workflows: workflows that orchestrate those agents.
  • Orchestrations: goal-driven coordination of one item across approved workflows. See Orchestrations.
  • Project Map: orchestration view scoped to this project’s workflows, agents, and resources. Distinct from the workspace Context Map.
  • Project Settings: repositories, channels, vault, context parameters, 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, open the Workspace Library, jump to a project’s settings, or create a new project inline. It also links to the workspace Projects page for full management. The Library holds shared resources and templates but does not run workflows or orchestrations.
  • 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 and context parameters it can use, and who’s allowed to edit it. Each project has its own settings page at Project → Project Settings with six 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. Secrets that several projects share live in the Library Vault of the Workspace Library. A project secret with the same name as a Library secret wins in that project’s runs.

​
Context Parameters

The Context Parameters tab has two parts. Project Values sets this project’s values for parameters defined at the workspace level, such as the base branch every workflow in this project should use. Project Context Parameters holds definitions that exist only inside this project. See Context Parameters for how values resolve.

​
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.
Workspace-level permissions are additive. Teams whose roles already grant a permission at the workspace level (set under Workspace → Security → Teams and Roles) carry that permission into every project automatically. Per-project assignments on this tab grant access on top of those workspace-wide grants.

​
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, the Workspace Library). Each product team owns its own project, with its own workflows, repositories, and vault, and attaches shared MCP servers, skills, and agents from the Library.
  • Agency / multi-tenant. One project per client, each isolated: separate repositories, separate vault, separate permissions. Workspace-level integrations and Library tooling stay shared.
For choosing between sharing, copying, and scoping, see Reuse Across Projects.