Linear labels

When you delegate an issue to Delego, the relay reads labels attached to that issue to decide how to route the job — which agent to use, which model, and which repository to work in. These are configured entirely inside Linear using Linear's own label system, so there's nothing extra to install or configure in Delego.

Label groups

Labels in Delego are structured as label groups: a parent label (the category) with child labels (the values). In Linear, go to Settings → Labels and create the following groups. The parent label name is the key Delego reads; the child labels are the values you apply to issues.

executor — which agent runs the job

Create a parent label named executor in Linear. Under it, add the following child labels:

Apply exactly one executor child label to an issue. If two conflicting executor labels are detected, the job is held in a waiting state until you resolve the conflict.

model — which model the agent uses

Create a parent label named model in Linear. Under it, add child labels for the models you want to use. The value is passed directly to the agent, so use the model identifiers your chosen agent accepts:

You can add additional model child labels at any time — Delego passes whatever value you set through to the agent without validation, so any model your agent supports will work.

repo — which GitHub repository the job works in

Create a parent label named repo in Linear. Under it, add one child label per repository you want Delego to target. For example, a label named delegoapp/runner tells the runner to clone and work in the delegoapp/runner repository:

repo
  ├── myorg/frontend
  ├── myorg/backend
  └── myorg/infra

Delego also supports repository mappings configured in the dashboard (under Repository mappings), which can serve as a default when no repo label is present on the issue.

thinking — agent thinking level (optional)

The thinking label controls the extended thinking budget passed to the agent. It is optional — omitting it disables extended thinking.

If an unrecognised thinking value is set, Delego falls back to medium and records a warning on the job.

Label resolution priority

When Delego receives a webhook for a delegated issue, it resolves executor, model, and thinking using this priority order:

1. Issue labels — labels applied directly to the issue take highest priority.
2. Project labels — labels applied to the Linear project the issue belongs to.
3. Workspace default — a default executor configured in your Delego account settings. This applies to executor only.

This means you can set a default executor at the project level and override it on individual issues when needed, without labelling every issue by hand.

Repository resolution

The repo field follows a different path. At enqueue time it is read from issue labels or prompt context, the same as the fields above. If no repo label is found, Delego defers resolution to claim time — when a runner picks up the job, the relay looks for a matching entry in your repository mappings (configured in the dashboard under Repository mappings), matched by the Linear project the issue belongs to. If the project information was missing from the webhook, Delego fetches it from the Linear API and retries the mapping lookup.

Repository mappings are the recommended way to avoid putting a repo label on every issue: map a Linear project to a GitHub repository once in the dashboard, and all issues in that project route there automatically.

What happens when a label is missing or conflicting

If a required field can't be resolved — because a label is missing and no default covers it, or because two conflicting values are present — Delego holds the job in a waiting state rather than failing it outright. The job detail page in the dashboard shows a banner with the exact problem, and the Linear issue contains a link back to it.

To unblock a held job: fix or add the label on the Linear issue, then re-trigger the Agent Session. Delego will pick it up and enqueue it fresh with the corrected values.