Skip to main content
Every engineering organization is now building a software factory: agents that pick up tickets, write and review code, keep documentation current, and respond to incidents. The open question is what to build it on. Whatever you choose anchors the workflows, skills, memories, and policies your teams accumulate on top of it, which makes it the hardest decision to undo later. This page lays out the advantages of Overcut for an organization making that choice, grouped under the three questions worth asking of any platform: what it locks you to, whether it runs the whole factory or one station, and whether your organization can operate it.

​
The paths most teams are weighing

Most evaluations come down to one of three paths, each with a gap.
  • Assemble it yourself from a coding agent, CI jobs, and scripts. You keep full control, and you also own the governance, sandboxing, observability, and memory layers that a factory needs and a coding agent does not provide.
  • Adopt your Git host’s or model vendor’s agent platform. You start fast, and the factory is tied to that host or that model family for as long as it exists.
  • Buy a closed agent product. You get a strong agent and someone else’s opinion of how your delivery process should work, with the model, runtime, and often the hosting fixed by the vendor.
Overcut is a fourth path: build your own factory on a platform that does not own your choices. The Git host, ticket system, model, harness, and deployment target are all configuration. The delivery loop is covered end to end. And the whole thing runs inside boundaries your administrators define.

What does it lock you to?

Vendor, model, harness, and deployment stay your decision.

Whole factory or one station?

One platform from trigger to write-back, with agents working as teammates in your tickets and pull requests.

Can your organization operate it?

Governance, scale, and administration for many teams.

​
What does it lock you to?

The parts underneath a software factory will change. Models improve every quarter, agent runtimes are consolidating, and Git hosts and hosting requirements shift with acquisitions and compliance reviews. Overcut is designed so that each of these can change without rebuilding what sits on top.

​
Vendor agnostic

Overcut connects natively to GitHub, GitLab (including self-managed instances), Bitbucket Cloud, Bitbucket Server / Data Center, and Azure DevOps for code, and to Jira (Cloud and Server / Data Center), Linear, ClickUp, and Azure DevOps work items for tickets. Slack brings the factory into team chat. Events from all of them are normalized into the same trigger types and conditions, so a pull request review workflow behaves the same whether the pull request came from GitHub or Azure DevOps. Organizations that run more than one host, or that expect to migrate, keep one set of workflows. See the Integrations overview.

​
Model agnostic

Overcut ships with system-managed models so teams can start without credentials, and accepts your own keys for OpenAI, Azure OpenAI, Anthropic, AWS Bedrock, and OpenRouter, which also opens up open-weight models. Models you host yourself, or route through a gateway such as LiteLLM, connect through a custom Base URL on an OpenAI-compatible or Anthropic-compatible endpoint. The choice is made per agent, not per platform. A triage step can run on a fast, inexpensive model while the implementation step that follows runs on a stronger one. Defaults cascade from workspace to workflow to agent, so an administrator can pin the workspace to an approved model or region and let workflow owners override only where they need to. Test Model confirms the connection and detects tool calling, vision, and other capabilities before a run depends on them. See LLM Models.

​
Harness agnostic

The harness is everything in an agent except the model: the loop that sends prompts, executes tools, and decides when the task is done. Overcut ships two, chosen per step in the Workflow Builder under Execution Engine. Overcut runs Overcut’s own agent runtime and accepts every model provider on the LLM Models page. Claude runs Anthropic’s Claude Agent SDK, the same runtime behind Claude Code, with Anthropic, AWS Bedrock, or any Anthropic-compatible gateway. The agent definition does not depend on the engine. Instructions, sub-agents, Skills, MCP servers, secrets, the repository checkout, and Overcut’s integration tools carry over, and one workflow can mix engines across its steps. When a better runtime appears, you change a dropdown instead of rewriting the agent. See Execution Engines. The same openness applies to how your engineers work with Overcut. They can connect Claude Code, Cursor, Codex, or any MCP-capable coding agent and use it to register repositories, publish workflows, and check on runs without leaving their terminal.

​
Deploy anywhere

Overcut is available as a hosted service and as a customer-managed deployment that installs into your own Kubernetes cluster, in a private cloud or on-premises, with a published release and vulnerability management lifecycle. The distinction that matters for regulated teams is what stays inside your boundary. Many hosted agent platforms run a sandbox on your side while the agent loop, the model calls, or both stay on the vendor’s side. In a customer-managed Overcut deployment, the control plane, the workflow engine, and the execution sandboxes all run in your environment, and models are reached through your own keys and endpoints. Bitbucket Server / Data Center and Jira Server / Data Center connect directly from that deployment. On Overcut Cloud, repositories and tickets are fetched just in time with scoped, time-limited tokens, every execution runs in an isolated sandbox that is torn down afterwards, and the default models run on Overcut-managed Azure OpenAI with no training on your data and regional residency. See Privacy & Security and Network Allowlisting.

​
Does it run the whole factory or one station?

A factory made of point solutions has a coding tool, a review tool, a documentation tool, and a chat bot, each with its own permissions, logs, and billing, and nothing that carries a work item from one to the next. Overcut is one platform for the loop, and the people in the loop take part from the tools they already have open.

​
End-to-end SDLC

  • Workflows start from an event, run agent steps and code actions, and write results back to the ticket, pull request, or channel. You build them three ways: visually in the Workflow Builder, by describing what you want in Overcut chat, or headless from your own coding agent. Either way they are versioned and can be exported or imported as files.
  • Orchestrations coordinate a work item across several approved workflows until a goal is complete, with a person deciding at each gated step. See Orchestrations.
  • Retrospectives review completed runs and write workflow memories back to the agents, so a workflow stops repeating the same mistake and picks up the conventions specific to your team. See Workflow Self-Improvement.
  • Built-in base agents (Senior Developer, Code Reviewer, Tech Writer, Product Manager) ship with role instructions and toolsets ready to specialize, and every run is visible live with structured logs. See Base Agents.

​
Native SDLC integration

Work starts where it already lives, not in a separate console. Results are written back the same way: a comment on the ticket, a pull request with a review, a message in the thread that asked.

​
Agents as teammates, not a separate tool

Overcut’s agents live inside the tickets, pull requests, and channels your team already works in, and they behave like another member of the team.
  • Output arrives as comments. An agent reports its findings as a comment on the ticket, a review on the pull request, or a reply in the Slack thread, in the same place and format a colleague would use. Nobody opens a separate console to see what the agent did.
  • Anyone replies natively. Mention @overcut, type a slash command, or reply on the thread, and the agent picks it up. Interactive sessions keep the conversation context across comments, so a follow-up question continues the same task instead of starting over. See Trigger with Slash Command.
  • The whole organization takes part. Developers, product managers, QA, and management each work with agents from the tool they already use. A product manager can approve an orchestration step by replying on the Jira ticket, and QA can ask for a change on the pull request, without any of them installing anything.
  • Agents run in the background. Work starts from an event or a schedule and runs in an isolated sandbox on Overcut’s side. No IDE has to stay open and no laptop has to stay on. You check on a run in monitoring, or ask about it in Overcut chat.

​
Fully customizable

Overcut supplies the platform. Your organization supplies the process.
  • Agent Roles with hand-picked tools and instructions. See Base Agents.
  • Skills that package procedures once and are versioned alongside the code they describe. See Skills.
  • MCP Servers for any system without a native connection, with an allowed-tool list per server. See MCP Servers.
  • Agent Images for bringing your own container image with the toolchain your repositories need. See Agent Images.
  • Workflows and orchestrations you build visually, and a Playbook Catalog so teams start from a working pattern rather than a blank canvas.
  • Custom Events and Context Parameters so one workflow serves many repositories, teams, and processes.

​
Can your organization operate it?

A factory that only its builders can run does not scale past one team. Overcut is built to be administered centrally and used by many teams at once.

​
Governance and control

Every agent action runs inside a permission boundary an administrator defined, and every change to that boundary is recorded.
  • Roles and teams. Roles carry granular permissions and are assigned through teams, at the workspace level and per project. Overcut ships defaults such as Admins, Workflow Builders, Integration Managers, Repository Managers, and Workflow Run Viewers, and you can define your own. See Multi-Project Workspaces.
  • Single sign-on. SAML and OIDC identity providers, with users routed by email domain and optional automatic joining. Request it from the workspace Security settings with Ask to add SSO.
  • Scoped access. Each project defines which repositories, Agent Roles, Skills, MCP servers, and Vault secrets its agents can reach. Secrets are encrypted at rest and never sent to the model.
  • Approval gates. Orchestrations pause with status Waiting on human before a gated workflow runs or a goal is marked complete, and only an explicit reply from a person lets them continue. The reply and the login behind it are recorded. See Approvals and Discussions.
  • Audit Trail. An append-only record of who created, changed, or removed which resource, with a field-level before and after diff and secret values redacted before the event is written. See Audit Trail.
  • Observability and spend. Follow every run live with structured logs, and break token usage down by model, workflow, and agent. See Token Usage Analytics.

​
Enterprise scale

A workspace holds many projects, and each project is a bounded scope with its own agent harness owned by one team. What should be shared stays shared: billing, integrations, LLM models, teams, and the Workspace Library.
  • Workspace Library. Platform teams publish Agent Roles, Skills, MCP Servers, Workflow Templates, Orchestration Templates, and secrets once. Projects attach them by reference, so a fix in the Library reaches every project. See Workspace Library and Reuse Across Projects.
  • Central administration. Projects, security, Audit Trail, and usage and billing are managed in one place, with per-project team assignments layered on top of workspace-wide roles.
  • Isolation by default. Every run gets its own sandbox, and a project’s agents see only the repositories and tools that project attached. See Multi-Project Workspaces.

​
What you keep when things change

The value of a foundation shows when something underneath it moves. This is what stays intact in Overcut when it does.

​
Where to go next