Core Building Blocks

Overcut automations are built using four fundamental building blocks. Once you understand how these pieces connect, you can create, customize, and troubleshoot any Overcut flow, from code review to spec generation to ticket triage.

---

​

Use Case

What it is:
A Use Case defines an end-to-end automation scenario. It wraps your trigger, all actions and agents, and your entire logic graph. Why it matters:
Use Cases give structure and intent to your flows. They let you describe what problem you’re solving—like automating bug triage or reviewing a pull request—while encapsulating all technical logic inside. Use Cases also improve over time. Every Use Case has its own memory, and Overcut runs retrospectives on past executions to capture lessons, refine existing guidance, and share it with future runs — so the Use Case gets sharper the more it’s used in your workspace. Core elements inside a Use Case:

• One Trigger (when the flow should start)
• One or more Actions or Agents (what should happen)
• A visual or declarative flow graph connecting them

---

​

Trigger

What it is:
A Trigger defines when a Use Case should run. It’s the event that starts execution. Supported trigger types include:

• Pull request opened
• Issue labeled or updated
• Mention detected (e.g. @overcut)
• Slash command issued (e.g. /review)
• Scheduled events
• Manual button click

Trigger Delays:
You can configure an optional delay before workflow execution to allow related updates to complete. This is useful for:

• Issue creation: Wait for fields to be filled out and labels to be added
• PR updates: Allow time for description edits and initial comments
• Field changes: Let users complete their input before processing

---

​

Action

What it is:
An Action performs a single operation during the flow. An action can be deterministic like “Clone a repository” or “Create a branch”, or it can AI based. Currently supported actions:

• git.clone: Clone repositories for code analysis
• repo.identify: Automatically determine relevant repositories for tickets
• agent.run: Execute a single AI agent for straightforward tasks
• agent.session: Start multi-agent sessions with coordination
• ci.executeWorkflow: Trigger external CI/CD workflows such as GitHub Actions

---

​

Agent

What it is:
An Agent is an AI-powered block capable of making decisions, generating content, and collaborating with users. Agents have access to predefined tools and can be trained for specific tasks. Agents are built on top of built-in specialized agent types. Agent Action Types:

• agent.run: Execute a single agent for focused, non-interactive tasks
• agent.session: Coordinate multiple agents for complex, interactive workflows

Base agent types: Every agent is built on one of five base types, each with a different default toolset and behavioral focus: Built-in tools use a provider-agnostic interface: an instruction like “create a ticket” or “open a pull request” works across all your connected integrations (Jira, Linear, GitHub, GitLab, etc.) without any changes. See the Agent Tools Reference and Base Agent Types for full details. Creating your own agents:

• Agents are always built on top of one of the base types above.
• You can customize the agent with your own instructions, additional tools, and model selection.
• You can add MCP Servers to give the agent access to external tools.

​

Model defaults and fallback order

Agents inherit their model selection from a strict cascade so you can define a single control point and let the rest fall through:

1. Coordinator override — coordinatorModelKey on an agent.session coordinator (never applied to child agents)
2. Agent model — the agent’s own modelKey
3. Workflow default — defaultModelKey defined in Workflow Metadata
4. Workspace default — configured in Workspace → General Settings
5. System default — Overcut’s managed default model

---

​

Execution

Execution is the process of running the Use Case graph step-by-step. Once triggered, Overcut executes the Use Case graph step-by-step. Each node is evaluated in order, and each agent or action completes its task before the next begins. Execution is observable and can be monitored from the Executions page.

---

​

Workflow Execution Control

Priority Queuing:
Control execution order when multiple workflows target the same resource using a 1-100 priority scale (lower numbers execute first). Resource Locking:
Only one workflow runs per issue, PR, or repository at a time, preventing race conditions and conflicts. Event Deduplication:
Rapid-fire events automatically merge while queued, reducing redundant executions by 60-80%. Queue Processing:
Background system processes workflows in priority order with FIFO within same priority level.

---

​

Advanced Workflow Features

Parallel Execution:
Multiple independent steps can run simultaneously to improve workflow performance. Conditional Logic:
Steps can be executed based on conditions and previous step results. Error Handling:
Workflows can include fallback paths and retry mechanisms for failed steps. State Management:
Context and results are preserved between steps for complex multi-step workflows.