Skip to main content
Projects keep each agent harness narrow, and that isolation is what makes runs predictable. It also means the second project that needs the same code reviewer, the same Datadog server, or the same pull request workflow gets a copy. Overcut has several ways to reuse work across projects, and each one answers a different question. This page tells you which one to reach for.

​
When copies become a problem

Two teams want the same code review workflow, but one of their repositories uses develop as its base branch. A platform team maintains a Sentry MCP server and three product teams each keep their own copy with their own API key. An orchestration for the mobile project is identical to the web one except for a branch suffix. A copy diverges the day it is made. Fixes land in one copy and not the others, credentials multiply, and nobody can say which version is current. The mechanisms below exist so that the thing that is actually the same is defined once, and only the thing that differs is set per project, repository, workflow, orchestration, or agent.

​
Shared, copied, or scoped

Three words describe every mechanism:
  • Shared means one resource that lives in the Workspace Library and is referenced from projects. There is one owner, one place to edit, and a change reaches every project at once. Agents, MCP servers, skills, and secrets are shared.
  • Copied means a project receives its own independent definition. Later edits to the source do not flow to the copy, and edits to the copy do not flow back. Library templates, Playbooks, and imported files are copied.
  • Scoped means one definition with values that differ by where a run happens. A context parameter is defined once and resolved per run from the most specific value on that run’s path.
Slack channels, runs, history, and anything you create inside a project without promoting it stay project-owned. Repositories belong to the workspace, and each project attaches the subset it uses. See Multi-Project Workspaces for the workspace and project boundary.

​
The reuse mechanisms

Workspace Library and Context Parameters cover every control for the first three. Playbooks and file import are covered in Overcut Playbooks and Import & Export Workflows.

​
How the mechanisms combine

The Library and context parameters are designed to be used together.
  • A Library template can reference {{params.<key>}}. Define that key at the workspace level. A project-level definition is not visible to the project that installs the copy, so the installed workflow fails to publish there until the key exists.
  • The Library defines no context parameters of its own. It holds shared resources and templates. Set values on the projects, repositories, workflows, orchestrations, and agents that run, including Library agents.
  • Values set on a Library agent travel with it. An agent-level value applies wherever that agent runs, in every project that uses it. Only workspace parameters can be set on a Library agent; a project parameter cannot.
  • A project secret beats a Library secret with the same name. Use this when a project needs its own credential for a shared MCP server: keep the Library secret for everyone else and add a same-name secret to the Project Vault.
  • Playbooks can seed the Library. Add a Playbook inside the Workspace Library to turn a public template into a private one that your projects install from.

​
Common patterns

  • Platform team and product teams. The platform team owns the Workspace Library: shared MCP servers with their secrets, shared skills, and a few reviewed agents. Product teams attach those by reference and keep their own workflows, repositories, and channels.
  • One workflow, many repositories. One published workflow with a base_branch context parameter. The workspace default is main; two legacy repositories set develop. See the quick start Reuse a Workflow Across Repositories.
  • One template, many teams. Author the workflow in the Library, publish it, and let each team install a copy. Put the values that should stay centrally managed into context parameters so the copies do not need to change when a convention changes.
  • Two orchestrations, one difference. Two orchestrations run the same workflows with a different branch suffix or marker comment. Set the value on each orchestration instead of copying the workflows.